洪 民憙 (Hong Minhee)

Fedify 2.0.0をリリースしました！

Fedify史上最大のリリースです。主な変更点をご紹介します：

• モジュラーアーキテクチャ — これまでのモノリシックな@fedify/fedifyパッケージを、@fedify/vocab、@fedify/vocab-runtime、@fedify/vocab-tools、@fedify/webfingerなど、独立したパッケージに分割しました。バンドルサイズの削減、インポートの整理に加え、カスタム語彙型によるActivityPubの拡張も可能になりました。
• リアルタイムデバッグダッシュボード — 新しい@fedify/debuggerパッケージにより、/__debug__/パスにライブダッシュボードを表示できます。連合トラフィックのトレース、アクティビティの詳細、署名検証、ログまで一目で確認できます。既存のFederationオブジェクトをラップするだけで使えます。
• ActivityPubリレーサポート — @fedify/relayパッケージとfedify relayCLIコマンドで、リレーサーバーをすぐに立ち上げることができます。Mastodon方式とLitePub方式の両方に対応しています（FEP-ae0c）。
• 順序保証メッセージ配信 — 新しいorderingKeyオプションにより、「ゾンビ投稿」問題を解決しました。DeleteがCreateより先に到着してしまう問題がなくなります。同じキーを共有するアクティビティはFIFO順序が保証されます。
• 永続的な配信失敗の処理 — setOutboxPermanentFailureHandler()で、リモートのインボックスが404や410を返した際に対応できるようになりました。到達不能なフォロワーの整理などが可能です。

その他にも、ミドルウェアレベルでのコンテンツネゴシエーション、@fedify/lint、@fedify/create、CLI設定ファイル、ネイティブNode.js/Bun CLIサポート、多数のバグ修正などが含まれています。

今回のリリースには、韓国のOSSCA（オープンソースコントリビューションアカデミー）参加者の皆さんからの多大な貢献が含まれています。ご協力いただいた全ての方に感謝いたします！

破壊的変更を含むメジャーリリースです。アップグレード前にマイグレーションガイドを必ずご確認ください。

リリースノート全文: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

Fedify 2.0.0을 릴리스했습니다!

Fedify 역사상 가장 큰 릴리스입니다. 주요 변경 사항을 소개합니다:

• 모듈형 아키텍처 — 기존의 단일 @fedify/fedify 패키지를 @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger 등 독립적인 패키지들로 분리했습니다. 번들 크기가 줄어들고, 임포트가 깔끔해지며, 커스텀 어휘 타입으로 ActivityPub을 확장할 수도 있습니다.
• 실시간 디버그 대시보드 — 새로운 @fedify/debugger 패키지로 /__debug__/ 경로에 라이브 대시보드를 띄울 수 있습니다. 연합 트래픽의 트레이스, 액티비티 상세, 서명 검증, 로그까지 한눈에 확인할 수 있습니다. 기존 Federation 객체를 감싸기만 하면 됩니다.
• ActivityPub 릴레이 지원 — @fedify/relay 패키지와 fedify relay CLI 명령어로 릴레이 서버를 바로 띄울 수 있습니다. Mastodon 방식과 LitePub 방식 모두 지원합니다(FEP-ae0c).
• 순서 보장 메시지 전달 — 새로운 orderingKey 옵션으로 “좀비 포스트” 문제를 해결합니다. Delete가 Create보다 먼저 도착하는 문제가 더 이상 발생하지 않습니다. 같은 키를 공유하는 액티비티는 FIFO 순서가 보장됩니다.
• 영구 전달 실패 처리 — setOutboxPermanentFailureHandler()로 원격 인박스가 404나 410을 반환할 때 대응할 수 있습니다. 도달 불가능한 팔로워를 정리하는 등의 처리가 가능합니다.

이 외에도 미들웨어 수준의 콘텐츠 협상, @fedify/lint, @fedify/create, CLI 설정 파일, 네이티브 Node.js/Bun CLI 지원, 다수의 버그 수정 등이 포함되어 있습니다.

