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

smoking weed and getting so high that you start speaking hieroglyphics, call that getting rosetta stoned

@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 unrelated to the post, but the links to the FEPs are malformed and seem to be missing the https: scheme

is this mf fortune cookie calling me a liar

@julian are you sending accept application/json or accept application/jrd+json instead of accept application/activity+json?

@puppygirlhornypost2 @thisismissem @julian more generally, the concept of an "instance actor" isn't well-defined

what most softwares call an "instance actor" is really more of a proxy actor, used primarily to sign fetches, not necessarily representing the service itself. i don't know why you'd want to discover such an actor outside of an http signature processing context. if you wanted to have a Service actor it would probably be best exposed via a specific link relation or rdf/jsonld predicate

@thisismissem @julian this assumes that the base url is the instance actor, which it might not be