洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

Or, just use a proper JSON-LD processor altogether. Of course, there would be a performance penalty. The spec explicitly allows as:Public or bare Public for public addressing in to/cc, etc., but surprisingly many implementations don't handle this. All of this would actually be solved by using a JSON-LD processor.

w3.org

ActivityPub

The ActivityPub protocol is a decentralized social networking protocol based upon the [ActivityStreams] 2.0 data format. It provides a client to server API for creating, updating and deleting content, as well as a federated server to server API for delivering notifications and content.

2 replies

洪 民憙 (Hong Minhee) :nonbinary:
@hongminhee@hollo.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

Honestly, I don't really care what strategy other implementations follow to comply with the spec. (I solved it in by just using a proper JSON-LD processor.) It's just a bit annoying that I always send valid JSON-LD documents, but whenever I encounter an interoperability bug where the other side can't process them, I'm the one who has to send them a patch to fix it. 😩

infinite love ⴳ
@trwnh@mastodon.social · Reply to 洪 民憙 (Hong Minhee) :nonbinary:

@hongminhee It's subtly more messed up than that. AP didn't explicitly allow all 3, but it calls out in a non-normative note that implementers may produce non-canonical serializations.

Right now, as:Public is canonical. Public would be canonical if properties like to/cc/audience were vocab-relative, but they aren't (and shouldn't be). Undefining the as: prefix results in the full URI being canonical.

I think introducing a vocab relative term for visibility could make sense, using Public.