Skip to content

add eris and ssb to chart, no reference in article copy #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
bumblefudge wants to merge 1 commit into from
Closed

add eris and ssb to chart, no reference in article copy #4

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 18 additions & 10 deletions _posts/2026-09-09-identifiers-and-activitypub.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -226,17 +226,19 @@ There will always be other networks and other protocols, but ours gets more powe
Note: these are the variously content-addressing-based identifier schemes I'm most familiar with, from my time working for the IPFS Foundation and Decentralized Identity Foundation.
A more exhaustive list would take more time to prepare than this whole article took to write, and while I might have missed one or two good options for ActivityPub, I stand behind these as the bulk of a list of options worth considering.

|type|URI scheme|normref|pros|cons|
|type|URI scheme|resolution+deref algorithms|normref|pros|cons|
|---|---|---|---|---|
|ni://|yes, IANA-registered, simple /.well-known/ system|IETF [RFC 6920]|low complexity, zero-dep implementable|limited range of hash functions|
|ipfs://|yes, but very complex and likely needs to be profiled via regexp to reduce security surface for AP use cases|no hope of normref|"kitchen-sink", can handle many different use-cases and extensions, e.g. virtual file system, toxic/DMCA content blocklist built-in, etc.|quite complicated, requires separate DHT and/or trustful HTTPS routing to dereference, an additional chatty protocol to host, content-type must be passed out of band for type safety|
|magnet://|yes, stable and versioned|stable community spec and impls but no normref|less complicated, diverse implementations|requires separate DHT protocol to dereference and/or host, content-type much be passed out of band for type safety, no built-in affordances for tracking/blocklisting toxic or DMCA payloads|
|`digestMultibase`|no|stable, W3C normref|low complexity, zero-dep implementable; works more like SRI than rest of this list, i.e. provides a stable syntax for passing hash alongside URL as part of link object|limited range of hash functions|
|[hashlink]|yes|stable, but unlikely to get normative status|very simple syntax for expressing hash in query parameter of URLs|query parameters not ideal in every use-case, can get lost in transport, etc.|
|at://|current scheme is URL-spec non-conformant|iterating (slowly) in IETF|uses individual user's DIDs as "authority" component, for now at least|requires trustful and/or complex resolution (merkel tree walking), non-normative CBOR serialization, all events fully-public and non-repudiable|
|[DID URLs] (in general)|per-method|DID URL is ratified, DID Resolution (debatably on critical path) still unstable|portable|resolution, security all depend on the specific method used|
|DID URLs ([webvh])|yes, simple /.well-known/ translation|low complexity, zero-dep implementation|some complexity around witnessing to be 100% tamper-evident against malicious servers (requires something like soatak's key transparency system)|
|[UUIDv5]|no|IETF [RFC 9562]|takes a URL as input and turns it into an opaque UUID (but can be verified if you know the original URL)|not a *content*-identifier, just a one-way commitment to the URL itself|
|ni://|yes, IANA-registered, simple /.well-known/ system|HTTPS GET on authority-hint with /.well-known/ query on known caching servers as fallback|IETF [RFC 6920]|low complexity, zero-dep implementable|limited range of hash functions|
|ipfs://|yes, but very complex and likely needs to be profiled via regexp to reduce security surface for AP use cases|many round-trips, some unknowable timing|no hope of normref|"kitchen-sink", can handle many different use-cases and extensions, e.g. virtual file system, toxic/DMCA content blocklist built-in, etc.|quite complicated, requires separate DHT and/or trustful HTTPS routing to dereference, an additional chatty protocol to host, content-type must be passed out of band for type safety|
|magnet://|yes, stable and versioned|special side-protocol on standard endpoint on authority-hint(s) provided in query params with known indexing servers as fallback|stable community spec and impls but no normref|less complicated, diverse implementations|requires separate DHT protocol to dereference and/or host, content-type much be passed out of band for type safety, no built-in affordances for tracking/blocklisting toxic or DMCA payloads|
|`digestMultibase`|no|no|stable, W3C normref|low complexity, zero-dep implementable; works more like SRI than rest of this list, i.e. provides a stable syntax for passing hash alongside URL as part of link object|limited range of hash functions|
|[hashlink]|yes|deref as normal but with checksum in hand at the end|stable, but unlikely to get normative status|very simple syntax for expressing hash in query parameter of URLs|query parameters not ideal in every use-case, can get lost in transport, etc.|
|at://|current scheme is URL-spec non-conformant|very straightforward, similar to DID URL default behavior (dereference DID, transform rest of URL to PDS-based to dereference)|iterating (slowly) in IETF|uses individual user's DIDs as "authority" component, for now at least|requires trustful and/or complex resolution (merkel tree walking), non-normative CBOR serialization, all events fully-public and non-repudiable|
|[DID URLs] (in general)|per-method URN scheme + base/default DID URL pathing behavior|per-method (resolve DID Doc before deref path/params)|DID URL is ratified, DID Resolution (debatably on critical path) still unstable|portable|resolution, security all depend on the specific method used|
|DID URLs ([webvh])|yes, specified URN scheme + a simple /.well-known/ translation for URL fallback|clearly specified in method spec|v1.0 at DIF, on shortlist for W3C DID Methods|low complexity, zero-dep implementation|some complexity around witnessing to be 100% tamper-evident against malicious servers (requires something like soatak's key transparency system)|
|[UUIDv5]|no|IETF [RFC 9562]|no|takes a URL as input and turns it into an opaque UUID (but can be verified if you know the original URL)|not a *content*-identifier, just a one-way commitment to the URL itself|
|[eris]|URN-only|[straightforward urn-->deref algo][eris-http]|no but [spec stable since 2022 and community tooling](https://eris.codeberg.page/eer/)|interesting deduplication/tracking-avoidant feature ("convergence secret", i.e. arbitrary hash salt to produce new identifiers for tracked content); DNSLink system like IPFS; has an SSB-like append-only mode per publisher; has its own RFC Canonicalization for content-addressing RDF recrods|no way of preserving or tracking content-type; no identity-awareness or built-in metadata layer|
|[secure scuttlebutt log][ssb]|[urn only][ssb uri], no authorities in TCP sense|locating is the tricky/OOB part, dereferencing deterministic once you have the bytes|unlikely|per-publisher append-only non-repudiable log|key rotation not possible; much discovery is OOB/underspecified by web standards|

## References

Expand All @@ -245,6 +247,8 @@ A more exhaustive list would take more time to prepare than this whole article t
* [DID Spec][DIDs]
* [DID Spec: DID URL syntax][DID URLs]
* [did:webvh typescript ref impl][didwebvh-ts]
* [ERIS content-addressing specification][eris]
* [ERIS over HTTP specification][eris-http]
* [Fedify AcitivityPub library in TS][fedify]
* [FEP-cd47: Federation-friendly Addressing and Deduplication Use-Cases¶][FEP-cd47]
* [FEP-73cd: Migration User Stories][FEP-73cd]
Expand All @@ -266,6 +270,8 @@ A more exhaustive list would take more time to prepare than this whole article t
[DIDs]: https://w3c.github.io/did/
[DID URLs]: https://www.w3.org/TR/did/upcoming/#did-url-syntax
[didwebvh-ts]: https://github.com/decentralized-identity/didwebvh-ts
[eris]: https://eris.codeberg.page/
[eris-http]: https://eris.codeberg.page/eer/http.xml
[fedify]: https://github.com/fedify-dev/fedify
[FEP-cd47]: https://fediverse.codeberg.page/fep/fep/cd47/
[FEP-73cd]: https://fediverse.codeberg.page/fep/fep/73cd/
Expand All @@ -277,6 +283,8 @@ A more exhaustive list would take more time to prepare than this whole article t
[RFC 6920]: https://datatracker.ietf.org/doc/html/rfc6920
[RFC 9562]: https://www.rfc-editor.org/info/rfc9562/
[sri]: https://www.w3.org/TR/sri-2/
[ssb]: https://ssbc.github.io/scuttlebutt-protocol-guide/#feeds
[ssb uri]: https://github.com/ssbc/ssb-uri-spec#list
[TIDs]: https://learningproof.github.io/tid-i-d/draft-goldman-tid.html
[UUIDv5]: https://www.rfc-editor.org/info/rfc9562/#section-5.5
[vcdi]: https://www.w3.org/TR/vc-data-integrity/
Expand Down
Loading