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: #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

• DIP-148 Rename DSNP Announcement URI to DSNP Content URI #148
• DIP-149 Reaction Retraction #149
• DIP-150 Update spec to include details of un-delegation on past data/batches #150
• DIP-180 Tombstones Target contentHash #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.