이번 릴리스에는 한국 OSSCA (오픈소스 컨트리뷰션 아카데미) 참가자분들의 큰 기여가 담겨 있습니다. 참여해 주신 모든 분께 감사드립니다!

브레이킹 체인지가 포함된 메이저 릴리스입니다. 업그레이드 전에 마이그레이션 가이드를 꼭 확인해 주세요.

전체 릴리스 노트: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

Fedify 2.0.0 is here!

This is the biggest release in Fedify's history. Here are the highlights:

• Modular architecture — The monolithic @fedify/fedify package has been broken up into focused, independent packages: @fedify/vocab, @fedify/vocab-runtime, @fedify/vocab-tools, @fedify/webfinger, and more. Smaller bundles, cleaner imports, and the ability to extend ActivityPub with custom vocabulary types.
• Real-time debug dashboard — The new @fedify/debugger package gives you a live dashboard at /__debug__/ showing all your federation traffic: traces, activity details, signature verification, and correlated logs. Just wrap your Federation object and you're done.
• ActivityPub relay support — First-class relay support via @fedify/relay and the fedify relay CLI command. Supports both Mastodon-style and LitePub-style relay protocols (FEP-ae0c).
• Ordered message delivery — The new orderingKey option solves the “zombie post” problem where a Delete arrives before its Create. Activities sharing the same key are guaranteed to be delivered in FIFO order.
• Permanent failure handling — setOutboxPermanentFailureHandler() lets you react when a remote inbox returns 404 or 410, so you can clean up unreachable followers instead of retrying forever.

Other changes include content negotiation at the middleware level, @fedify/lint for shared linting rules, @fedify/create for quick project scaffolding, CLI config files, native Node.js/Bun CLI support, and many bug fixes.

This release includes significant contributions from Korea's OSSCA participants. Huge thanks to everyone involved!

This is a major release with breaking changes—please check the migration guide before upgrading.

Full release notes: https://github.com/fedify-dev/fedify/discussions/580

#Fedify #ActivityPub #fediverse #fedidev #TypeScript

LogTape, the JavaScript/TypeScript logging library I created, was featured on Sentry's official YouTube channel!

https://www.youtube.com/watch?v=k_qhTXAyiUs

아직도 私的(사적) 記錄物(기록물)에서 固有名詞(고유 명사)의 表記(표기)를 어떤 文字(문자)로 해야 할 지에 對(대)해 뾰족한 答(답)을 못 내렸다. 大原則(대원칙)은 한글 表記(표기)인데… 그게 언제나 可能(가능)한 건 아닌 것 같아서, 요즘에는 固有名詞(고유 명사)에 限(한)해 原語(원어) 表記(표기)를 하고 있었지만, 그건 그거대로 不便(불편)하달까… 假令(가령) 러시아 人名(인명)을 그 原則(원칙)대로 적겠다고 키릴 文字(문자)로 적어버리면 大部分(대부분)의 讀者(독자)는 못 읽게 될 것 아닌가. 그런데 다 한글로 表記(표기)하자니 내 語學(어학) 水準(수준) 안에서 適切(적절)한 外來語(외래어) 表記(표기)를 찾아내지 못할 때도 많고 말이다.

It took time and experience before the workers learnt to distinguish between machinery and its employment by capital.

—Karl Marx

This verdict on the Luddites, written 150 years ago, maps onto the LLM debate with uncomfortable precision: Acting materialistically in an imperfect world: LLMs as means of production and social relations.

労働者が機械そのものと資本による機械の使用とを区別することを学ぶには、時間と経験を要した。

——マルクス

150年前のラッダイト運動に対するこの評価が、いまのLLM論争にそのまま当てはまると思っています。「完全な世界で唯物論的に行動すること——生産手段としてのLLMと社会的関係」

