You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
FEP-ef61 identifies portable actors and objects with ap: URIs whose authority component is a DID. Fedify plans to use ap+ef61: as its canonical portable-object scheme while still accepting ap: where needed.
Applications should not have to hand-build these identifiers by string concatenation. Fedify already provides context helpers such as Context.getActorUri() and Context.getObjectUri() for ordinary ActivityPub IDs. Portable objects need the same kind of ergonomic and consistent API, especially once object dispatchers, inbox delivery, gateway serving, compatible identifiers, and proof generation all need to agree on the same IDs.
This issue is about adding Context-level helpers for constructing FEP-ef61 portable IDs, backed by lower-level DID and portable URI helpers where needed.
Proposed work
Add public helpers for constructing portable actor and object IDs from Fedify context.
The exact API should be decided during implementation, but likely candidates include:
deciding the public helper names and return types;
returning URL objects, consistent with Fedify's existing URI APIs;
generating canonical ap+ef61: IDs;
accepting or deriving the DID authority used for the portable actor or object;
making sure the internal representation remains compatible with JavaScript's URL class even when the canonical serialized form contains an unescaped DID authority;
reusing the same URI Template paths as existing actor and object dispatchers where possible;
making the helpers usable from ordinary request contexts and from FEP-ef61 gateway request contexts;
defining how these helpers relate to Context.getActorUri() and Context.getObjectUri();
providing lower-level helpers for converting an Ed25519 public key to a did:key identifier if that is needed for the Context API;
using base58-btc did:key identifiers and the correct multicodec prefix for Ed25519 keys;
avoiding base64url did:key generation for portable actors;
integrating with compatible FEP-ef61 identifier conversion.
These helpers should produce portable IDs only. Conversion to gateway-compatible HTTP(S) identifiers should remain part of the compatible identifier helpers.
Design questions
The implementation should settle these API details before finalizing the code path:
Should the public API use Portable names or Ef61 names?
Should actor helpers accept an actor identifier, a DID authority, a public key, or some combination of these?
Should object helpers require an explicit DID authority outside an FEP-ef61 gateway request?
How should the current portable DID authority be exposed inside gateway request contexts?
Should helper output serialize as canonical ap+ef61://did:key:.../... when converted to a string, even if the internal URL representation percent-encodes the DID authority?
Should low-level did:key generation live in @fedify/vocab-runtime, @fedify/fedify, or both with different API layers?
How should these helpers interact with Object Integrity Proof generation so the proof verificationMethod matches the portable ID authority?
Background
FEP-ef61 identifies portable actors and objects with
ap:URIs whose authority component is a DID. Fedify plans to useap+ef61:as its canonical portable-object scheme while still acceptingap:where needed.Applications should not have to hand-build these identifiers by string concatenation. Fedify already provides context helpers such as
Context.getActorUri()andContext.getObjectUri()for ordinary ActivityPub IDs. Portable objects need the same kind of ergonomic and consistent API, especially once object dispatchers, inbox delivery, gateway serving, compatible identifiers, and proof generation all need to agree on the same IDs.This issue is about adding Context-level helpers for constructing FEP-ef61 portable IDs, backed by lower-level DID and portable URI helpers where needed.
Proposed work
Add public helpers for constructing portable actor and object IDs from Fedify context.
The exact API should be decided during implementation, but likely candidates include:
or, if the FEP number should be explicit in the API:
The work should include:
URLobjects, consistent with Fedify's existing URI APIs;ap+ef61:IDs;URLclass even when the canonical serialized form contains an unescaped DID authority;Context.getActorUri()andContext.getObjectUri();did:keyidentifier if that is needed for the Context API;did:keyidentifiers and the correct multicodec prefix for Ed25519 keys;did:keygeneration for portable actors;These helpers should produce portable IDs only. Conversion to gateway-compatible HTTP(S) identifiers should remain part of the compatible identifier helpers.
Design questions
The implementation should settle these API details before finalizing the code path:
Portablenames orEf61names?ap+ef61://did:key:.../...when converted to a string, even if the internalURLrepresentation percent-encodes the DID authority?did:keygeneration live in@fedify/vocab-runtime,@fedify/fedify, or both with different API layers?verificationMethodmatches the portable ID authority?Scope
This issue is only about constructing portable actor and object IDs from Fedify APIs.
It does not include:
Dependencies
This should depend on the lower-level portable URI and compatible identifier work under #288:
ap:andap+ef61:URI schemes in vocabulary codecs #826 forap:/ap+ef61:URI support in vocabulary codecs;ap:/ap+ef61:URIs #828 for portable URI canonicalization and comparison;It should also inform #835, because object gateway serving should use the same portable object ID construction rules.
Tests
Add regression tests for FEP-ef61 portable ID helpers.
The tests should cover:
ap+ef61:scheme;URLobjects from the public helpers;URLcompatibility for DID authorities containing reserved characters;did:keyidentifier from an Ed25519 public key if that helper is included;did:keyidentifiers;did:keygeneration;Context.getActorUri()andContext.getObjectUri()behavior.This should be added as a sub-issue of #288.