Update Announcement Type for DIP-165

[dopatraman]

Problem

This PR adds an Update Announcement type to the DSNP spec.

Link to GitHub Issue(s):

165

Solution

The Update Announcement has a contentHash that is a keccak-256 hash of the new, updated content. It also has a URL that points to the new content.

Discussion

Open question: will we need to create a new URL each time we update content?

Diagram:

One scenario is as follows: a user emits a Broadcast, creating new content. The Broadcast Announcement contains a hash of the content as well as a URL that points to that content.

Later on, the user decides that they want to update said content. They emit an Update Announcement that contains a new hash of the updated content but the same URL as the original broadcast. This means the previous Broadcast's content hash will no longer be valid, even if it was valid at the time it was created.

Does this matter?

The upside of this approach is that we will be able to host content once and then point updates to that single hosted copy. The downside is that previous content hashes will be invalidated each time an update is made.

---

Consider another scenario: the user emits a Broadcast creating content as earlier and tries to update it. This time, however, a new URL is created that points to either a brand new copy of the updated content, or some sort of diff.

Diagram:

The upside of this approach is not only that the all content has a traceable history, but also that previous versions can be validated. However, the downside is that we will wither have to copy content on each update or rely on clients to piece together partial diffs.

I think that until we have a compelling reason not to, we should take the 2nd approach.

[dopatraman]

Suggestion: We can also name this announcement "Update Content", as it can only be used to update content.

[dopatraman]

@saraswatpuneet any thoughts on the question of whether or not we should generate a new URI / copy of content?

[saraswatpuneet]

@dopatraman I think since we are linking back to old uri we might generate a new one which in case get updated again will point to previous one as you mentioned to have a have a consistent flow of edits/update but @wilwade's insight in this will be useful

[aramikm]

My personal choice would be to use 2nd approach meaning creating a new update message that points to original broadcast or reply Message (maybe using content URI or another announcement identifier) and banning creation of any Update message for another update messages. (Kinda like not allowing to tombstone another tombstone message). So we will always apply and use content of the latest update message.

first operation -> adding a Broadcast (B) update 1 -> adding an Update (U1) which is pointing to B update 2 -> adding another update (U2) which is also pointing to B (if we always keep the latest copy of the content we do not need any chaining but if we decide to do diffs then we would need to do chaining)

[saraswatpuneet]

@aramikm that definitely is an approach but then aren't we assuming that only one update is allowed is enforcing a rule but if we be flexible for updates l, services would pay for it and they can do this custom restrictions on their end giving them flexibility to whether allow one two or n updates

Thought? Though if we want to restrict we need to have a rationale but I am ok with either or

[aramikm]

@aramikm that definitely is an approach but then aren't we assuming that only one update is allowed is enforcing a rule but if we be flexible for updates l, services would pay for it and they can do this custom restrictions on their end giving them flexibility to whether allow one two or n updates

Thought? Though if we want to restrict we need to have a rationale but I am ok with either or

I'm not sure if I understood you correctly. So my description probably is not clear. Based on that approach that I was thinking you can have unlimited updates but any update will just point to the original announcement instead of pointing to it's previous update. The reason is that if you always keep the latest content you don't need to follow the chain of updates.

[dopatraman]

@saraswatpuneet i see what you're saying -- that by only allowing updates to be made to original content we are indirectly creating a rule that there can be only one update. However, it may be possible for clients to:

1. aggregate updates by announcement URI
2. apply the updates in order (ordered by timestamp maybe?) to reach the final state of the content

that way, we can still prevent users from making an update to an update without indirectly limiting the number of updates that can be made.

Thoughts?