I think the biggest challenge people are having with ActivityPub is that they are, for the first time, generally encountering a "structured open world system" for the first time.
Closed world systems let you control (and prove) a lot, but you can only do the things your own "world" has built an idea up about. Also "easier" to build DB schemas for, etc. But hopeless for extensibility when talking with the rest of the world.
Meanwhile, completely free-for-all-json, coordinating on meaning is nigh impossible.
So if you just use ActivityStreams' default stuff, it's easier, because you have just a smaller set of vocab to deal with. Suddenly you want or encounter extensions and oh shit, you hit the -LD side of JSON-LD, and that stuff is there for a reason
The main thing you can and should do: compact incoming json-ld to your local world knowledge with your local json-ld context. (This is a one-line operation with any json-ld library.) Then you can treat it as "just json" and all the fields will be things you know. Store the fields you don't know about somewhere so you can get to them if you need them but they can be off to the side a bit.
@cwebber well, if they're *not*, then you usually won't get all the information you need right away to see what an unfamiliar extension contains. that could be okayish but you'll be getting random bits of extension forever and have to figure out how to handle that.
all because somebody was too careless to throw a json-ld static file somewhere
@KitRedgrave generally I agree. I think the current state of URI terminology and contexts is fairly imperfect, and there's interest in some things that I think will improve stuff... but that's a conversation about making things better that's a bit too complicated to go into in this thread