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 forced to do whack-a-mole development. 😬
@hongminhee I ran into things like this with Mastodon. I send valid AP activities but if I don’t encode them in a specific way, Mastodon silently ignores them. Like how it assumes the object of a Create activity must be inline and not a reference, but the actor must be a reference and not inline.
@jamie Yeah, exactly such kind of thing!

@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
Normalize outgoing JSON-LD for Pixelfed interop by dahlia · Pull Request #721 · fedify-dev/fedify

Summary Adds a dedicated outgoing JSON-LD compatibility layer in packages/fedify/src/compat/outgoing-jsonld.ts. Moves the existing public audience workaround into that layer so outgoing activities...

GitHub

@hongminhee Thank you

(my server can handle an object, but you do a favor to all who are only beginning to develop their fedi projects)

> 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

@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

@Profpatsch you're pointing to a scapegoat and you can't avoid the complexity of a distributed open world system

if everyone already ignores jsonld then how is it jsonld's fault that people are encountering problems unrelated to jsonld? again, i really hope you are sanitizing your inputs and protecting against confusion attacks.

@trwnh fwiw I think "on the wire it's compliant JSONLD" is a bit like saying "this random stream of brackets is compliant perl"
@trwnh or "this single integer someone sends to the other side o ly expecting ascii integers is compliant YAML"
@trwnh does any receiving side actually do fully compliant context resolution? No probably not. And it would be a huge security risk to do so
@Profpatsch anyone using contexts must preload them ahead-of-time, actually. and if you use exclusively terms defined in AS2, you get the equivalent semantics from the media type (application/activity+json). so it only matters for extensions in the first place, which get ignored if they are not defined (and processing continues without breaking on those ignored extensions)
@Profpatsch if you want to agree on extensions without jsonld, you can -- but then you're not being descriptive at all, and you will have failures if you encounter anyone not agreeing with you and using the same term in a different way. if mastodon uses "featured" as a pinned posts collection on accounts and i use it as a boolean on activities, we simply disagree. but you can't detect that without some way of obtaining term definitions. jsonld expansion is one way. central registries is another.
@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
@mariusor @hongminhee I didn't infer that from the spec, it's how Fediverse works.
@mariusor @hongminhee I bet the software you're using right now always sends an array
@silverpill @hongminhee single element arrays in JSON-LD go to the element itself, not an array.
@silverpill @hongminhee why do we need this kind of complication? What's wrong with just always expecting an array and simplifying the standard instead?
@Profpatsch @hongminhee I'm all for simplification. There can only be one serialization format, and Fediverse has already settled on JSON. Attempts to change de-facto standard to JSON-LD are extremely counter-productive.

@hongminhee So, I really appreciate that you are doing this work. I know it's hard, and it feels unrewarding, but it really matters, and it really helps the ecosystem.

Please let me know if I can help out in these efforts.

I hope that all of us in the ActivityPub community take these requests seriously when they come in.