@silverpill @steve @raucao The only thing I can really suggest is dropping the use of the prefix mechanism by undefining the `as` term, then rewriting all other term definitions to not use the `as:` prefix. This might make sense since the media type nominally guarantees the meaning of certain terms, and you really shouldn't define your own custom terms in the `as:` namespace, so maybe it's okay to say that no one should ever use `as:`. Is that the resolution you'd prefer?

@silverpill @steve @raucao <Note> is <as:Note> is <https://www.w3.org/ns/activitystreams#Note>, but only "Note" is consistent with compacted JSON-LD.

Fundamentally, identifiers are expressed in different ways depending on context. The prefix mechanism produces compact URIs, which are still intrinsically URIs despite their lexical form not being a valid URI. If you care about referents, you need to expand them.

"as:Public" is canonical for object properties (type:id). Disliking this fact doesn't make it untrue.

@silverpill @raucao no requirements are being changed here. "the identifier is foo" does not mean "the identifier MUST always be expressed using the literal sequence of characters f, o, o".

speaking of requirements, please read the first sentence of https://www.w3.org/TR/activitystreams-core/#jsonld and note the MUST.

"as:Public should be banned" is completely uncalled for.

and you currently need to special-case the full URI too! this is because it is not a real object. the real mistake is addressing Public at all.

@pfefferle @julian @bengo @csarven @raucao @oblomov

i think the context is this github issue: https://github.com/w3c/activitypub/issues/320

was put to the swicg mailing list as a cfc by evan: https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0038.html

bengo requested a clear "error description" and "candidate correction": https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0039.html

to clarify, no requirements are being removed: https://lists.w3.org/Archives/Public/public-swicg/2025Jun/0043.html

i agree that cfc emails should include an "error description" and "candidate correction". perhaps https://github.com/w3c/activitypub/issues/320#issuecomment-2971191447 suffices?

@julian mods can delete a thread, right? this doesn't necessarily delete all posts in the thread, but they do become orphans

controversial protocol goals for a more conversational fedi:
- you should be able to create explicit threads instead of a loose reply tree
- you should be able to follow a thread without following any people or groups
- you should be able to delete a thread and have all posts declaring that thread as a context be marked as orphans to be garbage-collected
- you should be able to participate in a thread remotely, like commenting on github issues via email