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?
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 
)
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 
And seriously, this is BIG, as we say on twitter 
4 Likes
Yum Yums 
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ā
6 Likes
Thatās the things. Not deep fried I hope.
1 Like
I thought everything deep fried was better 
At least thatās what homer claims
3 Likes
Nice feedback overview. RIde on!