DIP-145 Delegate Batch Signatures

[wilwade]

Abstract

A proposal to move the signature out of the individual announcement in a batch file and allow the implementation layer to choose how to validate batches. Proposing for Ethereum, that the transaction with a batch publication should be signed by a delegate of the DSNP Ids in the batch.

Terms

• First Party: The owner of the DSNP Id.
• Second Party: A delegate of the DSNP Id, but not the owner. Often a service provider.
• Third Party: An actor that is cryptographically disconnected from the DSNP Id(s).

Motivation

• Simplicity in the spec
• Flexibility at the implementation layer
• (Ethereum) Increase in batch submission transparency

Specification Pull Request

Current change pull request: https://github.com/LibertyDSNP/spec/pull/183

Rationale

Half of the requirement in validation of an announcement was already at the implementation layer. This proposal extends that to the entire question of how to validate an announcement. This allows more freedom in the implementation to validate announcements in a variety of ways including at write-time instead of just read-time.

The other motivations draw from the implementation solution:

• Transparency increase. By cryptographically linking the batch to the delegate, users can know which delegates are honest and maintaining data availability.
• Batch file size is reduced.
• The work for validation is reduced to merely checking that the transaction sender is a delegate for each fromId in the batch.

Backwards Compatibility

This is a spec breaking change!

• Announcement structure drops a field and validation is completely altered.
• Tombstones are broken! We would need to update Tombstones to use the DSNP Announcement URI likely.
• Therefore this DIP will require DSNP to increase the minor version.

Migration Options:

1. Ignore previous data from DSNP.
2. Consider previous data from DSNP to be valid.
3. Have a migration block number per implementation.

For future changes like this, it would likely require 3. For now, we can just do 1 or 2.

Ethereum

No changes need to be made in Ethereum contracts to support this change.

SDKs

SDKs will need to be upgraded to support the changes.

Tombstone Announcement

Tombstone announcements will need to be updated to target something besides the signature

Reference Implementation and/or Tests

• SDK Update/Branch: TBD.

Security Considerations

This might appear to increase the level of trust that a user must have in a delegate, but the trust was just hidden before. Previously, an app would need to either ask the user's trusted wallet to sign every announcement, have a key in the app, or have a backend service signing announcements. The user's wallet option is secure, but not a great experience for the user. Even if there was a way for the wallet to background approve, the multi-device nature of the world makes it a difficult setup without then also relying on web wallets. The expected outcome is that apps would lean toward having a key in their client or at the server level which is a hidden layer of trust.

The proposal moves towards an explicit 2nd party trust model for most users. It is a limit on the option of relying on a user's trusted wallet to interact with apps unless the user also publishes their own batches.

Dependencies

• 148

• 149

• 150

• 180

References

None

Copyright

Copyright and related rights waived via CC0.

[wilwade]

Ideas for tombstone targeting:

• Composite keys
• DSNP Announcement URI (reaction issue)
• DSNP Extended Announcement URI
  • dsnp://12345/0xabc/reactorId/reaction/createdAt (something like that)
  • Should reactions be different?
  • Graph style "👍" then "un 👍" = nothing
  • Works, small amount of data.
• Every Announcement must either be tombstonable (Must have an Announcement URI) or internally un-doable (aka Graph style)
• pre-signature Hash (see Announcement Signatures > Hash)

[aramikm]

• what is the benefit of of using dsnp://userId/contentHash instead of dsnp://userId/pre-signature-hash ? what If we have the latter and allow reactions to have URI?

[wilwade]

• what is the benefits of of using dsnp://userId/contentHash instead of dsnp://userId/pre-signature-hash ? what If we have the latter and allow reactions to have URI?

@aramikm Hmm... I like that idea in that it would be much more about targeting an announcement (instead of the content)

Ah just thought of a pair of maybe issues:

• Reactions/Replies/etc... would target announcements instead of content. Perhaps that is fine however? It doesn't take away from the ability to also target content, but something to think about.
• It is harder to find content when you only have a Reply/Reaction. The contentHash is a part of the bloomFilter, but the pre-signature hash is not. I think that might be a kicker.

I think this shows the difference in the goals of tombstone vs Announcement URI. The former is targeting an announcement while the latter is really targeting content (despite the name implying otherwise).

[aramikm]

I think this shows the difference in the goals of tombstone vs Announcement URI. The former is targeting an announcement while the latter is really targeting content (despite the name implying otherwise).

