SAFE Network Dev Update - August 30, 2018

[dirvine]

@zeroflaw

This sounds cool, but so far everything unexplained is explained by the word random . I could argue all day that nothing is random.

Not with me though

@zeroflaw

Thats what interfaces and unit tests can tell you. If (B) behaviour changes, (A) is never going to be able to agree with (B), so the network can’t upgrade until enough people are randomly using (B) reinforcing that (B) has the correct behaviour (This will take longer than 50% because they are all randomly trying the the new behaviour). So the tipping point is still basically adoption. Unless the change has no impact on behaviour, then the upgrade is seamless.

No (this is again absolutism, there is many ways to upgrade, i.e. we are speaking to skype dudes to see how they did it etc.) , any node could speak both language A and B and via multiformat or other means know which language to speak. This is RFC territory though and that RFC does not yet exist.

@zeroflaw

@dirvine honestly I’m just trying to work out how you expected aspects of this network to actually work as you intend. I feel resources for describing these things are limited. They really should be aim at the ‘look how simple this is.’, not ‘look how clever we are’.

I appreciate that (a lot), but I think this list does not come across as us being clever in any way. It is a set of principles/foundations the network requires in our opinion. It has not changed but we felt it did need re-emphasising. Your explanations make it sound as though you are trying to be clever telling us there is only one way and then creating that way in what really needs to be a design discussion/doc (RFC). All we are saying is the network needs upgrades and may …

@zeroflaw

Yes, but which nodes do you pick from the ones that are waiting? I know, I know the answer is random

Whichever one is waiting at the time we want one in a section. Nodes will try-join and be accepted or rejected (probably do resource proof work etc.). Again though RFC

@zeroflaw

Okay, agreed, any device with an output is a server. Yet, the network cannot be expected to work efficiently with 100 home laptops, both consuming and serving data.

I don’t agree, after all it is designed to. This is why so much work in crust with NAT traversal and reliable udp etc.

@zeroflaw

You are going to need servers

If you mean computers, then I agree

@zeroflaw

so lets update that definition, an always-on computer device with dedicated resources for the sole purpose of serving others.

Let’s not

@zeroflaw

You totally just reminded me of one of my lectures I attended at uni, it was based on the same argument with a different example.