Remember we are open-source. Anyone can join if they compile the code. We need to handle that too, but perhaps we can whitelist some ip’s but I feel we need to not code too much we don’t want in production.
We do have churn tests in house, so linking that with the testnet makes sense. Mind you there is always a limit to the churn the network can handle safely before we get into the network rebuild status. That is where nodes have data that is signed and even though they are off the network they can represent the data again and so on.
The other churn limit is the loss of consensus nodes in one go, we still have to fix that.
Hammer Lord hat on again.
Is there any point in getting as many folk as possible to near simultaneously download a partcular file/dir?
" OK troops as close to 2100UTC as you can manage, issue this command safe files get safe: // blah"
And obviously carefully checksum the received output
For me it looks like perfect application of git branches.
Run it, extract useful data and forget it.
Constants, which controls how often nodes will leave and join should not be completely random, yes.
I think that even slight disturbances like taking 1 random node offline for 1 hour every hour will allow to catch lots of bugs.
Dear David & Team, I think it is great to see Maidsafe doing official testnets! For us non-techis, how is it going? I get the idea it is running pretty smooth, am I right?
Yes true, but we didn’t always split before the wheels came off. Always been suspicious of large puts causing an issue (is that confirmed by the limit?)
While adding the ability to join willobviously (may) add instability my pondering is will it be more stable with the limit in place?
Great work!!