勞働者(노働자)들이 機械(기계) 自體(자체)와 機械(기계)의 資本主義的(자본주의적) 適用(적용)을 區分(구분)하는 法(법)을 배우기까지는 時間(시간)과 經驗(경험)이 必要(필요)했다.

—마르크스

150年(년) 前(전) 러다이트 運動(운동)에 對(대)한 이 評價(평가)가 只今(지금) LLM 論爭(논쟁)에 그대로 適用(적용)된다고 생각합니다: 〈不完全(불완전)한 世上(세상)에서 唯物論的(유물론적)으로 行動(행동)하기: 生產(생산) 手段(수단)으로서의 LLM과 社會的(사회적) 關係(관계)〉(한글).

労働者が機械そのものと資本による機械の使用とを区別することを学ぶには、時間と経験を要した。

——マルクス

150年前のラッダイト運動に対するこの評価が、いまのLLM論争にそのまま当てはまると思っています。「完全な世界で唯物論的に行動すること——生産手段としてのLLMと社会的関係」

勞働者(노働자)들이 機械(기계) 自體(자체)와 機械(기계)의 資本主義的(자본주의적) 適用(적용)을 區分(구분)하는 法(법)을 배우기까지는 時間(시간)과 經驗(경험)이 必要(필요)했다.

—마르크스

150年(년) 前(전) 러다이트 運動(운동)에 對(대)한 이 評價(평가)가 只今(지금) LLM 論爭(논쟁)에 그대로 適用(적용)된다고 생각합니다: 〈不完全(불완전)한 世上(세상)에서 唯物論的(유물론적)으로 行動(행동)하기: 生產(생산) 手段(수단)으로서의 LLM과 社會的(사회적) 關係(관계)〉(한글).

It took time and experience before the workers learnt to distinguish between machinery and its employment by capital.

—Karl Marx

This verdict on the Luddites, written 150 years ago, maps onto the LLM debate with uncomfortable precision: Acting materialistically in an imperfect world: LLMs as means of production and social relations.

Random question, but I wondered:

Do you use CAPSLOCK on a physical keyboard?

I have just completed the "Learning the Basics" and "Creating a Microblog" tutorials on @fedify. The Fediverse is very complicated. However, building the example application with Fedify is much simpler, and the tutorial was really good, with lots of examples and explanations of the basics. If you want to check it out, here's the link: https://fedify.dev/tutorial/microblog.

Thank you for creating it, and please consider following @hongminhee!

#fediverse

@liaizon If you have a GitHub account you can report here!

今年中に日本で出版予定のFedifyの本の表紙イラストのラフ案をもらったんだけど、どれもすごく可愛くて選ぶのが大変！

In fact, Hackers' Pub is a bleeding-edge testbed for Fedify. 🙄

Bookmarked: [brandon.si] Linking Smaller Haskell Binaries

https://brandon.si/code/linking-smaller-haskell-binaries/

See more links at https://abhinavsarkar.net/linkblog #linkblog #linkblogging

@z9mb1 Congrats! 🎊

Internationalise The Fediverse

We live in the future now. It is OK to use Unicode everywhere.

It seems bizarre to me that modern Internet services sometimes "forget" that there's a world outside the Anglosphere. Some people have the temerity to speak foreign languages! And some of those languages have accents on their letters!! Even worse, some don't use English letters at all!!!

A decade ago, I was miffed that GitHub only supported some ASCII characters in its project names. There's no technical reason why your repo can't be called "ഹലോ വേൾഡ്".

Similarly, I'm frustrated that Mastodon (the largest ActivityPub service) doesn't allow Unicode usernames and has resisted efforts to change.

So I built a small ActivityPub server which publishes content from an Actor called @你好@i18n.viii.fi - it is only a demo account, but it works!

Some ActivityPub clients report that they are able to follow it and receive messages from it. Others - like Mastodon - simply can't see anything from it. Take a look at the replies on Mastodon to see which services work. You can also see some of its posts on the Fediverse.

What Does The Fox Spec Say?

The ActivityPub specification says:

Building an international base of users is important in a federated network. Internationalization

