Thanks to everyone who caught my talk, I just wanted ruby annotations: writing in dead scripts on the living fediverse, at @nprofile1q... 2026 today! It was great seeing you in the Fediverse & Social Web track. Here are the slides.

https://fediverse-ruby-coscup-2026.hongminhee.codefloe.page/

It is an honour to have been interviewed on behalf of the @nprofile1q... team for @nprofile1q...'s Building a Free Internet of the Future series.

https://www.apc.org/en/news/drfed-reducing-complexity-and-enabling-more-people-shape-fediverse

ActivityPub assumes content is text/html by default when mediaType isn't specified, whether the object is a Note or an Article. Misskey does something different, for reasons I still don't fully understand. It stores its internal representation as MFM, its own markup language. Between Misskey instances, it sends that through a separate _misskey_content property rather than content itself. When talking to non-Misskey software, it converts HTML into MFM.

The trouble is that MFM can represent much less than HTML. If another implementation sends HTML that has no clean MFM equivalent, the formatting comes out mangled in Misskey.

I keep wondering why Misskey didn't just store HTML, like Mastodon and most other implementations do, or at least kept both the source markup and the rendered HTML side by side. I know storing only HTML can lose some MFM features too. I still don't understand why Misskey chose the format that can represent less.

The more I work on Hollo, the more its Mastodon-compatible API feels like a straitjacket. I chose it for a practical reason: people could use existing clients, and I wouldn't have to build a frontend too. I still think that was the right call at the time.

The problem is that clients can only expose what Mastodon's API represents. I keep coming up with ideas, then asking whether the API has anywhere to put them. If it doesn't, I have no way to get the feature in front of users.

ActivityPub API (so-called “C2S”) might be the eventual answer, but it doesn't help much today. I don't know of any clients Hollo users could realistically use with it, and adoption is still limited.

So I keep coming back to the idea that Hollo will need a frontend of its own. I'd keep the Mastodon API for existing apps. I'm not especially eager to take on a whole frontend, but I don't see another way to try ideas that don't fit Mastodon's model.

I recently moved my personal blog from a PHP setup to Astro on Netlify because I wanted to add ActivityPub support with Fedify.

Somehow, it took me until then to realize that I had never actually tried running Fedify on Netlify.

Netlify Database is PostgreSQL, so the persistence side should already fit @fedify/postgres. The less obvious part is background delivery: Netlify Functions cannot keep a queue consumer alive, while Async Workloads uses a push-based model similar to WorkersMessageQueue in @fedify/cfworkers.

So I’m going to try making @fedify/netlify, with my own blog as its first real test case. I wrote down the initial design in issue #930.

#Mastodon's #ActivityPub inbox treats object types in tiers. Note and Question are supported directly. A second tier, Article, Page, Image, Audio, Video, and Event, gets converted to a title, a summary, and a link; content itself doesn't show. Anything outside both tiers is dropped on delivery, which is a large part of why so much of the fediverse federates as Note regardless of what the object actually is.

mastodon/mastodon#24079 asks for content to show up whenever it's present and the mediaType is supported, independent of type. Open since 2023, and as far as the thread shows, no core team engagement beyond one offhand remark that they're not happy with the status quo either.

Reading the issue text closely, it's a bit ambiguous whether it covers the drop tier or only the convert-to-title-and-link tier. I left a comment asking for clarification, since the fix looks very different depending on the answer.

If you build on ActivityPub, a comment or a reaction there is worth more than another workaround.

#fedidev #fediverse

One thing I keep coming back to when comparing #ActivityPub and AT Protocol: ActivityPub is basically a convention on top of the #web stuff we already have. An actor is a JSON-LD document you GET. An inbox is an endpoint you POST to. If you already run a website, you can bolt this on without changing the site's basic shape. Ghost didn't set out to join the #fediverse, and then years later it could, just by adding an endpoint.

AT Protocol feels less like that to me. Running a PDS means a signed repo, a Merkle search tree, a firehose, a DID. It's not a layer you add to an existing site. It's closer to standing up another backend beside it.

I think that's why ActivityPub keeps making sense to me. You can join later. You don't have to have built the whole thing with federation in mind from day one.

#ATProto #ATProtocol #fedidev

Starting on FEP-ef61 (Portable Objects) in @Fedify: ActivityPub server framework. It's a @nprofile1q... milestone due September 30, and the scope is… substantial. Not a lot of runway. Wish me luck.

#Fedify #FEPef61 #PortableObjects #ActivityPub #fedidev

Fedify Studio finally has a proper name: DrFed. We just got @nprofile1q... funding too.