Ideally, at the bare minimum, ActivityPub should have explicitly specified the "shape" of JSON (not JSON-LD) documents.
For example, the spec could have stipulated:
"An Actor document MUST contain the following fields, and MAY be extended via JSON-LD contexts"
And then also stipulate:
"Clients SHOULD expand incoming JSON-LD documents".
This way, applications could skip the expansions step for significantly large subset of the Fediverse.
This is important because not all environments (languages, runtime environemnts, etc.) have the luxury of expanding JSON-LD documents.
@manlycoffee can you explain this with samples?
@manlycoffee this would cause a rift in the fediverse. Platforms would go for the lowest common denominator, and JsonLD usage will be abolished completely.
Our own AP implementation requires a lot of extra fields, to adapt AP from a microblogging protocol to a messaging and Blogging protocol. That means any platform that doesn't support JsonLD will be unable to interop with it.
Btw, if you find a JsonLD library, you can expand it then deserialize it like any ordinary Json. It takes a lot of boilerplate in some languages, depending on their Serialization system, but it should work perfectly.
I will recommend Titanium if you're using the JVM, and Sophia if you're using Wasm. There's an official list that you've probably already found but I'll include it for completeness' sake.
Btw, what platform are you on that you say doesn't support JsonLD?
My rewrite of bovine processing will lead to something like that. The goal of the rewrite/refactor is to separate out delivery, validation, receiving logic from the business stuff of handling content.
I'm still not on where the road is going, currently it looks like it will be sufficient to consider the id, type, actor, attributedTo, and object fields for incoming messages. For outgoing messages, one needs to add to, cc, bto, bcc.
Allowing for signed objects and embedded objects will lead to some complications, but none that matter, i.e. they are exactly what I expect.