SAFE Network Dev Update - September 27, 2018


#22

This looked very promising!


#23

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?


#24

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.


#25

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


#26

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:


#27

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!”


#28

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


#29

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).


#30

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.


#31

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.


#32

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.


#33

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.


#34

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.


#35

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.


#36

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.


How does SAFE stop censorship?
#37

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:


#38

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:


#39

That’s the things. Not deep fried I hope. :laughing:


#40

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


#41

Nice feedback overview. RIde on!