SAFE Network Dev Update - September 27, 2018

This looked very promising!

3 Likes

Thanks so much for the weekly update! I know everybody works hard.

I liked the @goindeep article on the medium.com website. Great work!

Iā€™m wondering if I could write one of these articles. I have a lot to say about cryptocurrency that is useful. If I wrote a charming, clever, article, and the Maidsafe management approved, could I get published too?

6 Likes

Go for it. Thats what @goindeep did, he made it and asked members of the forum to look at it and comment on it.

No reason you cannot do similar.

6 Likes

Great update.
And really a great article, @goindeep!
Everybody should check it out and clap it up on Medium.

8 Likes

Great update Maidsafe devs,

Really loved @ bochaco explanation vid, please more of these as this puzzle gets put together. Is this also shared here: https://forum.safedev.org and https://safenetwork.tech to inspire new devs?

:stuck_out_tongue:

5 Likes

It is, but ratherā€¦ subliminally, as @foreverjoyful and -cheerful is one of the interesting candidates that are yet to be met.

I kinda wish some member would actually meet up with him. Would make for a great devotion test.

ā€œSon, the time has come for you to prove your worth and earn a permanent job with the team. Are you ready to get a painful SAFE Network logo body branding right on yourā€¦ cheek?ā€

ā€œWhatā€™s the other option master?ā€

ā€œSarah, let him out of the cage!ā€

3 Likes

Meant to also mention that the crust anylitics dashboard looks really nice!

10 Likes

I donā€™t know if they are useful to your discussion but here are two remarks I want to add:

No, it isnā€™t. Only the latest version is available, this is true for both the MD version and the MD entry version. Note that in the past we had versioned SD which used to retain all the history of versions.

I would say instead ā€œwhich we donā€™t have anymoreā€, because SDs allowed this. Furthermore, we had the choice to store only the latest value (unversioned SDs) or to retain all the past values (versioned SDs).

1 Like

youā€™ll need something that can be amended/mutated with a new version but keep its address, which at the moment we donā€™t have.

@tfa I know MD is different to SD, but I think it does meet the need described in the quote above, because the address of an MD doesnā€™t change when you mutate it.

So I think Iā€™m misunderstanding you and @bochaco there?

This is why you need indirection in a graph - to avoid the need for address changes to be propagated when a resource at an address changes, and thatā€™s what Mutable Data provides, and which SAFE NFS turns into a simple file system API.

1 Like

I was talking about a data type you can mutate without changing its address, where mutation was really storing a new version of the data and keeping them all, and each version of its data was immutable, so itā€™s not the case of what we have now with MD.

Iā€™m probably being a bit thick, but I donā€™t see why you canā€™t do this with MD.

I guess you are talking about an immutable version of this (ie any file size rather than up to 1MB per MD) but Iā€™m still thinking that functionality can be achieved with MD? It might involve more API calls, but is this just like an MD which points to an ImmD, or is there some property missing from for your purposes?

I can see where there might be differences, but Iā€™m not sure if they matter. Just trying to clarify.

Just to clarify: the feature we are talking about is storing n versions of an object at one single address, right?

I think the misunderstanding is:

  • @bochaco says that this feature cannot be implemented with a MD alone.

  • I say this was previously possible with a SD alone

  • you say that this is possible with several data objects (mutable and/or immutable)

I think we are all right, and there are no contradictions in what we say.

One possible implementation is that the single address is the address of an MD object whose entries are pointers to the successive versions:

  • Entry key: the version of the object

  • Entry value: the pointer to an Immutable Data containing this version of the object

Note: the entry version cannot be used as the version of the managed object because the history of this object wouldnā€™t be retained. This is maybe the origin of the misunderstanding.

3 Likes

The MD version and entry version is for optimistic concurrency, from all Iā€™ve seen.

(I was surprised when someone mentioned previous versions, Iā€™ve never seen a way to access them through the API. Thought for a while that I had missed something :slight_smile:)

Itā€™s not about storing previous versions, but for handling concurrent writes, where you provide an expected version, as to only be able to write to the version you read. If someone wrote in between, the version would not match, and an would be error returned.

5 Likes

Everyone is, including your example, there are many ways to do this. A new RFC to definitively specify appendable only data is required. It should be relatively short and concise though, but this thread and recent threads show it is required.

2 Likes

This is true, although PARSEC solves much of that now, or at least it can and probably much more effectivly.

You did not miss that, we did, it should now be an API call for sure.

6 Likes

Thatā€™s quite a miss, I think Maidsafe need to buy some of those cakey things for all the developers :wink:

And seriously, this is BIG, as we say on twitter :laughing:

4 Likes

Yum Yums :smiley: Yes this is due to us having actually moved away from the fundamentals with SD and MD, my fault in many ways as I pushed the SD RFC etc. then it extended to MD and now itā€™s being ā€œfixedā€ :smiley:

6 Likes

Thatā€™s the things. Not deep fried I hope. :laughing:

1 Like

I thought everything deep fried was better :yum::yum: At least thatā€™s what homer claims

3 Likes

Nice feedback overview. RIde on!