Background

The org.hypercerts.claim.activity lexicon has its record key set to any, meaning ATProto will accept any rkey value. The question was: what format should this rkey take, given it effectively serves as the Hypercert ID?

This was originally raised in hypercerts-lexicon#26 (inconsistent rkey types across lexicons) and split out into hypercerts-lexicon#43 specifically for the activity claim.

Holke's question:

The key is any for an activity claim. I assume the SDK would define the key correctly then. How do we make sure that other hypercerts get the correct hypercerts ID as well? and no doubles?

Requirements

Must have:

• Chain-agnostic (tokenizable on any chain, or multiple simultaneously)
• Collision-resistant
• Uniquely recognisable as a Hypercerts ID (e.g. via a prefix)
• Stable — works forever

Nice to have:

• Content-dependent / tamperproof (hash of contents)
• Includes creation timestamp for ordering
• Universally unique

Considerations

• If we allow crosschain bridging of Hypercerts tokens in the future, then it’s not possible to have a Hypercerts ID which uniquely refers to both the offchain activity claim and the specific chain it’s located on, because the chainId would change, requiring an update of the id which defeats the stability requirement. This suggests that we need different versions of the id for offchain vs. onchain.
• For Hypercerts on ATProto, we can just use both strong and weak references as appropriate (depending on data immutability requirements)
• For tokenized Hypercerts, we can use whatever is needed to uniquely identify the onchain digital twin of the ATProto activity claim. This would need to involve at least one chainId to indicate where the token was minted, and possibly a second if bridging tokens between chains is later supported. In that case maybe you could refer to a token both via "here's where a Hypercert was originally tokenized" and "here's where this Hypercert token currently lives".

Decision