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?
@Profpatsch the complaints are about bugs on the consuming side for serializations that are correct on the producing side. consumers are applying arbitrary too-strict schemas that are not part of the AS2 spec. hong was asking for consumers to fix their software, and the response was asking hong to break their software in exactly the same way. (dropping jsonld does nothing and is a complete red herring. actually, using jsonld could avoid the issue, because it doesn't skip the normalization step.)
@trwnh
elinks --dump https://www.w3.org/TR/json-ld/ | wc
14618 54990 674684
JSON-LD 1.1

JSON is a useful data serialization and messaging format. This specification defines JSON-LD 1.1, a JSON-based format to serialize Linked Data. The syntax is designed to easily integrate into deployed systems that already use JSON, and provides a smooth upgrade path from JSON to JSON-LD. It is primarily intended to be a way to use Linked Data in Web-based programming environments, to build interoperable Web services, and to store Linked Data in JSON-based storage engines.

@trwnh btw I hope you are following all the algorithms, there’s like 10 and they each have 40–50 steps and three layers of branching: https://www.w3.org/TR/json-ld11-api/
JSON-LD 1.1 Processing Algorithms and API

This specification defines a set of algorithms for programmatic transformations of JSON-LD documents. Restructuring data according to the defined transformations often dramatically simplifies its usage. Furthermore, this document proposes an Application Programming Interface (API) for developers implementing the specified algorithms.

@Profpatsch you don't need to implement all the algorithms yourself, you just need to disambiguate terms and normalize the serialization. this is true regardless of whether you use jsonld or not, because it's an open world system. you can't say any property always has only one value, or is always an array, unless defined that way. and most AS2 properties are not defined with those restrictions. people are effectively using the AS2 terms in ways they are not defined, imposing extra restrictions.
@Profpatsch like, i could say the same thing as you, "i hope you are sanitizing your inputs" or "i hope you are disambiguating your terms" or "i hope you aren't being too strict in what you receive" or so on. that's not much of an argument against jsonld because these are things you need to do even without jsonld.
@trwnh you're not saying anything here really
@trwnh I'm saying "this thing is too complex we can skip on it and make it less complex" and you are saying actually I have no clue tbh
@trwnh fwiw I think "on the wire it's compliant JSONLD" is a bit like saying "this random stream of brackets is compliant perl"
@Profpatsch if you choose to use jsonld (yes it's optional) then you can describe how to expand or compact documents into knowledge graphs and store them in graph databases. the problem you are describing is in AS2 itself, where {} is a valid document describing an Object with no known properties.
@trwnh yes, I think we should simplify AS as well. There's no reason for the extra branch on the object