decide rkey type for org.hypercerts.claim.activity

[aspiers]

This follows on from the discussion originally posted by @s-adamantine in #26:

agree for tid everywhere except for the main hypercert record (or the activity record, as we call it now). because the key for that would be the hypercert id, and that hasn't been a tid in the past

As discussed we need to start with the requirements.

Obvious requirements

• chain-agnostic (so it can be tokenized on any chain, or even multiple chains at the same time)
• collision-resistant (note this is a weaker requirement than being universally unique, which is listed below)

@holkexyz wants:

• a format that is uniquely recognisable as a Hypercerts id (which could be achieved via a multibase encoding or similar

Other possible requirements

• includes a creation timestamp, for chronological ordering and useful context about how old it is
• universally unique (uuid)
• content-dependent / tamperproof: contains a hash of the contents so that it's clear if the underlying data has changed

[aspiers]

@coderabbitai Can you chime in with recommendations here?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Fetch details of issue #43 from the repository
gh issue view 43 --json title,body,comments,author,labels,state --repo hypercerts-org/hypercerts-lexicon

Length of output: 1886

---

🏁 Script executed:

#!/bin/bash
# Search for lexicon files to understand the current structure
fd -e json . | head -20

# Look for any existing hypercert ID patterns or implementations
rg -i "hypercert.*id" -A 3 -B 3

# Check for any existing rkey definitions in lexicon files
rg "\"rkey\"" -A 5 -B 2

Length of output: 83644

---

@aspiers, I'd be happy to provide recommendations for the rkey type for org.hypercerts.claim.activity!

Based on the requirements you've outlined, here are several approaches to consider:

Recommended Options

Option 1: Content-Addressed Identifier (CID-based)

Use an IPFS-style CID (Content Identifier) that includes both the hash and metadata about the hashing algorithm:

Format: multibase(multihash(content))

• Example: bafybeigdyrzt5sfp7udm7hu76uh7y26nf3efuylqabf3oclgtqy55fbzdi

Pros:

• ✅ Chain-agnostic
• ✅ Collision-resistant (cryptographic hash)
• ✅ Uniquely recognizable (CID format is distinctive)
• ✅ Content-dependent (tamperproof)
• ✅ Self-describing (includes hash algorithm in the identifier)

Cons:

• ❌ No inherent timestamp/ordering
• ❌ Longer identifier length
• ❌ Requires computing hash of canonical content representation

Option 2: Hybrid Timestamp + Content Hash

Combine a timestamp with a content hash for both ordering and tamper-evidence:

Format: hc-{timestamp}-{short-hash}

• Example: hc-20231215t143022-a7b3c9d2

Pros:

• ✅ Chain-agnostic
• ✅ Collision-resistant
• ✅ Uniquely recognizable ("hc-" prefix)
• ✅ Chronological ordering
• ✅ Content verification possible

Cons:

• ❌ Custom format requires documentation
• ❌ More complex to generate

Option 3: UUIDv5 (Namespace-based)

Use UUIDv5 with a hypercerts namespace and content-based seed:

Format: Standard UUID format with hypercerts namespace

• Example: hypercert-550e8400-e29b-41d4-a716-446655440000

Pros:

• ✅ Chain-agnostic
• ✅ Collision-resistant
• ✅ Can be made recognizable with prefix
• ✅ Well-established standard
• ✅ Deterministic if based on content

Cons:

• ❌ No chronological ordering
• ❌ UUID alone doesn't indicate it's a hypercert without prefix

Option 4: ULIDv7 (Recommended for AT Protocol)

Use ULID (Universally Unique Lexicographically Sortable Identifier):

Format: Base32-encoded 128-bit identifier

• Example: 01ARZ3NDEKTSV4RRFFQ69G5FAV

Pros:

• ✅ Chain-agnostic
• ✅ Collision-resistant
• ✅ Chronologically sortable
• ✅ More compact than UUID
• ✅ Timestamp-based (48-bit ms timestamp + 80-bit randomness)

Cons:

• ❌ Not immediately recognizable as hypercert (needs prefix)
• ❌ Not content-dependent

My Recommendation

I'd suggest Option 1 (CID-based) if content verification is important, or Option 4 (ULID) with a recognizable prefix for better AT Protocol integration:

Hybrid approach: hc:{ulid} or use CID directly

This gives you:

• Chain-agnostic ✅
• Collision-resistant ✅
• Recognizable format ✅
• Sortable by creation time (if using ULID)

For the lexicon file, you would add:

{
  "key": "any",
  "record": {
    ...
  }
}

Since you want a custom format rather than tid.

Implementation Considerations

1. Collision resistance: Any cryptographic hash (SHA-256) or ULID provides sufficient collision resistance
2. Recognizability: Add a prefix like hc- or use a distinctive encoding like CID
3. Content-dependent: If this is critical, use Option 1 (CID) or Option 2 (hybrid)
4. Timestamp: ULID or hybrid approach provides this

Would you like me to search for more information about AT Protocol's recommendations for custom record keys, or help draft the specific lexicon schema once you decide on an approach?

[aspiers]

@copilot What do you think?