洪 民憙 (Hong Minhee)

@django @nlnet @dansup The FEP for GTS-style comment controls will be coming from me. 👋 Hopefully in the next few weeks. If you scroll down my replies on my profile you can find scattered remarks on progress and remaining work items. There is a Matrix chat - if you want an invite to it, let me know!

以前から、東アジアにもFediConのようなイベントがあればいいなと言い続けてきました。独自のカンファレンスはまだ難しそうですが、小さな一歩として考えていることがあります。

@COSCUP 2026（台北、8月8日〜9日）がコミュニティトラックの提案を受け付けています。FOSDEMのSocial Web devroomのような感じで、Social Webトラックを開けないかなと思っているところです。

まだ構想段階ですが、ActivityPubやフェディバース、ソーシャルウェブ全般に取り組んでいて、発表や共同オーガナイズに興味があるという方がいれば、ぜひ話しかけてください。

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #ActivityPub #fediverse #フェディバース #COSCUP #fedidev

東(동)아시아에도 FediCon 같은 行事(행사)가 있으면 좋겠다는 말을 여러 番(번) 해왔는데요. 獨立的(독립적)인 컨퍼런스는 아직 어렵더라도, 작은 첫걸음으로 생각해보고 있는 게 있습니다.

@COSCUP 2026(臺北(타이베이), 8月(월) 8日(일)–9日(일))이 커뮤니티 트랙 提案(제안)을 받고 있어요. FOSDEM의 Social Web devroom 같은 느낌으로, 거기서 Social Web 트랙을 열 수 있지 않을까 하고 構想(구상) 중입니다.

아직 確定(확정)된 건 아무것도 없지만, #ActivityPub, #聯合宇宙(연합우주), 或(혹)은 소셜 웹 全般(전반)을 다루고 있고 發表(발표)나 共同(공동) 오거나이징에 關心(관심)이 있으신 분이 있다면 이야기 걸어주세요.

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #fediverse #연합우주 #페디버스 #COSCUP #fedidev

I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:

