From fb82565a66b5373b109deaa732cdfb27b4d963ce Mon Sep 17 00:00:00 2001 From: bumblefudge Date: Mon, 14 Sep 2026 10:41:47 +0200 Subject: [PATCH] add eris and ssb to chart, no reference in article copy --- .../2026-09-09-identifiers-and-activitypub.md | 28 ++++++++++++------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/_posts/2026-09-09-identifiers-and-activitypub.md b/_posts/2026-09-09-identifiers-and-activitypub.md index 5f944de7d33d..2c627bc51f3c 100644 --- a/_posts/2026-09-09-identifiers-and-activitypub.md +++ b/_posts/2026-09-09-identifiers-and-activitypub.md @@ -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 @@ -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] @@ -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/ @@ -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/