I can't find anything in the specifications which limits what languages a username can be written in. But there are a few clues scattered about.

The user's @ name is defined by preferredUsername which is:

A short username which may be used to refer to the actor, with no uniqueness guarantees. 4.1 Actor objects

There's nothing in there about what scripts it can contain. However, later on, the spec says:

Properties containing natural language values, such as name, preferredUsername, or summary, make use of natural language support defined in ActivityStreams. 4. Actors

So it is expected that a preferred username could be written in multiple scripts. Which implies that the default need not be limited to A-Z0-9.

The ActivityStreams specification talks about language mapping.

Finally, the ActivityPub specification has some examples on non-Latin text in names.

So, I think that it is acceptable for usernames to be written in a variety of non-Latin scripts.

But What About...?

There are usually a few objections to "Unicode Everywhere" zealots like me. I'd like to forestall any arguments.

What about homograph attacks?

Well, what about them? ASCII has plenty of similar looking characters. I doubt most people would notice when a capital i is replaced by a lower L - and vice-versa. Similarly the kerning issue of an r and n looking like an m is well known. Are mixed language homographs more dangerous? I don't think so.

What if people make names that can't be typed?

Well, what if they do? Maybe not being found by people who can't type your language is a feature, not a bug. But, anyway, clients can let users search for other people, or copy and paste their names.

What about weird "Zalgo" text?

It is up to a client to decide how they want to render text input. The "problems" of strange Unicode combinations are well known. This is not a hard computer-science problem.

What about bi-directional text?

The spec makes clear this is allowed.

Do people even want a username in their own script?

I have no evidence for this. But I bet you'd get pretty frustrated if you had to switch keyboard just to type your own name, wouldn't you? In any case, why can't I have a username of @😉

What's Next?

If you build ActivityPub software, give some thought to the billions of people who don't have names which easily fit into ASCII.

If your software can see @你好@i18n.viii.fi and its posts, please let me know.

@mcc @Hearth @xgranade I'm guessing Q and R are disallowed to mitigate homoglyph attacks. Maybe Old Hangul too, which presumably contains some homoglyphs with modern Hangul.

Somebody linked me RFC 7565, which linked to RFC7564, and if that's the place to look this appears to be the list of disallowed characters in a Fediverse username, and I'm cracking up because it's *mostly* stuff you'd expect, except the very first category of banned characters, specially, is "pre-1700 Korean characters".

The fediverse is welcome to all. EXCEPT KOREAN TIME TRAVELERS. Did you just wake up from being frozen in ice during the Joseon dynasty? The IETF is targeting you PERSONALLY

I Guess I’m now the first ever Indiekit Instance on the #fediverse

Thanks to Fedify

