@silverpill 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.