Some servers require authentication for all requests made via ActivityPub, even for GET requests on public objects addressed to as:Public. This violates the requirement that anything addressed to as:Public is made available without requiring authentication. This FEP proposes an alternative addressing that may be used in such scenarios, signaling that the object is not fully public but is otherwise available to any actor.
…then the full IRI is the only valid representation (since any term defined will not be expanded properly)
if this change is made:
if no shorthand term is defined:
…then the full IRI is the only valid representation (since there is no shorthand term defined)
if a shorthand term is defined:
if the context is used:
…then the compacted document will use the shorthand term (since the change was made and there is a shorthand term in the context used)
if the context is not used:
…then the compacted document will use the full IRI (since even though the change was made and the shorthand term was defined, that context was not used)
so it seems like in most cases you would essentially only have to check for the full IRI, but in the event that the change is made + a term is defined + that context is used, plain JSON consumers will have to check for either/both the full IRI and also the shorthand term. for this reason i’m hesitant to define a term / make a context document asset for this FEP. it would be simpler/easier not to, and in some ways it would be replicating what is very likely a mistake or regretful approach of the current spec in regards to how it handles the Public mapping. doubtless the whole issue of Public == as:Public == https://www.w3.org/ns/activitystreams#Public would simply not exist had it never been tried – just check for the full IRI and nothing else, and you’re done.
This would add the next special URI https://indexable.example. Next, maybe I want posts one is not allowed to share, so I add the special URI https://notshareable.example, and so on…
Conclusion: We combined two things, for no obvious benefit, but a clear detriment: Creating another aspect of ActivityPub parsing that is non trivial. As I already consider parsing ActivityPub objects too complicated, I would prefer another approach.
the reasoning for using the addressing properties is that 1) it will trigger certain heuristics like mastodon marking the status as “limited visibility”, 2) i’m not sure replacing Public addressing with a different mechanism is worth it. we could for example try to replace Public with something like Web Access Control but that would require a lot more buy-in.
as for parsing, you would just ignore any addressees that don’t resolve, no?