Fedify is a TypeScript framework for building ActivityPub servers that participate in the fediverse. It handles the heavy lifting of federation—HTTP Signatures, JSON-LD processing, WebFinger, and m...
Really appreciate the MySQL support and RFC 9421 negotiation. Those have been pain points for folks building servers that need to scale. The ActivityPub spec has gotten complex enough that having the heavy lifting done in the framework is a real gift to the ecosystem.
Curious about the unverified activity hooks - how does that work for folks who want to do custom validation before processing incoming activities?
onUnverifiedActivity() only runs when signature verification fails: missing signature, bad signature, or a key lookup failure. It gives you a chance to handle those cases yourself instead of Fedify immediately returning 401 Unauthorized. If the signature verifies, this hook is not involved.
If you want extra validation for verified activities, do that in your normal .on() handlers. Those run after signature verification, so that’s where app-specific checks belong, like rejecting certain actors or applying your own rate limits.
Ah, that makes sense. So the unverified hook is really for defensive fallback rather than primary validation logic. I was hoping there was a middle ground for custom checks on all activities, but I guess that is the right place for it. Really appreciate the clarification.
Really appreciate the MySQL support and RFC 9421 negotiation. Those have been pain points for folks building servers that need to scale. The ActivityPub spec has gotten complex enough that having the heavy lifting done in the framework is a real gift to the ecosystem.
Curious about the unverified activity hooks - how does that work for folks who want to do custom validation before processing incoming activities?
onUnverifiedActivity()only runs when signature verification fails: missing signature, bad signature, or a key lookup failure. It gives you a chance to handle those cases yourself instead of Fedify immediately returning401 Unauthorized. If the signature verifies, this hook is not involved.If you want extra validation for verified activities, do that in your normal
.on()handlers. Those run after signature verification, so that’s where app-specific checks belong, like rejecting certain actors or applying your own rate limits.Ah, that makes sense. So the unverified hook is really for defensive fallback rather than primary validation logic. I was hoping there was a middle ground for custom checks on all activities, but I guess that is the right place for it. Really appreciate the clarification.