I recently noticed that the json-LD signatures in Epicyon were not working as intended. Partly it was just that the unit test wasn't comprehensive enough and so wasn't catching failures, but also there were some genuine problems which have now been fixed.

The use of json signatures in the ActivityPub fediverse isn't universal. I notice that some instances do it and some don't. The purpose is to ensure the authenticity of posts even when they are being relayed through intermediate servers. http signatures are good for checking posts as they move from one server to another, but in a decentralized architecture similar to email in which posts may sometimes be stored and re-broadcast by various servers to ensure that they reach their destination even when individual servers may not be 100% available (think of content delivery networks) the http signatures may not be enough.

What happens if you don't have authenticity mechanisms like these? In that case it becomes like email in the olden days. X can send a post pretending to be Y in order to artificially incite a flame war on a rival instance, and especially in social network systems this can have devastating effects. With signature checking in place at least if bad actors try to create chaos like this then they are reliably identifiable and blockable.

At present in Epicyon if a post arrives and has a json signature then it will be checked and the post rejected if it fails. This isn't ideal because an adversary can simply omit the signature, but we are not yet in a situation where these sorts of checks are a mandatory part of the ActivityPub specification. I'll add a configuration option which allows json signatures to be fully enforced if you don't care about federating with instances which havn't implemented this.

While fixing json signatures I also noticed that the verifier was downloading schemas from any URL referenced within the context section of a post. Not only was this slow but also potentially insecure. The schemas for activitystreams and signatures are now hardcoded, which makes the checking much faster and doesn't allow a server outside of your control to potentially veto your ability to perform checks. Investigating this also lead me down the schema.org rabbit hole, which is another Google horror and probably best left as the subject of a future blog post.