Thanks all for listening to my talk about #Fedify at #FOSDEM 2026 today! Here's my deck for the talk: Fedify: Building ActivityPub servers without the pain.
I overslept. Looks like I'll have to grab some brunch real quick and head to ULB.
Thanks all for listening to my talk about #Fedify at #FOSDEM 2026 today! Here's my deck for the talk: Fedify: Building ActivityPub servers without the pain.
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
It was really fun to talk with @liaizon about so many things like… anarchism and punk in the States, socialism vs. liberalism in Korea, and so on…
By the way, if you're attending #FOSDEM 2026 and are interested in #Fedify, an #ActivityPub server framework, please consider checking out my talk in the Social Web Room tomorrow.
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).
The fix will likely require API changes, so this will probably need to wait for #Fedify 2.0.0.
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).
The fix will likely require API changes, so this will probably need to wait for #Fedify 2.0.0.
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.
#Mastodon takes a different approach—when #authorized_fetch is enabled, it validates the HTTP Signatures and returns the content if the requesting actor has permission. I think it would be beneficial if Misskey could adopt a similar mechanism, since it would better respect the access control semantics that ActivityPub intends. Has anyone else run into this, or are there specific reasons Misskey handles it this way?
