I am not sure to understand, but user or application, the SD owner doesn’t matter. The problem is that a SD can be recreated with same ID, same version but different content.
I also remind you my RFC about SD time stamping. If it is implemented, an application could timestamp the SDs and anytime a SD is modified (or recreated) its date would be updated and the version wouldn’t matter.
The functionality is not exactly the same:
with previous delete implementation we were able to prove that a SD has not been modified since its creation
with SD time stamping we would be able to prove that a SD has not been modified since a certain date
To be able to create ledgers competing with bitcoin blockchain, the safe network needs both.
If you can remember a date you can remember a hash so, to probe that a SD has not been modified, a timestamp is not essential.
Of course, all tools are welcome, and a timestamp, who don’t need to be on core, too. But we have several kind of SD, the possibility to create other, and the immutable data to play. With a little imagination, we can do almost anything.
Or just maintain order of creation? I am not convinced it requires time, but a ledger would require an order of creation. I think we can do this cryptographically and then ledger items (undeletable) will provide exactly what you are after I think. I am working on something that will provide that exact capability, but not for all SD types.
It means a type will not require to be ledger type, but you can ask for a ledger bit set on SD update. So for instance keep a safecoin receipt on a ledger that is cryptographically provable. That, is what I think would provide the mechanism you are after.
Once you have that then putting time on an entry can simply be from a timeserver (app equiv of ntp) and not in the core. The order of creation would prevent massive pre/post dating by a bad actor.
I am going to harp on this a bit more. Some of the functionality you are putting into reserve types. One reserve type == one functionality seems to be wasteful and very limiting.
For certain functionality such as read/write delete/undeletable write (update) by owner/everyone/noone should really be a permissions/attributes for every SD object. This allows applications/protocols (eg decorum) to have SD objects using their own type for specific reasons rather then using a particular type that every other applications that need say a undeletable SD is using and massively increasing the chances of clashes in the ID
To my way of thinking SD types should be for the likes of SAFEcoins, messages-out-boxes, and other core/application uses. Not for permissions to read or write or delete or what groups can do this.
I agree and this is what I am aiming for. Complete capability set in every SD object. Reserved types will be like
SafeCoin - Only created by network (users cannot create)
DNS - A type where data is held in a particular container (hashmap of services)
Login packet - The network will react to invalid packets by sending requester seemingly encrypted data (that is junk basically, to prevent range attacks).
Yes this is the debate we should be having here I think. To me allowing a strict set of capabilities is powerful, but needs really debated thoroughly. It seems ownership, multisig and xfer are very easily satisfied. I think ledger types are also satisfied easily.
I agree core types can be differently handled in core, so we can look deeper at computation etc. (map/erduce type functionality).
Here, I think there is broad agreement. (I know I am repeating quotes here)
I think all types are deletable ? Perhaps I am missing something in the convo though? I have a suggestion (RFC to come) that adds a ledger flag, if this is set any SD will not delete. So rather that per tag or type, this would be set on each SD you wish to not allow deletion of.
Ah so the ledger (undeletable) feature is going to be an attribute “bit” of an SD and not a specific SD Type like DNS or coins SD types are.
Are the other attributes going to be attributes rather than their own specific SD types. Remembering back the “who can update the SD” types mention a while ago.
Sorry but not. Is not possible to synchronize time across entities in a distributed system. That’s is a basic property of distributed system. And, in the end, you always depend on some method of ordering events to function.
A lot of propositions by @dirvine@neo for new developments but I am afraid they will delay the launch of safe network and many of them are already doable today or are of little costs:
Non modifiable SDs are already possible today: The app has to set an owner key with no known private key (by taking the hash of a known string). One such hash can be provided by a Maidsafe crate with 2 methods like is_immutable() and set_immutable().
Note that non modifiable SDs are different from modifiable SDs for which I want to know if they have been modified. For the latter Maidsafe has just to go back to previous delete implementation (and this functionality is the main point of my topic).
Ordered objects: A local ordering is already possible today (relative ordering of a subset of objects). The app has only to store the hash of previous object in the data part of new object. Both objects can be independently Immutable Data or Structured Data. In the case the old object is a SD, it must have an owner key with no known private key or have version 0 (once again at the condition that Maidsafe goes back to previous delete implementation).
A global ordering (being able to order any objects) seems too complex to develop in a decentralized network. Timestamping with an approximate date is much simpler to implement and is what is needed to build ledgers comparable to what is doable with bitcoin blockchain.
I don’t want something impossible. I want something similar that has already been done on bitcoin network: an approximate timestamps on SDs like there is in bitcoin blocks.
But ordered objects vs. timestamping is a digression. We are losing focus on the question raised by this topic: Will Maisafe go back to previous delete implementation? (except maybe for some reserved SD types)
// Reducing content to empty to avoid later on put bearing the same name
So the intent at that time was exactly what I want. Does this mean that people in Maidsafe team really changed their minds or is it an unplanned consequence of the “great simplification” of personas?
Currently we feel this can be achieved by a very simple addition of a ledger flag on SD items. It’s not a large change at all. Then ledger items do not delete, non ledger items will delete. I think personally anyway this feels natural and clean. So delete == delete and ledger items would return an error if delete is called. I need to write an RFC to include this very small change. I would be more than happy any other person writes that RFC though. (hint hint)
Normally a ledger is more than a series of ordered entries, they are also timestamped. Instead of adding just a flag, we could make a provision for a later addition of a timestamp.
As indicated in my RFC, a timestamp needs 2 fields because the consensus on a date can only be reached on an interval. For example, the nodes of the group managing a SD can agree on something like: current date is after 2016/06/10 22:43:13 and before 2016/06/10 22:54:24.
So the ledger field could be implemented by an Option<(i64, i64)> with 2 possible values initially:
None: which indicates that the SD is not a ledger entry
Some((0, i64::max_value())): which indicates that the SD is a ledger entry with a date between the beginning of Epoch to 2^63-1 seconds after that, which is concretely equivalent to no timestamp.
Later, possibly after network launch, narrower ranges could be introduced and the format would remain compatible.
Guess @dirvine is implementing a semi-ledger SD then.
A possible solution to time stamp is simple. I am certain that people will want an equivalent to ntp (timeservers). And SAFE utilises crypto
So lets have a series of applications that initially rely on the internet’s ntp servers, but later as the ntp servers serve SAFE too. They can provide a crypto proof of the time they supply.
Now how do you include that timestamp and its proof of authenticity? Well I can think of 2 ways “off the top of my head”
Obvious, the core does this. But this is not a good solution because it adds a new dimension of complexity and one that even the current internet never tried. Hence the ntp server system
You have a timestamp SD.
It is option 2 I describe below
The quality of the timestamp SD is noted by the ntp APP “servers” ratings of quality.
The timestamp SD is passed through a number of timeservers and can only be written by a timeserver and can only be appended to.
The first timeserver will create the SD and the others you pass the SD to will append their timestamp and proof.
The ledger SD is also passed to each timerserver APP so that its ID can be incorporated and the timestamp proof includes the ledger ID/contents hash as part of the proof.
the ledger ID/hash ensures that the timestamp SD is for the ledger entry and cannot be associated to any other or forged.
Oh and the timestamp SD also has the non-deletable flag set too
So if the kind of ledger you want has to have an accurate timestamp then you can afford a timestamp SD for each ledger entry.
The chicken/egg situation of how do you include the timestamp SD’s ID into the ledger entry, well you ask the 1st/any timestamp APP for the SD to be created then add that ID then get any timestamp APP to “stamp” the timestamp SD
I have updated my RFC to include ledger item management (and also catch up with routing and safe_vault since november)
A ledger item is a SD that is not erased from the network when it is deleted. Instead a new version is stored with an empty payload and its version is incremented by 1. The purpose is to prevent recreation of a SD bearing the same name.
I have implemented it and partially tested it. I will make 2 PRs in a few days when my tests are finished (for routing & safe_vault).
It should just return an Error on attempted delete IMHO. Keeps it simple and more of an expected pattern. So any SD with a ledger bit set does not delete.
I think this should not be coupled with any notion of timestamp though. I do appreciate the work, but coupling is our arch nemesis really.
So keeping these two things separate is for sure beneficial.
(I know I am repeating quotes here)