Publish portable objects with compatible identifiers as their IDs

[dahlia]

Background

FEP-ef61 lets publishers use a compatible identifier, such as https://gw.example/.well-known/apgateway/did:key:z6Mk…/actor, as the id of a portable object for software that cannot handle ap: URIs. tootik identifies all its portable actors this way. #1093 made Fedify authenticate such documents when it receives them, but its publishing side still treats only ap: and ap+ef61: IDs as portable.

mapPortableActorId() already accepts a compatible identifier, so an application can give a portable actor one. Several publishing paths then treat that actor as an ordinary one:

• Context.sendActivity() applies the portable activity rules only to ap: IDs (isPortableUrl() in packages/fedify/src/federation/outgoing-proof.ts). It neither requires the activity's ID to belong to the actor's DID nor restricts the proof to the DID's key, so it can send activities that receivers following FEP-ef61, including Fedify since Treat compatible-ID documents as portable documents #1093, reject.
• Serving a portable object through a gateway returns 404 Not Found when the dispatched object's ID is a compatible identifier, as isRequestedPortableObject() in packages/fedify/src/federation/handler.ts accepts only ap: IDs.
• WebFinger takes a portable actor's host from its first gateway only when its ID is an ap: URI (packages/fedify/src/federation/webfinger.ts).
• The actor dispatcher warns that such an actor's ID does not match Context.getActorUri() (packages/fedify/src/federation/builder.ts).

Proposed work

Treat an actor or object whose ID is a compatible identifier as portable on the publishing side, consistently with how #1093 treats it on receipt:

• apply the portable activity rules of sendActivity() to compatible IDs, comparing DIDs rather than gateways;
• serve a dispatched object whose ID is a compatible identifier of the requested portable object;
• base WebFinger on the first gateway for such actors;
• skip the ID mismatch warning for them.

Design questions

• Should Fedify encourage publishing with compatible IDs at all, or only support it for applications that must interoperate with software without ap: support?
• FEP-ef61 says publishers must use the first gateway in the actor's gateways when constructing compatible identifiers. Should sendActivity() or the dispatchers check that?
• Should the Context helpers from Context helpers for FEP-ef61 portable IDs #841 also construct compatible identifiers, or stay limited to portable IDs?

Scope

This issue covers publishing Fedify's own actors and objects with compatible identifiers as their IDs. It does not include how receivers authenticate them (#1093) or arbitrary gateway paths.

Tests

• sendActivity() rejecting an activity of a compatible-ID actor whose ID names another DID, and signing it only with the DID's key;
• serving an object whose ID is a compatible identifier, on the gateway it names and on another one;
• WebFinger for a compatible-ID actor;
• a Fedify inbox accepting what Fedify sends for a compatible-ID actor.