Users of mainstream social networks may expect to be able to edit content that they post. This behavior is possible because centralized networks place control of content in a single administrative body that owns the entire network. Distributed networks, however, do not delegate ownership to any one body. As a result, editing content after posting publicly poses a unique challenge.
Announcements published to a distributed network that implements DSNP are immutable. While underlying content can change, the announcement itself, once published, lives on the blockchain in perpetuity. Below are some ideas on how we can ensure that users have an experience consistent with what they are used to without compromising the fundamentals of a distributed social network.
A separate Announcement Type for Updates will allow users to update content via DSNP.
Motivation
Users coming from established social networks, specifically centralized ones, will expect the ability to edit content. This announcement type will allow them to do that.
An Update Announcement type could function very similarly to a Tombstone. Along with the hash and url of the updated content, the announcement could also contain the signature of the original announcement along with a new signature of the creator and an announcement type.
This would require editable announcements to have either a signature on them that edit announcements can reference, or a content hash that can serve as an identifier. I don’t believe using a content URI would be enough, since the content hosted at that URI could always change.
This announcement would serve as an indicator to the other nodes in the network that the content at the url has changed with the approval of the creator.
Alternatives:
An alternative could be to issue a tombstone for the original broadcast/reply and then issue another announcement of the same type. The upside of this approach is that it would not require a new announcement type.
The tombstone would need to indicate the signature of the announcement being updated as well as the type of that announcement. A validating body (either client or other validator node) would need to make sure the fromId matches the fromId of the original announcement.
One downside, however, to the approach is that it involves two separate announcements to achieve the edit/update. More actions required by the client increases surface area for errors.
Abstract
Users of mainstream social networks may expect to be able to edit content that they post. This behavior is possible because centralized networks place control of content in a single administrative body that owns the entire network. Distributed networks, however, do not delegate ownership to any one body. As a result, editing content after posting publicly poses a unique challenge.
Announcements published to a distributed network that implements DSNP are immutable. While underlying content can change, the announcement itself, once published, lives on the blockchain in perpetuity. Below are some ideas on how we can ensure that users have an experience consistent with what they are used to without compromising the fundamentals of a distributed social network.
A separate Announcement Type for Updates will allow users to update content via DSNP.
Motivation
Users coming from established social networks, specifically centralized ones, will expect the ability to edit content. This announcement type will allow them to do that.
Specification Pull Request
https://github.com/LibertyDSNP/spec/pull/174
Rationale
An Update Announcement type could function very similarly to a Tombstone. Along with the hash and url of the updated content, the announcement could also contain the signature of the original announcement along with a new signature of the creator and an announcement type.
This would require editable announcements to have either a signature on them that edit announcements can reference, or a content hash that can serve as an identifier. I don’t believe using a content URI would be enough, since the content hosted at that URI could always change.
This announcement would serve as an indicator to the other nodes in the network that the content at the url has changed with the approval of the creator.
Alternatives:
An alternative could be to issue a tombstone for the original broadcast/reply and then issue another announcement of the same type. The upside of this approach is that it would not require a new announcement type.
The tombstone would need to indicate the signature of the announcement being updated as well as the type of that announcement. A validating body (either client or other validator node) would need to make sure the fromId matches the fromId of the original announcement.
One downside, however, to the approach is that it involves two separate announcements to achieve the edit/update. More actions required by the client increases surface area for errors.
Copyright
Copyright and related rights waived via CC0.