SAFE Network Dev Update - January 16, 2020

It will be a basic version, very similar to RFC0057. Some changes have happened since it was written, so it probably goes into a new RFC.
After Fleming we can evaluate and go more advanced on things (and look at different models as well). But at this stage, this is all that is needed.

10 Likes

I thought that sections merge was now abandoned (temporary?).
While the mentioned RFC states:

When two sections merge, the new section’s farmed value will be the total of their final farmed values.

Have I missed something?

3 Likes

Thats a cracker :rofl:

1 Like

Yes :wink:

This for example:

And, nopes, it’s not temporary. Merges implementation is not needed.
I’m pre-breakfast on the phone but can elaborate later if I’m not ninja’d by David or so :smile:

8 Likes

They are abandoned forever. A section has 7 Elders (controllers) and almost 200 Adult, who store most data. So before a section needs to merge you are looking at losing over 100 nodes, poss closer to 200, but then you have lost almost all data. Merge code kept many engineers sleepless and there was never a need to worry, node age fixes it really, but disjoint sections was the big change a while back.

tl;dr No merge could happen without almost total data loss, ergo we never merge. We can lose lots of nodes adn never merge (i.e. approx 95% node loss needed to merge, so network is then dead not in need of merge).

14 Likes

Here we go… :laughing: :laughing:

5 Likes

I remember reading this, and thinking, is this a possible attach vector? How much work will be required to become adult, and then kill the nodes?

2 Likes

It will be relatively easy to become an adult. If we lose an Elder the oldest adult is promoted to fill that slot etc. Elders should be quite robust though as they have survived a long time.

4 Likes

Chinese Translation here:

21 Likes

Thank you for the translation @eureka! I added it in the first post :dragon_face:

7 Likes

Thanks for the update Maidsafe devs,

Thanks for your dedication to make this happen.

:white_check_mark: :white_check_mark: :white_check_mark: to go… :partying_face:

:crazy_face:

9 Likes

Been reading through this. It’s pretty thorough tho I think someone was typing fast because there are some minor typos that need fixing scattered through it. Also what does it mean to mutate data in terms of an app transfering safecoin? I also think at some point the user should be able to create multiple wallets or subwallets (or safecoin IDs similar to how they have SAFE IDs) to help organize their money. One of the most annoying things about digital money I’ve found is that you can’t organize it too well. You have a single bank account most times and it’s all lumped in one place. With cash you can separate it, put in jars, and file it like anything else. So perhaps at some point you could have a safecoin ID system where one could label groups of safecoin dedicated to x or y purpose (maybe even add color coding to the UI which could be useful).

2 Likes

The IETF quic spec draft was published 2 days ago (https://quicwg.org/base-drafts/draft-ietf-quic-transport.html) and might be à propos re:quic-p2p memory usage (see 4. Flow Control and 21.5 Stream Fragmentation and Reassembly Attacks)

4 Likes

Not sure I get your question here, could you elaborate?

This status board is focused of the Minimum Viable Experience (MVE). Here’s a big explainer on that, incase you missed it. So it’s not the extent of what the app, or Network, will be capable of but the minimum we feel that needs to be built to get everyone up and running.

You’ll also notice we have multiple wallets down as a stretch goal for MVE too by the way.

The way it will work in the app before that, is that you will have a single wallet to contain your
Safecoin, but you’ll be able to transfer in and out of it using any of your SafeIDs, or a one-time anonymous wallet address.

You’ll get a fair about of organisational tools tool, as you’ll to filter incoming and outgoing payments by SafeID, and see the transaction history for each etc.

This gives you a good bit of flexibility, and the ability to use an unlimited number of identities with safecoin under the one account, but reduces the complexity of the user interface somewhat for the first iterations.

Including multiple wallets adds quite a number of extra considerations: creating wallets, naming wallets moving coins between them, labelling, assigning a ‘default’ wallet for day-to-day app spending, which IDs are associated with which wallet, removing/archiving wallets etc. It feels simple, but all these wee things add up, and suddenly timelines start extending.

This is the reason we’ve designated it as a stretch goal. We can have a perfectly usable, viable app, with just a single wallet, and anything else on top of that is a nice bonus.

12 Likes

Is there any merit in adjusting the roadmap to launch the safecoin first?

Like - before farming rewards are available, before all sorts of other stuff…

I mean… that’s an app right there. It’s the only app most blockchains have. It’d help boost MAID’s price and attract a lot more attention to the project (maybe desirable, maybe not?)…

Just a thought… thoughts?

2 Likes

It’s all part and parcel of it. You can’t really have one without the other. It requires a complete network to function and be secure. The track we are on though, is the quickest route to it.

18 Likes

Can anyone explain me a it about frontend roadmap to beta? I can see on github, it’s not been updated since March 2019,

1 Like

I think you meant mutable or changable data, like I get the general idea but it’s just very odd way of putting it

Yeah I actually did notice it was for the MVE and like I said I don’t expect it to be an immediate feature. I just think it would be useful. If multiple wallets are implimented later that would be great.

2 Likes

Just to be clear, this is the ability to set permission allowing an app to use Safecoin from your (default) Account Wallet for spending relating to the use of the app in creating, editing (mutating), and uploading data.

This is a separate permission to that allowing an app to send (transfer) Safecoin to another user, or Wallet.

It’s also a separate permission to the one authorising the app to be used to mutate data. Subtle difference, but this one only relates to Safecoin, and not authorisation to edit the data itself.

7 Likes

Thank you for the heavy work team MaidSafe! Do not live forever, create something that will! :dragon:

I add the translation into Bulgarian in the first post :dragon:

16 Likes