I hope more #ActivityPub implementations start properly handling JSON-LD documents in various forms, rather than using ad-hoc approaches like only allowing specific fields to accept both arrays and scalar values.
Or, just use a proper JSON-LD processor altogether. Of course, there would be a performance penalty. The #ActivityPub 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.
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.

Honestly, I don't really care what strategy other #ActivityPub implementations follow to comply with the spec. (I solved it in #Fedify 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. 😩

@hongminhee

Why don't you fix your software instead?

It sounds like you're referring to this issue:

https://github.com/pixelfed/pixelfed/issues/6588

But in Fediverse, attachment is not supposed to be an object, it's an array.

I don't think you should expect people to comply with your vision of ActivityPub.

[Federation]: `Create(Note)` with a single attachment is dropped because `Helpers::verifyAttachments` still assumes `attachment` is an array (follow-up to #6427) · Issue #6588 · pixelfed/pixelfed

Description PR #6427 made handleCreateActivity accept the JSON-LD 1.1 compact form of to/cc (single value instead of a one-element array). The same compaction rule applies to every set-valued prope...

GitHub

> attachment is not supposed to be an object, it's an array.

@silverpill I don't understand how you infer that from this spec: https://www.w3.org/TR/activitystreams-vocabulary/#dfn-attachment

@hongminhee

Activity Vocabulary

@mariusor @silverpill @hongminhee yeah, that's definitely not what the spec says.

"The serialized JSON form of an Activity Streams 2.0 document MUST be consistent with what would be produced by the standard JSON-LD 1.0 Processing Algorithms and API [JSON-LD-API] Compaction Algorithm"

@evan @mariusor @silverpill @hongminhee I can't wait for us to finally drop jsonld in a living standard
@Profpatsch what makes you think that's going to happen? It's unlikely. It would require a massive backwards-incompatible change. Why would we do that to a network that has tens of thousands of nodes, 100+ implementations?
@evan cause most Implementations already treat it as if it was plain JSON with a subset of ActivityPub semantics
@Profpatsch "Most implementations" treat it like it is -- JSON-LD. They might use different kinds of processors for publishing or consuming it, but on the wire, it's compliant JSON-LD, according to the ActivityPub and Activity Streams 2.0 specs.
@evan then what's with all the parsing issues like the ones people are complaining about in this very thread?

@evan nobody is in all seriousness implementing the full generality of jsonld, that would be a huge attack vector as far as I understand, given the complexity of context merging, reference resolution etc.

Most languages don't provide full jsonld libraries in their stdlib either