@COSCUP 2026 (Taipei, Aug 8–9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track there—something in the spirit of the Social Web devroom at FOSDEM.

Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #COSCUP #fedidev

Fedifyを使ってFedi版Togetter作るぞ

Fedify使う上で一番克服すべきはTypeScriptなんだよな

以前から、東アジアにもFediConのようなイベントがあればいいなと言い続けてきました。独自のカンファレンスはまだ難しそうですが、小さな一歩として考えていることがあります。

@COSCUP 2026（台北、8月8日〜9日）がコミュニティトラックの提案を受け付けています。FOSDEMのSocial Web devroomのような感じで、Social Webトラックを開けないかなと思っているところです。

まだ構想段階ですが、ActivityPubやフェディバース、ソーシャルウェブ全般に取り組んでいて、発表や共同オーガナイズに興味があるという方がいれば、ぜひ話しかけてください。

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #ActivityPub #fediverse #フェディバース #COSCUP #fedidev

東(동)아시아에도 FediCon 같은 行事(행사)가 있으면 좋겠다는 말을 여러 番(번) 해왔는데요. 獨立的(독립적)인 컨퍼런스는 아직 어렵더라도, 작은 첫걸음으로 생각해보고 있는 게 있습니다.

@COSCUP 2026(臺北(타이베이), 8月(월) 8日(일)–9日(일))이 커뮤니티 트랙 提案(제안)을 받고 있어요. FOSDEM의 Social Web devroom 같은 느낌으로, 거기서 Social Web 트랙을 열 수 있지 않을까 하고 構想(구상) 중입니다.

아직 確定(확정)된 건 아무것도 없지만, #ActivityPub, #聯合宇宙(연합우주), 或(혹)은 소셜 웹 全般(전반)을 다루고 있고 發表(발표)나 共同(공동) 오거나이징에 關心(관심)이 있으신 분이 있다면 이야기 걸어주세요.

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #fediverse #연합우주 #페디버스 #COSCUP #fedidev

I've been saying for a while that we need something like FediCon in East Asia. A dedicated conference is still a stretch, but I've been thinking about a smaller step:

@COSCUP 2026 (Taipei, Aug 8–9) is accepting proposals for community tracks. It might be worth trying to open a Social Web track there—something in the spirit of the Social Web devroom at FOSDEM.

Nothing is decided yet, but if you're working on #ActivityPub, the #fediverse, or anything in the social web space and might be interested in speaking (or co-organizing), I'd love to hear from you.

https://floss.social/@COSCUP/116152356550445285

#SocialWeb #COSCUP #fedidev

I would like to migrate some of my projects to Codeberg, but since Codeberg doesn't seem to support PyPI's Trusted Publishing (yet), I don't think I'll be able to do that...

#OtD 1 Mar 1947 police on the Korean island of Jeju opened fire on left-wingers on a pro-independence demonstration, killing six. In protest, public sector workers on the island launched a general strike, which had never occurred before in Korea https://stories.workingclasshistory.com/article/7710/3.1-shooting-incident

🚀 COSCUP 2026 Call for Participation is now open!

🎤 Community Tracks – Run a open-source agenda with talks, panels, or workshops. Apply by Mar 23. Spots are limited.

🛠 Community Booths – Showcase your project, recruit members, and connect. Apply by Jun 9. First come, first served.

👉 Apply here: https://s.coscup.org/26communityen

#COSCUP2026 #OpenSource #Community

@kodingwarrior 제가 Hollo 쪽을 패치해서 Mastodon 흉내 내도록 고쳤어요 ㅋㅋㅋ

@kopper The composability angle is something I hadn't fully appreciated before—a standalone reply tree indexer that any client can query via proxyUrl is a genuinely interesting pattern, and it's not something you'd get from just standardizing a monolithic client API.

On did:key, you're right that handing over a private key for autonomous server actions is a real problem, and the non-rotatability makes it worse. Though I'd frame that as a limitation of did:key specifically rather than portable identity as a concept—FEP-ef61 mentions other DID methods as candidates, and the broader space of approaches to server-independent identity isn't exhausted by any single proposal.

But agreed that they're orthogonal and can coexist.

@trwnh Yes—Fedify is database-agnostic, so tracking which IDs are already in use is the application's responsibility. Fedify handles the federation layer, but the data model and storage are entirely up to the application built on top of it.

@kopper That's a fair point about the Mastodon API—the lexicographic ID requirement and the pagination assumptions are good concrete examples of how standardization quietly closes off design space in ways nobody intended.

I think this exchange has been useful for me in clarifying that we're probably starting from different premises about what C2S is for. If frontend portability isn't the goal, then the case against standardizing the client API makes a lot of sense. I just can't quite let go of the feeling that portability at that layer is what most people imagine when they hear “C2S”—though I'll admit the spec itself is ambiguous enough that neither of us is obviously wrong.

Anyway, thanks for taking the time to respond. Lots to think about.

@kopper Thanks for engaging with this—it helps me think it through more carefully.

Your point about making the split explicit at the protocol level is well taken. I can see how that matters especially for extensions: a lot of FEPs end up adding actor-global state for things that are really client concerns, and having a clearer boundary in the protocol might discourage that drift. That's a concrete benefit I hadn't fully appreciated.

On the interoperability question, I think I see where we differ. You're reframing the core promise of C2S as “reuse the same account across different interfaces,” whereas I'd been reading it as “connect any frontend to any server.” Those lead to quite different designs. I'm not sure which framing is more faithful to what C2S originally intended—maybe neither of us is wrong, and the spec was simply underspecified on this point.

That said, if account portability is the goal, I wonder whether C2S is really the right tool for it. FEP-ef61 and the Nomadic Identity approach both tackle that problem more directly, by making identifiers server-independent at the identity layer rather than standardizing the client–server protocol. It feels like a different layer of the problem altogether, and I'm not sure C2S can carry that weight on its own even with your proposed architecture.

The point about AP objects remaining AP objects through hydration is interesting though. I can see how that keeps the pieces composable even without a standardized client API. I'll have to think about that more.

@trwnh Actually, Fedify already supports this quite well. The actor dispatcher gives you full control over the actor's id—you can set it to any URL, including one on a custom domain. And since Fedify 1.4.0, there's a mapAlias() method that lets you handle WebFinger lookups for those custom URLs too. So running Fedify behind a reverse proxy that routes multiple hostnames, and assigning per-actor custom domain identifiers, should be achievable without any changes to Fedify itself.

Today @kopper shared a post on the fediverse titled how to not regret c2s, and I found it genuinely interesting to read, even if I'm not sure its proposed architecture actually solves what it sets out to solve.

The author's frustration with naïve #C2S implementations is well-founded. Slapping an #ActivityPub facade onto an existing Mastodon-like server and calling it C2S doesn't buy you much—you end up with the rigidity of a bespoke API without any of the interoperability C2S is supposed to offer. The “JSON-LD flavored Mastodon API” framing is apt.

The proposed solution is to split responsibility more aggressively: the C2S server should be nearly stateless and dumb, storing ActivityPub objects without interpreting them, while a separate “client” layer handles indexing, timelines, moderation, and exposes its own API to the frontend running on the user's device. It's a clean separation of concerns on paper.

But here's what bothers me. When you map this architecture onto familiar terms, it looks roughly like this:

• C2S server ≈ a database (PostgreSQL, say)
• “Client” ≈ an application server (Mastodon, Misskey)
• “Frontend” ≈ the actual client app on your phone

That's not a new architecture. That's just the current architecture with the labels shifted. The interesting question is which interface gets standardized, and the author's answer is the one between the C2S server and the “client” layer—the bottom boundary.

The problem is that what people actually want from C2S is to connect any frontend to any server. The portability they're after lives at the top boundary, between the frontend and whatever is behind it. But the author explicitly argues against standardizing that layer: “we don't really need a standardized api,” they write, leaving each client free to expose whatever API it likes.

Which means frontends remain locked to specific clients, just as Mastodon apps are locked to the Mastodon API today. The interoperability promise of C2S—log in to any server with any app—isn't actually delivered. It's been pushed one layer down, out of reach of the end user.

There's real value in the post's thinking about data hosting vs. interpretation, and about the security implications of servers that understand too much. But as an answer to the question C2S is supposed to answer, I'm not convinced.

#fedidev #fediverse

@trwnh Fedify does run well behind a reverse proxy, and it doesn't actually require a fixed base URL—it can derive the base URL from the incoming request. Ghost takes advantage of exactly this to implement virtual hosting on top of Fedify, so in principle the kind of per-actor custom domain you're describing should already be achievable without changes to Fedify itself.

@trwnh Fedify currently doesn't support binding a custom domain to individual actors—all actors share the server's domain. Honestly, I'm not sure how that would work in practice either; it would need some kind of indirection or delegation mechanism at the HTTP level, and I'm not aware of an established spec for it. Do you have something specific in mind, or perhaps an approach you've been thinking about?

@mro That's a fair point about design by committee, and I don't disagree that RFC 9421 added complexity without proportionate benefit. But I think it's a somewhat separate question from what I was getting at.

Even if every ActivityPub spec had been designed with ruthless simplicity—no committee sprawl, no redundant signature schemes—the DX problem would still be there. You'd still need to know what to do when a property arrives as a string instead of an array. You'd still need to handle embedded objects vs. URIs. The gap between “I understand ActivityPub conceptually” and “I can ship something that actually federates correctly” would still be wide.

My point isn't really about why the stack is complex. It's that the complexity, whatever its origin, currently falls entirely on the application developer. A framework should be able to absorb most of that—the same way web frameworks absorbed HTTP parsing and content negotiation—so developers can focus on what their app actually does.

(And yes, the CGI analogy was never meant to be architectural criticism! Just reaching for a feeling most of us remember.)

Obsidian Sync now has a headless client, so you can sync vaults to a server without using the desktop app.

Try the open beta:

@rick Great work, Ricardo! And thank you for using Fedify!

@silverpill That's right. I think client-side abstraction will be necessary when ActivityPub C2S interactions become more widespread, too.

@hongminhee@hollo.social I think you're completely right, and this is coming from somebody who went deep into the weeds of ActivityPub when building out his own implementation.

Generic C2S servers offload the server side aspects to a trusted third party.

Generic S2S frameworks (like fedify!) give you even more control.

We need both! We need fewer idiots like me who decided to implement the entire protocol from the ground up 🤣

Do it @hongminhee@hollo.social! DEPRECATE ALL MY HARD WORK ALREADY!!!

@hongminhee Better developer tooling is the only correct answer to rising complexity. Getting 200 different servers to smoothly interoperate is impossible, but we can do that with 10 libraries.

@julian Haha, most ActivityPub implementers have their own frameworks, they just haven't separated them out! It would be really great if there were full-featured ActivityPub frameworks for each of the major programming languages.

When I first started working with #ActivityPub, before #Fedify existed, it felt like writing web apps in Perl and CGI in the late '90s. Interesting, even exciting—but never comfortable. That era where your business logic and your protocol plumbing were just… the same thing:

print "HTTP/1.1 200 OK"
print "Content-Type: text/html"
print
print "Hello, world!"

Decades of web development have given us layers of abstraction we now take for granted. Nobody hand-parses application/x-www-form-urlencoded query strings anymore. Nobody writes their own JSON codec, or manually constructs HTTP request/response messages. These things just aren't your problem when you're building an app.

ActivityPub development still feels like they are your problem. What do you do when the https://www.w3.org/ns/activitystreams#actor property comes in as a string instead of an array? What about when https://www.w3.org/ns/activitystreams#object is an embedded entity rather than a URI? How exactly do you implement HTTP Signatures? And wait—what's Linked Data Signatures, and do you need that too?

The real issue isn't that ActivityPub is complicated per se. It's that you can't get away with understanding it at a high level. You have to know it the way an implementor knows it—every edge case, every inconsistency in how different servers serialize JSON-LD, every signature scheme that exists in the wild. That's a lot to learn before you can even start thinking about your actual app. And when developers understandably cut corners on the protocol to focus on their product, it quietly becomes an interoperability problem for the whole ecosystem.

What I want ActivityPub development to feel like: you spend a day understanding the big picture, and then you just… build your app. That was the goal when I started Fedify, and honestly, we're not fully there yet. But it's where I want to get.

#fedidev #fediverse