Add support for FEP-ef61
for creating server indepent fediverse applications
This FEP are depend on 8b32 which already available in Fedify
Implementation plan
The following implementation plan was added by @dahlia after reviewing FEP-ef61 and the related sub-issues. It describes the intended scope for the first Fedify implementation pass.
FEP-ef61 support will be implemented as a set of smaller, dependency-tracked issues under this issue. The first stage is the portable identifier layer: Fedify needs to accept ap: and ap+ef61: URI schemes in vocabulary codecs (#826), canonicalize and compare those identifiers consistently (#828), convert between canonical portable IDs and gateway-compatible HTTP(S) IDs (#833), and expose Context helpers for constructing portable actor and object IDs without hand-built strings (#841).
The next stage is authentication and trust. Portable objects rely on Object Integrity Proofs rather than HTTP origin ownership, so Fedify needs did:key verification method resolution (#827), FEP-fe34 cryptographic origins for portable IDs (#829), a portable object proof policy (#832), and a concrete HTTP Signature key model for gateways acting on behalf of portable actors (#840).
Vocabulary and media support can proceed alongside that foundation. Fedify needs the FEP-ef61 vocabulary terms, including gateways and portable media-related properties (#830), plus SHA-256 digestMultibase and hashlink helpers (#831). Gateway media serving for hashlink-addressed resources is tracked separately in #838.
Once those pieces are in place, the gateway behavior can be built on top of existing Fedify APIs. Gateway dereferencing should integrate with generated vocabulary dereferencing accessors (#834). Local portable object serving should reuse existing object dispatchers instead of introducing a parallel dispatcher model (#835). Portable inbox delivery should route into the existing inbox dispatcher/listener pipeline and handle gateway forwarding without a new public inbox API (#839).
The remaining compatibility work covers the places where portable actors need to interoperate with ordinary ActivityPub software. Fedify needs a trust policy for unsecured portable collections (#836) and WebFinger behavior for portable actors whose WebFinger host comes from the first gateway rather than the actor ID host (#837).
Scope
The first implementation pass should cover the core portable object model: portable IDs, proof verification, cryptographic origins, vocabulary terms, compatible identifiers, gateway dereferencing, local gateway serving, hashlink media serving, portable inbox delivery, collection trust policy, WebFinger adaptation, and the HTTP Signature key model needed for gateway requests.
This first pass intentionally does not include FEP-ae97 outbox posting, actor registration, gateway discovery, media upload/delete APIs, automatic storage for portable actors or objects, general-purpose gateway registration, key rotation workflows, or support for DID methods beyond did:key.
Those items can be added later as follow-up work once the core FEP-ef61 behavior is in place.
Add support for FEP-ef61
for creating server indepent fediverse applications
This FEP are depend on 8b32 which already available in Fedify
Implementation plan
The following implementation plan was added by @dahlia after reviewing FEP-ef61 and the related sub-issues. It describes the intended scope for the first Fedify implementation pass.
FEP-ef61 support will be implemented as a set of smaller, dependency-tracked issues under this issue. The first stage is the portable identifier layer: Fedify needs to accept
ap:andap+ef61:URI schemes in vocabulary codecs (#826), canonicalize and compare those identifiers consistently (#828), convert between canonical portable IDs and gateway-compatible HTTP(S) IDs (#833), and expose Context helpers for constructing portable actor and object IDs without hand-built strings (#841).The next stage is authentication and trust. Portable objects rely on Object Integrity Proofs rather than HTTP origin ownership, so Fedify needs
did:keyverification method resolution (#827), FEP-fe34 cryptographic origins for portable IDs (#829), a portable object proof policy (#832), and a concrete HTTP Signature key model for gateways acting on behalf of portable actors (#840).Vocabulary and media support can proceed alongside that foundation. Fedify needs the FEP-ef61 vocabulary terms, including
gatewaysand portable media-related properties (#830), plus SHA-256digestMultibaseand hashlink helpers (#831). Gateway media serving for hashlink-addressed resources is tracked separately in #838.Once those pieces are in place, the gateway behavior can be built on top of existing Fedify APIs. Gateway dereferencing should integrate with generated vocabulary dereferencing accessors (#834). Local portable object serving should reuse existing object dispatchers instead of introducing a parallel dispatcher model (#835). Portable inbox delivery should route into the existing inbox dispatcher/listener pipeline and handle gateway forwarding without a new public inbox API (#839).
The remaining compatibility work covers the places where portable actors need to interoperate with ordinary ActivityPub software. Fedify needs a trust policy for unsecured portable collections (#836) and WebFinger behavior for portable actors whose WebFinger host comes from the first gateway rather than the actor ID host (#837).
Scope
The first implementation pass should cover the core portable object model: portable IDs, proof verification, cryptographic origins, vocabulary terms, compatible identifiers, gateway dereferencing, local gateway serving, hashlink media serving, portable inbox delivery, collection trust policy, WebFinger adaptation, and the HTTP Signature key model needed for gateway requests.
This first pass intentionally does not include FEP-ae97 outbox posting, actor registration, gateway discovery, media upload/delete APIs, automatic storage for portable actors or objects, general-purpose gateway registration, key rotation workflows, or support for DID methods beyond
did:key.Those items can be added later as follow-up work once the core FEP-ef61 behavior is in place.