DIP-287 DSNP Content URI specificity

[wesbiggs]

A DSNP Content URI is formed by using the creator's DSNP User Id and the content hash of the referenced content.

However, it provides no context as to where (or when) the content appears.

Because DSNP specifies that Activity Content Notes contain a timestamp (the published field) with second-level precision (xsd:dateTime type), it is unlikely that two Notes from the same user, even if they contain the same content, will generate the same hash.

Problem Scenarios

Misattribution

However, a malicious user or poorly implemented application could certainly create this scenario:

1. A posts "I like puppies". B posts "I like Nazis".
2. C constructs a reply Note that says "I agree". C announces the Note twice -- once as a reply to A, once as a reply to B.
3. D comes along and sees the "I like puppies" thread. D replies to C's "I agree" with "Me too"

Does D's "Me too" get included in the "I like Nazis" thread? An outside observer can't tell.

Over-tombstoning

Consider a similar case where the same content is posted twice in two different contexts within the same published second.
If C wants to delete the reply to B, but not the reply to A, he has no ability to do so.

Options

1. Leave as is. The likelihood of this scenario occurring is low.
2. Leave as is, but add instructions to implementers on heuristics to deal with these situations (e.g. don't allow the same DSNP Content URI to be used as a Reply in two different threads.)
3. Add further context to DSNP Content URI in an attempt to make it more unique.
4. (Similar to 3.) Add further fields to Activity Content Note in an attempt to make it hash more uniquely in different contexts.
5. Change resolution of timestamp in published field to milliseconds

A note on 3 (and possibly 4) -- what happens if a user replies to a specific item with the same text, over and over again? Should this be allowed, or should it be de-duped?

[JoeCap08055]

I'm in favor of 4. DSNP content should be unambiguous regarding context; ie, if context is important, then it should contribute to the content hash. 3 seems less desirable because to reconstruct the content URI from the content then would require additional information.

Regarding the note:

A note on 3 (and possibly 4) -- what happens if a user replies to a specific item with the same text, over and over again? Should this be allowed, or should it be de-duped?

The timestamp field mitigates this, somewhat. Beyond that, it should be up to the provider to provide for some level of de-bouncing, if that is desirable.

[wesbiggs]

Community Call discussion:

• Final ordering should be eventually consistent, and "first" should win; second (and subsequent) replies should be ignored
• Suggestion to use milliseconds like Bluesky -- doesn't address malicious user, but allows detection more easily
• Current spec on ordering of announcements: https://spec.dsnp.org/DSNP/Announcements.html#ordering-announcements
• Can we better align with ActivityPub usage by including it in the content?

[gobengo]

Is this because the hash doesn't have a timestamp or nonce in it?

UPDATE: @wesbiggs pointed out to me that the timestmap IS in the preimage of the hash that goes in the content URI. So the rest of this may be misleading. Sorry. In this case my feedback is that it's a little tricky from reading the spec quickly to determine what is the preimage of the hash that becomes the content uri. Wes says it contains the timestamp (but not the inReplyTo value), but I didn't grok that from https://spec.dsnp.org/DSNP/Identifiers.html#dsnp-content-uri

i.e. would it also happen for the somewhat-less-contrived/malicious behavior where web3 folks often wake up and just post 'gm' to their followers to sort of start a daily discussion. iiuc each of these posts potentially every morning would have the same content uri, and clients wouldn't really be able to thread the replies in a way to facilitate the morning chit chat.

4. (Similar to 3.) Add further fields to Activity Content Note in an attempt to make it hash more uniquely in different contexts.

(If I'm understanding right) #4 above seems like a good idea. add inReplyTo and ideally also a timestamp to the hash that goes in contentUri.
IMHO ideally the hash in the contentUri would be a hash over all the fields in the content. e.g. hash the parquet serialization, or if there is a canonical JSON serialization, apply rfc8785 JSON Canonicalization Scheme and hash that.

[gobengo]

Can we better align with ActivityPub usage by including it in the content?

Here is the inReplyTo property in AS2: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-inreplyto

[wesbiggs]

Summarizing discussion points into a proposal:

• Add a reference to the content being replied to in the reply Note will cause the contentHash in the Reply Announcement to vary appropriately
  • A common pattern for this is to use the inReplyTo property from AS2 with a URI
  • The DSNP Content URI would be used for this
• Consuming applications should validate that the "inReplyTo" URI in the content Note matches the "inReplyTo" field in the Reply Announcement