ATProto 및 Bluesky 기술 블로그 포스트 아카이브

AT Protocol(ATProto)과 Bluesky의 설계 철학, 연합 아키텍처, 중재 시스템 등 핵심 기술 문서를 연도별로 정리하여 제공한다.

🔗 원문 보기

once I’m out of college I want to be in the AT Protocol space as a job.

Using Claude Code to build an ActivityPub implementation for Indiekit, based on Fedify, was the easy part. (and it was a lot of fun 😊)

Building the UI to actually consume ActivityPub content, and layering a Mastodon-compatible API on top of it that works with existing apps and plays nicely with other AP implementations… that’s the real challenge.

Eating FEPs for dinner and reading how other implementations do things is how you realize just how much work is still ahead — and how many pain points are still unresolved.

Right now, my Indiekit blog has:

IndieWeb (Micropub, Microsub, Webmentions)

ActivityPub (server + reader)

If I wanted to self-host my own ATproto PDS, I’d also need to build an “AppView” to consume Bluesky content.

So I’d end up with:

one reader for RSS (my current Microsub)

one reader for ActivityPub (my native, still ugly AP reader)

one reader for ATproto

That’s a lot of readers for different data streams coming from different protocols.

At some point I thought: what if I just used my Microsub UI to consume everything — not just RSS/Atom/JSONFeed/h-feed?

Since Microsub already supports channels, I figured I could inject an AP timeline into a Microsub channel.

That idea fell apart pretty quickly.

RSS and h-feed from IndieWeb sites are straightforward. I know I can reply, like, repost, or bookmark because the other side supports the same interaction model.

But the moment I had to deal with ActivityPub — likes, boosts, replies — everything became different. The Microsub plugin would have needed so many protocol-specific features that my implementation would drift far from other Microsub implementations.

And I really didn’t like where that was heading.

Microsub turning into a universal ingestion layer for everything?
That felt like a guaranteed mess.

So I drew a line: Microsub stays scoped to RSS/Atom/h-feed/JSONFeed. That’s it.

And yet… I’m still torn.

Because instead of one unified UI to consume RSS, ActivityPub, and ATproto, I’m now building three separate readers.

And that honestly feels like a huge waste.

So I’m dumping this conundrum here.

Maybe somewhere between the Fediverse and the Atmosphere, someone has already figured this out — or at least has a better idea.

Do you?

🔗 https://rmendes.net/notes/2026/03/31/a9598

Sehr interessante Dynamik mit #Attie auf #Bluesky: Die Leute regen sich über das Scrapen und maschinelle Verarbeiten ihrer Posts auf, wollen den Attie-Dienst verbieten usw. Sie begreifen Bluesky noch immer als direkten Twitter-Klon, es ist nicht durchgedrungen, dass das ganze Netzwerk sogar durch offene APIs live abschnorchelbar ist. Das ist die fundamentale Architektur von #ATProto. Dienste wie Attie waren von Anfang an als Monetarisierungspfad geplant:

https://chaos.social/@frumble/114330398840603019