I think if it is close enough but a large departure then I would say it’s perhaps better to make another rfc. If it’s a lot of comments then perhaps adding these comments in a way people can grasp them, if possible a bit at a time. I would say we need to be careful at thoughts of deleting ImmutableData from these older versions though as it’s a hack if I create a StructuredData and add well known ImmutableData (or worse) identifiers in the StructuredData.
I think a repo to back up / explain your ideas/suggestions is a good way to go when there is a lot to decide. If possible bits at a time works best though.
Perhaps start with changes here, or if you feel there is a large departure then a new RFC.
Loving these RFCs! IMO, this solves the problem of needing multiple forums mostly - detailed technical discussions can be associated directly with the RFC.
It looks like retaining archive versions will be super simple, which is awesome tbh!
I wonder how much effort it would be to make a safe net version of Git? Perhaps even a simple app that just lets you compare and roll back on any file saved to safe net would be very handy.
We have all overwritten files and regretted it. Tbh, I am surprised that local file systems haven’t provided this too, as stale versions could just be zapped when the file is deleted or space is getting tight (e.g. if you are running low, you may not get a backup which lasts, etc).
Thinking about this further, the beauty of having globally unique data references creates a whole new range of possibilities.
Why would you download or copy something when you can just reference the original? You may not even want the latest version.
In short, the whole network’s data can be included, compiled, extended, quoted, modified and so on. This is massively powerful and will take the internet to a new level, with highly integrated and distributed applications - even the source could be distributed and directly linkable at network speed.
Who needs FTP, HTTP, DNS, SMTP, POP3, IMAP, various IM, SMB, NFS, etc. These are all going to be made obsolete, as they simply become superfluous. Mind blowing stuff, when you think about it.
Can anyone explain this RFC in Lehman terms? Is it so that Apps in the Client can use their own protocols or so, which only they understand? Like, when I write an App that’s providing a forum? I can use my own type_tags like: post_reply, delete_message, update_page?
I will try, As an App dev you select a type_Tag and way to create identities (i.e. hash of a username is an easy one). You supply the correct keys etc. and you have a place on the network where the network will protect and perfectly update your data, regardless what it is.
So the rules are,
You must supply an initial owner of the data (owners_key) and make is same as previous owner.
This is now transferrable data hold … hold … hold …
So now you have a space where your client software can go to get something So what can that something be ?
This is what is good about this, that something can be anything, such as
Dns records
Document types
Tokens
Directory listings
Calculations
Code (something that will take instructions and execute them)
So pretty much anything you can do today, but SAFE secure and decentralised. So what if your data won’t fit into the 100Kb limit?
Then you create immutable data chunks (easy take data hash it, the hash is the name data is the content).
So then consider some very basic features and examples:
All data can be encrypted or plain (private or public).
All data is now cryptographically secured and transferable
All data is now able to be manipulated via a quorum of owners agreeing to do so (M + N sharing). So like Judge Dredd when the judges have to vote to re-open the Janus project Well more important than than. Important ALL DATA is now able to be handled like this, everything!
Example usage
Smart contracts, using external oracles or even plain escrow capable systems (ebay etc. should be easy)
Business decisions by a board/group all handled automatically (you decide on the data, then network does this for free for you).
Document histories and changes (github like data) and much more easily implemented.
Mashable data (dynamic websites, forums, commenting systems) all become very simple. This should extend to different API’s between SAFE systems as well.
Ownership transfer of any document (house, car, guitar ownership papers) very simple
… this goes on forever, but just think securely transferable quorum based data of any type, I have no clue what folks will build, but I can imagine this is where SAFE network goes beyond building only what is available on todays networks.
Of course again all controlled by the people and no intermediaries or banning etc. now applies to App developers and content creators as it has been for users and farmers. Now what will we be prepared to do
By definition a SD is mutable. If you want to reference data that doesn’t change it would be more convenient to create plain simple data. If you insist on using a SD, the only way to be sure that it doesn’t mutate is to be the owner of it (it can mutate, but only through your control).
There are 2 kinds of SD:
non versioned ones that retain only the last version
versioned ones that retain all the history.
At first glance you could think that you can reference a specific version of a versioned SD but there are 2 problems with this solution:
a versioned SD contains a vector of immutable data with one element per version. So you would have to memorize the index of the data you are interested in. It is simpler to directly memorize the name of this data instead of the name of SD + an index.
when a new version is appended the client API adds a new element at the end of the current vector. This is the way the history is kept. But nothing prevents the owner from modifying this vector to alter the history of the SD. This has to be programmed in the core client code, but this is possible.
Possibly, it depends on how SD is or will be coded. It is hard to say (I don’t quite understand the functions implementing the controls).
But anyway I don’t see the use case: SD were created to offer a new kind of data that can be modified or deleted. When we don’t want these functionalities then it is simpler and cheaper to use immutable data.
hold … hold … hold …