{
"@context": [
"https://www.w3.org/ns/activitystreams",
"https://w3id.org/security/v1"
],
"type": "Person",
"id": "https://rmendes.net/",
"preferredUsername": "rick",
"name": "Ricardo Mendes",
"url": "https://rmendes.net/",
"inbox": "https://rmendes.net/activitypub/inbox",
"outbox": "https://rmendes.net/activitypub/outbox",
"followers": "…

https://rmendes.net/notes/2026/02/19/8b1d5

@evan @cwebber @kopper @hongminhee Couldn’t we agree to standardize on expanded json-ld? We would not need any json-ld processor, we would not need to fetch or cache any context. There would be no way to shadow properties.

@kopper @evan @cwebber Ah, yes, the https://w3id.org/identity/v1 context... As I recall, I probably used it because I needed some kind of context to handle Linked Data Signatures. It's a bit embarrassing, but Fedify also preloads and uses that context. Personally, I wish https://w3id.org/identity/v1 would redirect to a different URL instead of the now-defunct https://web-payments.org/contexts/identity-v1.jsonld.

Nice that @kagihq Translate is available on iOS now. Using it as my new default.

https://apps.apple.com/se/app/kagi-translate/id6748310237?l=en-GB

@kopper @hongminhee As the person probably most responsible for making sure json-ld stayed in the spec (two reasons: because it was the only extensibility answer we had, and because we were trying hard to retain interoperability with the linked data people, which ultimately did not matter), I agree with you. I do ultimately regret not having a simpler solution than json-ld, especially because it greatly hurt our ability to sign messages, which has considerable effect on the ecosystem.

Mea culpa :\

I do think it's fixable. I'd be interested in joining a conversation about how to fix it.

One of the most interesting areas of exploration in the ActivityPub community right now is the ActivityPub API. Most people who know ActivityPub are familiar with its federation protocol, which lets social networking servers like Mastodon and Pixelfed share data between them. But there is another, closely-related feature in the same specification, called the "social API".

ActivityPub has five normative sections: 3 Objects, 4 Actors, 5 Collections, 6 Client-to-Server Interactions, and 7 Server-to-Server Interactions. 3, 4, and 5 provide a read-only interface to social data that is useful for both the federation protocol and the social API. It lets both clients and servers read information about users on the network, their feeds, and the things they make and share.

Section 6 is focused on the mechanism clients can use to create new activities, and the side-effects of those activities. "Activities" are the most important data structure in ActivityPub (which is why they're featured so prominently in the name!). They represent sentences or statements about things that happen on a social network, like "Christine created the image img123.jpg" or "Evan liked Christine's image img123.jpg" and "Amy shared Christine's image img123.jpg". Creating these statements is how clients can make things happen with ActivityPub.

Section 7 is focused on how and when servers can send these activities across the network to other servers. There are some side-effects that are laid out, but mostly they involve cache management.

So, here's the important point I want to make: the federation protocol which connects ActivityPub servers is defined in sections 3, 4, 5, and 7. The social API is defined in sections 3, 4, 5, and 6. But some people use "server-to-server" or "s2s" as a synonym for the federation protocol, even though "server to server interactions" only covers one section. Similarly, some people use "c2s" or "client-to-server" as a synonym for the social API, even if "client-to-server interactions" is only one section.

I prefer to use "social API" or "ActivityPub API" to refer to the entire part of ActivityPub that lets client apps talk to social servers. Here are some rough reasons why.

• It's what the spec calls it. In the conformance section, we said that 'this specification defines two closely related and interacting protocols: A client to server protocol, or "Social API" [...] A server to server protocol, or "Federation Protocol"'. This was intentional; the names come from the Social Web Working Group charter deliverables. Making a Social API was a key goal of the group. The ActivityPub API satisfies that goal.
• It's a term that all developers and many users are familiar with. People who've used mobile apps or third-party apps know what an API is and what it's for. If you use "c2s", it's not clear to most developers what you're even talking about.
• It's accurate. The social API is a RESTful API that uses JSON, HTTP, and all the fun stuff that app developers are already familiar with.
• It emphasizes what's already available. People often say that Mastodon does not implement the ActivityPub API. But it implements sections 3, 4, and 5 of the specification – it has to, in order to support the federation protocol. That's the entire read-only side of the API. All (almost all?) Fediverse servers support these parts of the spec, too. You can build a pretty OK read-only API client using what's already available from Mastodon and others; see https://acct.swf.pub/ for an example.
• "c2s" doesn't cover the whole API. As I said above, only one section of the doc is called "Client-to-Server Interactions", and it doesn't cover the read-only side of the API.
• "c2s" is insider jargon. c2s isn't a common term for RESTful APIs. It really isn't a common term at all; there are only a few protocol suites, like XMPP, that refer to the "c2s" and "s2s" part.

I think it's fine if others use "c2s" when talking about the API, or especially about section 6 of the ActivityPub spec. It's not going to cause any harm. But the Social Web Community Group task force on implementing the API is called the "ActivityPub API" task force. I think that's a good idea – it emphasizes the API. I intent to use this name and framing for the foreseeable future.

Speaking of the quality of Apple's Private Cloud Compute model…

🫥