Yeah, so in that case we might want to have Content URI as what we have and a different kind of Announcement URI that targets an announcement.

I'm afraid we can not completely get rid of signature since it is serving a dual purpose. The identifier role needs to be filled somehow maybe by replacing it with a 32 bytes announcement-Hash and have it on bloom filter also.

@wilwade In any case I think it makes sense to have a unique announcement identifier in protocol level if we want the data to be service agnostic.

[shannonwells]

why not dsnp://userid/pre-signature-hash/signature, that way the content can be fetched and signature validated for the hash without interacting with the chain, also you get a unique combination signature+id that way. That way reposts are also different. That was one of the reasons we included the signature with the content hash. Another advantage is since the prefix is the same, it makes it very easy to track reposts without interacting with the chain and fetch the content only once.

[wilwade]

@shannonwells I don't think I quite follow.

@aramikm I think I agree at a minimum that need to use the term DSNP Content URI instead of DSNP Announcement URI. Created an issue for that: #148

DSNP Content URI is what we currently in the spec call a DSNP Announcement URI. It could be switched up to more target content than it does. (Getting it closer to what inspired it, the Web Annotations model: https://www.w3.org/annotation/) Either way, it currently does the job. Re-announced content is still associated with the original data.

If we had a new DSNP Announcement URI targeting a specific announcement are there other potential use cases besides Tombstones?

• Content moderation suggestions
  • User A posts content, User B puts a nasty comment/reaction on it, User A can suggest the comment/reaction be hidden
  • I think this might be better served by DSNP Content URI
• Content edits
  • I am the author of this post, and I want to edit it.
  • This can be achieved through DSNP Content URI better
• Encryption key revocation?
  • This is likely better to just target the key directly

To restate the options for Tombstones:

• Composite Keys
  • I don't think anyone in our discussion liked this. Lots of duplicate data
• Extending the (now named) DSNP Content URI
  • dsnp://[dsnp user id]/[dsnp content hash]/[something...]
  • It feels like a short term solution specifically to fix the reaction issue
• Create a new DSNP Announcement URI targeting Announcements
  • Use a hash of the announcement
  • Nice in that it has the minimum amount of data
  • Harder to discover
• Update Reactions to not use tombstones and to work more like graph and tombstones still use DSNP Content URI

That last option might be better stated by this:

Tombstones are `Content Tombstones`. Announcements are never deleted or tombstoned. Tombstones do not (as it currently says in the spec) revoke a signature, they target external content for.

Content Tombstones say you can delete dsnp://[dsnp user id]/[DSNP Content Hash]. That also implies that the announcements of said content should be marked with that information. (and potentially hidden)

I think I like this characterization. It provides a clear line between DSNP Content URIs and Content Tombstones.

It forces a different solution for reactions (likely a 1 bit flag for "remove reaction"). However that removes a layer of nesting. Instead of search for all reactions, then search for tombstones for each reaction, it is merely search for all reactions and resolve.

[aramikm]

@wilwade I think Content URI based on current spec is not going to be unique for the same user sending the same post to different people.

So in that context Tomb stoning a Content will cause a lot of issues instead of Tomb Stoning Announcements. (Same applies to Edits). We can mitigate this either by making sure Activity Stream will have a required unique value like timestamp or nonce in it so the generated Content URI will be unique for the same Content from the same user or just target Announcement instead of Content

[wilwade]

required unique value like timestamp or nonce in it so the generated Content URI will be unique for the same Content

@aramikm I think I would be ok with requiring a published timestamp in Activity Content to make content "default" unique.

[saraswatpuneet]

@wilwade does delegating and removing a delegate is considered tombstoning? especially when third party is proxies on behalf of a delegate service, ideally should services/third party be made aware before they publish batch which will fail due to first check

[wilwade]

@wilwade does delegating and removing a delegate is considered tombstoning? especially when third party is proxies on behalf of a delegate service, ideally should services/third party be made aware before they publish batch which will fail due to first check

I don't think so?

In the current spec, you can revoke a delegation in the past. We've discussed in the past if we wanted to disallow that option. And instead someone would undelegate and then tombstone or reverse any actions that they wanted to remove in the past.

There still would be a need to allow some slippage for batch validation I think. Not that the announcement would be valid, but that the batch wouldn't fail validation if just one block earlier (a block that the delegate might not have known about) is what undelegated.

We should add that to the spec. @saraswatpuneet could you write up that DIP?

[saraswatpuneet]

@wilwade sure on it.