SAFE Network Dev Update - February 7, 2019

Oh snap!!! That’s awesome and @AndreasF strikes again!!!

Also cool as hell :smiley:

Addon: I should also say huge props to those from the POA team for working in an open-source, collaborative fashion. It’s not seen enough in this space I think. If anyone else from POA reads this, thank you. :blush:


Second! :v: Now to read …


This is amazing! Great job team! The SAFE NET train is getting faster…


84 posts were split to a new topic: Appendable Data discussion

An impressive array of progress, but it is a little depressing to hear that Fleming will be losing some focus to improve Parsec. I understand the long term importance of this, but alpha 2 is getting rather long in the tooth.


This means we have BLS keys in play though. So much better authority chain (much simpler) plus a powerful mechanism for multi-sig etc. So not all for fleming, but a big win when we go down the Maxwell rollout. There are many new patterns open to us with this actually in routing and vaults.


I’m guessing this should help speed up PARSEC’s performance also?


No figures yet, but I hope so.


the holy grail :ok_hand:


Cool update! Not as hell (:hot_face:) I think; Maybe some special place there :wink:

Reminds me of the ELI5: ZFS Caching talk @FOSDEM last weekend (LRU explanation starting at minute 7). The Solid and Tor talks was also interesting.


Cool update,
There will be a special place in hell for those who do not plan ahead thoroughly…

What am I missing here?


Maxwell is the step after Fleming in the roadmap.


Ooops - I actually stopped looking at the roadmap cos I was telling myself " They are working as hard as they can. I’ll take the updates I see weekly and leave it at that"

Thank you :slight_smile:


Come on Fleming…:muscle::+1:t2::innocent:


There is a feeling after reading all this that Fleming will be slowed, you (kind of) have control of your data but not entirely and if certain steps are either made or not made, it could serverly impact adoption of both individuals and companies based on cost. While a finer tuned project is always great, from the layman side most of that sounds like not a positive outcome.

This is post Fleming, Fleming will have no data. It is a routing only network to show, sharding, abft, chains etc. Basically a secured autonomous network foundation. Maxwell will follow, where we can add in functionality we already have in code and tested. That part is where the work is going with part of the team right now to confirm all there will be smooth. So the Fleming work is very much backend driven, which allows the front end guys to focus on what comes next and can we do those next parts quickly and in a managed fashion. We are all looking forward to getting to a more timscale driven roadmap. I hope Fleming answers the last of the big unknowns, except perhaps for upgrades. But I think we have some great ideas there as well.


Okay, this update is dividing me emotionally. There are some really exciting things in it but also some things that concern me. Let me iterate through these:

Very delighted to hear that! Also very exciting to hear that you have found a solution to potentially make PARSEC fully asynchronous. :slight_smile:

Maybe it’s just me but as an excited +3 year follower, after many emotionally ups and downs I currently feel a little bit confused and lost on what’s left to be done in terms of really huge unknown problems to solve. I think this comes mainly because of phrases like these, that might stir up wrong expectations (from the introduction post of PARSEC):

Maybe let’s analyze the big milestones, mentioned on the timeline:

  • Integration of PARSEC in a dynamic permissionless network
  • Introduction of Disjoint groups with secure message relay
  • Enabling disjoint groups to merge and split whilst maintaining consensus
  • Secure Message Relay
  • Integration with SOLID

Is this a complete list of major items that need to be finished in order to launch FLEMING and if so, what is the level of “unknownness” of these items?

The second part that concerns me is the somehow heated discussion about Appendable data. I have the feeling that we decide here on very big structural changes although we have very little insight in how the network evolves once it is launched and how it will be getting used. Even if you include the community here on this, we are still a very small group right? As an alternative way I would suggest the following path:

  1. Put all resources behind launching a first iteration of the network
  2. Once it got some traction, introduce some kind of node/user voting technique (similar to bitcoin)
  3. Let the members of the network decide on such major design changes
  4. Iterate network versions through “hard forks”

I don’t know how feasable that is but it certainly would support the decentralized paradigm which I think in the end unites us all here.

That being said…maybe after all it turns out that I’m too impatient and we’ll have a more detailed timeline soon?

Still, until then it would be very interesting to hear your thoughts on my questions / suggestions.


These are all done (SOLID is ongoing). The last big thing we need to finalise is network upgrades. These are likely to start with
a forceful mechanism and evolve to fully network aware upgrades. That does not stop the launch, but makes it easier I feel.

These are not big structural changes, at least not from our perspective. It is cleaning up what we have and hopefully making that clear, which we have not made clear enough so far, as the discussion show.

Hope that answers your questions?


Thanks David for the fast response!

With “done” you mean done, in terms of conceptually solved (no unknown left) but still needs to be implemented?

Okay, thanks, then I might have misinterpreted this as well.


By done I mean already in code and being tested :+1: