Just filed sub-issues for FEP-ef61:

• #826 Support ap: and ap+ef61: URI schemes in vocabulary codecs
• #827 Resolve did:key verification methods for Object Integrity Proofs
• #828 Canonicalize and compare ap:/ap+ef61: URIs
• #829 Support cryptographic origins for ap:/ap+ef61: URIs
• #830 FEP-ef61 vocabulary terms
• #831 SHA-256 digestMultibase helpers for portable media
• #832 FEP-ef61 proof policy for portable objects
• #833 Compatible FEP-ef61 identifiers for portable objects
• #834 Gateway dereferencing for portable vocabulary references

If you're interested in this work you can subscribe umbrella issue #288.

@hongminhee@hollo.social luck wished! Are you going to use more than did:key though?

@hongminhee

Subscribed to all of them

For Fedify, we should treat ap+ef61: as the canonical portable-object scheme going forward

Why?

I am open to changing the recommended scheme but my implementation doesn't support ap+ef61 yet.

There are other options as well: ap+portable, ap+nomad.

@silverpill@mitra.social Mostly because ap: is a very broad scheme name.

If ap: becomes the long-term ActivityPub portable identifier scheme, that is fine, and Fedify should support it. The concern is that FEP-ef61 is still a draft, and making a library emit ap: as the canonical form today can make the current draft semantics look more settled, and more general, than they are.

ap+ef61: has a narrower meaning: this is the portable-object URI model defined by FEP-ef61. That gives implementations room to experiment with the current DID authority, gateway dereferencing, compatible ID, and proof-policy rules without implicitly claiming the whole ap: scheme for this exact design. It also avoids a possible future conflict if ap: is later standardized with slightly different semantics.

This is not a strong objection to ap: itself. Fedify should accept ap: because the current FEP requires it, and interoperability with existing implementations matters more than a local naming preference. My current thinking is:

• accept both ap: and ap+ef61:;
• canonicalize them through the same comparison algorithm;
• emit ap+ef61: for newly generated portable IDs while the FEP is still draft, unless the FEP settles on ap: or another scheme;
• keep this easy to change if the FEP chooses ap:, ap+portable:, ap+nomad:, or something else.

Between the alternatives, ap+ef61: is precise but tied to the FEP number. ap+portable: or ap+nomad: would be better if the goal is a stable human-readable scheme name. I do not have a strong preference there.

The main point is that a draft-specific or portable-specific scheme feels safer than treating the generic ap: scheme as permanently settled before the FEP reaches consensus.

@hongminhee

Okay, this makes sense. I updated my implementation to support ap+ef61 scheme and also updated the FEP:

https://codeberg.org/fediverse/fep/pulls/872/files

Both schemes are allowed, but ap is RECOMMENDED. I don't expect the semantics to change. The most controversial part is the authority, which makes 'ap' URIs not compliant with RFC-3986, but I believe that we should push for the standardization of DID authorities. Plain DIDs are easier to read and you can copy-paste them without decoding. As far as I know, #atproto people also don't intend to encode their URI authorities.