Deletion of SD objects

Hi @anon86652309, with the current implementation, how is it suggested to create a linked list made of SD? Are immutable SD(is this a thing?) also deletable?

So, directory listing tags are not reserved!

/// Tag representing the Versioned Directory Listing
pub const VERSIONED_DIRECTORY_LISTING_TAG: u64 = ::core::CLIENT_STRUCTURED_DATA_TAG + 100;
/// Tag representing the Versioned Directory Listing
pub const UNVERSIONED_DIRECTORY_LISTING_TAG: u64 = VERSIONED_DIRECTORY_LISTING_TAG + 1;

Respectively 15100 & 15101, that’s strange!

I don’t agree. If delete is implemented like a Post with an empty payload and a version increment (like it was before) we would be sure of the following fact:

  • a SD at version 0 has never been modified since it’s creation

If it is implemented by an actual deletion from the network then we are sure that a SD has not been modified in the past, only if three conditions hold simultaneously:

  • version is 0

  • the owner field is filed with a constant value with no known associated private key (like hash of “David Irvine” string)

  • we are confident that the app only generates such SDs

The problem is the last condition: it has no place in a decentralized network which should be trustless.

1 Like

Is SD on the kademlia DHT? If so, DHT data should be considered volatile in my opinion anyways. I mean a peer’s address and what not is “deleted” from the DHT too, right? Sorry if I misunderstand.

Vaults are deleted but immutable data are not, so no clear winner among entities of XorName space

SD can be deleted, we are only debating how deletion is implemented. I prefer previous implementation because current one allows misbehaviour of bad actors.

Yes it is. You only have to set the owner field with a value having no known associated private key. These immutable SDs are also non deletable. This is true in both deletion implementations (current one and previous one)

1 Like

Cheers for input, very helpful

That’s just plain wrong, a bug and needs fixed. All the reserved types are not currently reserved in code but will be (it’s an esy thing that needs focus).

Yes, but you can still do this.

A delete for instance though could allow a refund to be made of the payments to store it.

Unless you are seeing that delete being delete is wrong in some use case. If you are can you expalin the use case and why delete actually deleting would prevent that?

Using throwaway accounts could do what you say, even for type 0, but it seems you have another sneaky plan here. I am missing it and this is what we are looking for in these API discussion.

1 Like

@anon86652309 was talking about non-reserved SD types. So I am, and they exclude safecoins and accounts which are managed by core code and may have special behaviors.

Regarding the use case: any application that needs to prove that the SDs it generates can only be modified by incrementing their version. For example a forum in which each post display a number of edits that cannot be forged. A special case is version 0 which indicates that the post has never been modified.

By default that check is made. The process involves at the moment upgrade via only valid successor, amongst owners and previous owners it also checks for valid version increments (by one).

I hope that helps you in this case.

By default yes. But the application can cheat by deleting the SD and recreating it, restarting at version 0. Previous implementation didn’t allow that.

1 Like

I see, but that would mean the owner deletes? The app itself may not need to create the SD? Could it be something else is missing here, such as the identifier should be what increments? For comments I am not sure, need to think more on much of use of SD (way too deep in other parts right now), but this is exactly why we are here :wink:

IF you use identifiers and type tage. Your app selects type # (say 9999). and for a comment use the identifier as the story identifier (or similar). Then commenters upload an SD type 9999 with an identifier, ++1 of your story.

Then users pay to comment, but of course they can delete their own comment. Your app can ensure all comments are version 0 though to stop people editing them.

Early days and crude but perhaps a path to further investigate.

How does the network know if there is a private key associated with the owner field? Does it make a request to the network to look up for a specific public id (not sure this is the right term) and if none is found then the SD is flagged as immutable?

As an aside, I don’t know how we’ll create unbreakable linked list at the app level (or is that necessary?). It seems like an app will always have to guess if a linked list is just cut off or if it reached the end of it.

For example, a forum app requires that a node(a user comment), to be consider valid, is immutable. If someone creates a node that isn’t immutable, the app knows it needs to skip over this address and go to the next one. If there is 10 invalid node in a row, it will skip over them all to the 11th one. But then the owner of the invalid nodes deletes them all. How would an app know if the linked list is just cut off or if it ends? How can an app prevent this? Or does it needs to?

I’m not proposing anything, just trying to see what other dev have in mind to handle this case.

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.

1 Like

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.

To be able to create ledgers on a trustless network, safe vaults need an approximate time consensus computed by core code, like bitcoin nodes.

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.

2 Likes

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.

1 Like

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.

2 Likes

I agree and this is what I am aiming for. Complete capability set in every SD object. Reserved types will be like

  1. SafeCoin - Only created by network (users cannot create)
  2. DNS - A type where data is held in a particular container (hashmap of services)
  3. 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. :smiley: (I know I am repeating quotes here)

1 Like

Just to help my understanding then why is undeletable being given a reserved type rather then just a “flag”/attribute in the SD

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.

2 Likes