Mike Macgirvin (dev) on Nostr: In the json-ld examples I've seen, @contexts nest and are only valid in their object ...

In the json-ld examples I've seen, @contexts nest and are only valid in their object or branch of the document tree, which implies searching "the nearest ancestor with a @context" to resolve any single object key.  This is the first time that I've seen anybody claiming it doesn't work this way. I'm not saying this is right or wrong because I haven't researched it in depth myself. If these nested contexts don't survive compaction or produce ambiguous results, I'd be inclined to call that a bug in the compaction. If it's a limitation of json-ld, ActivityPub is pretty much screwed as a json-ld implementation, because for instance you wouldn't be able to Like a Note with a different context without logically separating them as @Helge (npub1ug7…vaes) has done in this fep.

if Like/Note works only because they are separate documents that are fetched independently,  the obvious solution is to separate the 'proof' and fetch it independently also. Not my preferred solution, but if it will cleanly delineate the @context boundaries, I guess we're probably stuck with it - or some hack like this fep suggests.

I've always disliked this aspect of ActivityPub because overly chatty protocols don't really scale, so I'd probably lean towards the hack. But then I wonder how ld-signatures ever worked. Only because they are stripped from the document prior to compaction? Isn't this also true for DataIntegrityProof?

I had just finiished my morning cuppa and was just preparing to roll up my sleeves and start working on DataIntegrityProof and finally get rid of the accursed ld-signatures,  so this is a timely conversation.