Recent searches
Search options
Administered by:
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?
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.