洪 民憙 (Hong Minhee)

@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

Fedify has just laid out a comprehensive implementation plan for this fep:

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

The core idea is replacing HTTP(S) URIs with server-independent identifiers: ap:// URIs that use a Decentralized Identifier (DID) as the authority component, rather than a domain name. An object identified as ap://did:key:z6Mk…/actor can live on multiple servers simultaneously and survives any single server disappearing.

@jupiter_rowland Full nomadic identity—the kind Forte and (Streams) have—is something I'd like to support in Fedify eventually. But for now, I'm focusing on the more modest goal: server-independent object identifiers that survive a server disappearing. The multi-server synchronization side of things feels premature to build out seriously until the relevant specs (FEP-ef61 itself is still DRAFT, after all) stabilize a bit more. Once the standardization catches up, I'd like to revisit.

Thanks for the context on @mikedev and the history here—I wasn't fully aware of how deep the roots of nomadic identity go.

@silverpill

@shimon1024 おお…すごいですね！素晴らしいです！ぜひお会いしていろいろと学ばせていただきたいです。

ところで、今回の東京行きにご一緒するHaze Leeさん（@nebuleto）も同席してもよろしいでしょうか？（日本語は話せます）

@shimon1024 おお、モンゴル文字対応ですか…興味深いですね！モンゴル文字については浅学ですが、もっと深くお話ししたいです。私は自作のActivityPub実装であるHolloに、漢字混じりの韓国語（所謂「国漢文混用体」）に振りハングル（振り仮名のハングル版）を付ける機能を実装したことがあります。もしよろしければ、DMで具体的なお約束を決めませんか？

@silverpill Thanks for the clarification! I think I was overcomplicating it—I was imagining a scenario where gateway A forwards a received activity to gateway B, and wondering how B could trust that A hadn't tampered with it. But of course, since portable activities must carry FEP-8b32 integrity proofs, the authenticity of the activity itself can always be verified regardless of which server forwarded it. No separate gateway-to-gateway authentication mechanism is needed.

And the gateways-based trust makes sense now as a mechanism specifically for unauthenticated collections—if a collection comes from a server listed in the actor's gateways array, proof verification can be skipped; otherwise it's required.

Jiwon (@z9mb1), one of our core contributors, drew a Fedify dino! How cute!

https://oeee.cafe/@z9mb1/2b5b0baf-466b-4c65-a1e0-d3588f0666f4

Fedify dino for notice

https://kre.pe/CKwN This is a paid request :) fediverse logo was attached afterwards.

Started laying out a rough plan for implementing FEP-ef61: Portable Objects in #Fedify—server-independent #ActivityPub identities backed by #DIDs, multi-server replication, and client-side signing. It's going to be a long road (13 tasks across 5 phases, with a few open questions that need answering before we even begin), but I think it's worth doing right.

https://github.com/fedify-dev/fedify/issues/288#issuecomment-3971459585

#fedidev #fediverse #PortableObjects

I have so much fun tin the fediverse, this is a very cozy place.

@hyunjoon 그냥 字體(자체)가 다른 건데… 어느 쪽이 좀 더 《康熙字典(강희자전)》 字體(자체)에 가깝냐를 基準(기준)으로 쓰고 있습니다. ㅎㅎㅎ

國漢文(국한문)으로 韓國語(한국어) 쓸 때 「産(산)」 代身(대신) 「產(산)」을 쓰는 便(편). 비슷하게 「畵(화)」 代身(대신) 「畫(화)」를 쓴다거나, 「査(사)」 代身(대신) 「查(查)」를 쓴다거나 하는 게 있음. 아무도 神經(신경) 안 쓰겠지만… ㅋㅋㅋ

슬슬 Fedify 스티커도 좀 더 生產(생산)해야…

Here's a cat drawn by @hongminhee that you can look up here by its URL to interact with https://oeee.cafe/@hongminhee/ed323b59-557c-4843-aad2-5a83df0e3006

RE: https://planet.moe/@oeee_cafe/115615511184864588

Oeee Cafe is a Korean federated community drawing app that recently launched mobile apps on iOS and Android. You can follow users there from here in the fediverse already but not sure if you can submit drawings remotely yet.
#fedidev

Instead of using git as a database, what if you used database as a git?

https://nesbitt.io/2026/02/26/git-in-postgres.html

I making auto-translated FEP document for Japanese, trying local models...

@liaizon @julian @rick To be honest, I'm not really waiting for FEP standardization. It's more likely that the task of adding the GTS interaction policy vocabulary to Fedify will be included in the roadmap for the next version. (Or maybe the one after that.) Only after that prerequisite work is done can support for Mastodon-style quote posts be added to Fedify, I think.

@silverpill Ah, I see. In that case, it would be great if canonical permalinks could be decided for the FEP documents first!

@liaizon @rick We have an issue for this!

https://github.com/fedify-dev/fedify/issues/452

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

There's now a proper rendered web interface for FEPs at https://fediverse.codeberg.page/fep/fep/*/, which is much nicer to read than the raw Markdown source on Codeberg. But the canonical permalink, https://w3id.org/fep/*, still redirects to the Markdown file rather than the rendered page.

Would it make sense to update the w3id.org redirect to point to the rendered version instead? It seems like the better experience for anyone following a FEP link, and arguably what a “permanent” link should resolve to—something human-readable.

I'm not sure who manages the w3id.org/fep/ redirect configuration. (It lives in the perma-id/w3id.org GitHub repo, so it would just be a PR, but I'd want to get community consensus first rather than just send one in unilaterally.)

#fedidev #fep #fediverse #ActivityPub

日本かアジア圏でActivityPubとかオープンデータとかシビックテックのカンファレンスやイベントがあればちょっとずつ参加していきたいな。英語もまた話せるように鍛え直さないと…