fedify

I have deeply mixed feelings about #ActivityPub’s adoption of JSON-LD, as someone who’s spent way too long dealing with it while building #Fedify.

After months of struggling with the “zombie post” issue on Hackers’ Pub—where deleted posts wouldn’t disappear from remote servers—I had a sudden hypothesis today. As I dug into it, I realized it’s a structural issue with Fedify’s MessageQueue system: Create(Note) and Delete(Note) activities can be delivered out of order, causing remote instances to receive Delete(Note) before Create(Note).

While working on #Fedify, I noticed something about how #Misskey handles #ActivityPub object access. When a remote server requests a followers-only post or DM with a valid HTTP Signatures (draft-cavage) from an authorized actor, Misskey still returns 404 instead of the content. It seems Misskey only checks the visibility field (public/home) without verifying the signature at all.

[Fedify] is a #TypeScript framework for building #ActivityPub servers that participate in the #fediverse. It reduces the complexity and boilerplate typically required for ActivityPub implementation while providing comprehensive federation capabilities.

According to @tchambers@indieweb.social’s *My 2026 Open Social Web Predictions*:

A ReDoS (Regular Expression Denial of Service) vulnerability has been discovered in Fedify’s HTML parsing code. This vulnerability could allow a malicious federated server to cause denial of service by sending specially crafted HTML responses.

A while back I mentioned the idea of “Fedify Studio”—a web-based toolkit for #ActivityPub debugging and development. I’ve been quietly working on shaping that idea into something more concrete.