@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:andap+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 onap: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.
