洪 民憙 (Hong Minhee) :nonbinary:

知り合いの @siliconsjang さんが今日、SiliconBeest v1.0.0 を公開しました。Cloudflare Workers、D1、R2、Queuesだけで動くフェディバースサーバーで、Fedifyを使ってくれています。

個人的に面白いと思ったのは出発点で、Cloudflare障害のたびにフェディバースのサーバーがまとめて落ちるのを見て、「それならいっそCloudflareの上で動かせばよいのでは」と思ったのが始まりだそうです。

小規模なインスタンスならCloudflareの無料プランで、少し大きくなっても月5ドルくらいで運営できることを目指しているとのこと。まだ初期バージョンなので未実装の部分も多く、MastodonやMisskey APIとの互換性は未だ先の目標みたいです。

Fedifyを使ってくれているのもあって、個人的に嬉しいです。気になったので共有します。

ソースコードはAGPL 3.0でGitHubで公開されています。

#フェディバース #fediverse #ActivityPub #Cloudflare

RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

知人(지인)인 @siliconsjang 님이 오늘 SiliconBeest v1.0.0을 公開(공개)했습니다. Fedify와 Cloudflare를 基盤(기반)으로 만든 #聯合宇宙(연합우주) 소프트웨어인데, Workers, D1, R2, Queues 등 #Cloudflare 서버리스 스택 위에서 全部(전부) 돌아갑니다.

發想(발상)의 出發點(출발점)이 재밌습니다. Cloudflare 障礙(장애) 때 聯合宇宙(연합우주) 서버들이 덩달아 다운되는 걸 보고, 「그럼 아예 Cloudflare 위에서 돌리면 되지 않나?」라는 생각에서 始作(시작)했다고 하네요.

費用(비용) 面(면)에서는 小規模(소규모) 인스턴스는 Cloudflare 無料(무료) 플랜, 조금 더 큰 規模(규모)는 月(월) $5 플랜으로 堪當(감당)할 수 있도록 하는 게 目標(목표)라고 합니다. 아직 初期(초기) 버전이라 未具顯(미구현) 機能(기능)이 많고, Mastodon 및 Misskey API 互換(호환)은 長期(장기) 目標(목표)로 보고 있다네요.

Fedify를 써주시는 분이라 반갑기도 하고, 應援(응원)하고 싶어 紹介(소개)합니다.

소스 코드는 AGPL 3.0으로 GitHub에 공개되어 있습니다.

#ActivityPub #연합우주 #페디버스

RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

A friend of mine, @siliconsjang, released SiliconBeest v1.0.0 today. It's a #fediverse server built on #Cloudflare Workers, D1, R2, and Queues, using Fedify.

I like the starting point: after watching fediverse servers go down together during Cloudflare outages, they thought, why not just run on Cloudflare directly?

They're aiming for something cheap enough that a small instance can stay on Cloudflare's free plan, and a somewhat bigger one can fit in the $5/month tier. It's still early; a lot is missing, and Mastodon/Misskey API compatibility is more of a long-term goal.

I'm glad to see Fedify put to use for something like this. Worth checking out.

The source code is on GitHub under AGPL 3.0.

#ActivityPub #fedidev

RE: https://hackers.pub/@siliconsjang/2026/siliconbeest-v1.0.0

Drafting a proposal to add API support in #Fedify for the ActivityPub Media Upload extension, the SocialCG-incubated #C2S companion that lets clients upload media via a dedicated endpoints.uploadMedia endpoint, separate from the outbox.

The sketched API mirrors the outbox listeners shipped in Fedify 2.2: setMediaUploader(path, callback) paired with .authorize(). Return a vocab.Object for 201 Created, or a URL for 202 Accepted.

This is still an early design draft. Feedback on the shape, semantics, and edge cases is very welcome:

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

#ActivityPub #Fedify #fediverse #fedidev

Unless something comes up, #Fedify 2.2.0 will be released today.

If you'd like to preview the #tutorial I'm writing on building a small federated image sharing service, similar to @pixelfed, with @fedify and @nuxt, here it is:

https://pr-731-0.fedify.pages.dev/tutorial/content-sharing

If you'd like to give feedback after reading it, please leave a comment on the following PR:

https://github.com/fedify-dev/fedify/pull/731

#Fedify #fedidev #ActivityPub #Nuxt #Pixelfed

Honestly, I don't really care what strategy other #ActivityPub implementations follow to comply with the spec. (I solved it in #Fedify by just using a proper JSON-LD processor.) It's just a bit annoying that I always send valid JSON-LD documents, but whenever I encounter an interoperability bug where the other side can't process them, I'm the one who has to send them a patch to fix it. 😩

If you'd like to preview the #tutorial I'm writing on building a small #threadiverse software with #Fedify, here it is:

https://pr-710.fedify.pages.dev/tutorial/threadiverse

If you'd like to give feedback after reading it, please leave a comment on the following PR:

https://github.com/fedify-dev/fedify/pull/710

Writing a #Fedify tutorial on creating #threadiverse software…

Commander.jsの.conflicts()や.implies()は、排他的な組み合わせをランタイムではちゃんと検出してくれます。

でも.opts()の型は賢くならず、戻り値は結局string | undefinedのままです。どのオプションが同時に使えないのかを、TypeScriptは知りません。

このズレをパーサーコンビネータでどう型に落とし込めるか、Yargsとの比較も含めて書きました。後半では、環境変数・設定ファイル・対話プロンプトまで同じ型保証を広げる話もしています。

https://zenn.dev/hongminhee/articles/6ba2a6247ec0c4

#Optique #Commander #Yargs #TypeScript #JavaScript #CLI

I wrote about a problem that's been bugging me with #Commander.js and #Yargs: .conflicts() and .implies() enforce constraints at runtime, but the type you get back is still a flat object with every field optional. The compiler has no idea which options belong together.

The post walks through what happens when you express the same constraints in the parser structure instead, and how #TypeScript turns that into a discriminated union where each branch carries only its own fields.

Second half covers a less obvious question: what happens when values come from env vars, config files, or prompts instead of argv, and whether the constraints should still hold across all of them.

https://hackers.pub/@hongminhee/2026/optique-10-discriminated-unions-for-cli

#JavaScript #CLI #Optique

#Optique 1.0.0 is out! If you build #CLI tools with #TypeScript, it might be worth a look.

I started it because I wanted a TypeScript CLI parser that felt more like optparse-applicative than the usual builder-style APIs. You build up small typed parsers, compose them, and TypeScript infers the result. It handles subcommands, option dependencies, shell completion, and man pages, and it runs on #Deno, #Node.js, and #Bun.

For 1.0 I added @optique/env, so env vars can fill in missing flags, and @optique/inquirer, so missing values can fall back to Inquirer.js prompts. I also cleaned up a lot of awkward API edges and fixed a long backlog of completion bugs across five shells.

Packages are on JSR and npm.

https://github.com/dahlia/optique/discussions/796

はじめまして！ソウル在住の30代後半のオープンソースソフトウェアエンジニア、洪 民憙（ホン・ミンヒ）と申します。バイセクシュアル（bisexual）・ノンバイナリー（non-binary）で、自由・オープンソースソフトウェア（F/OSS）とフェディバース（fediverse）の熱烈な支持者です。

STF（@sovtechfund）の支援を受け、TypeScript用ActivityPubサーバーフレームワーク「@fedify」の開発に専念しています。他にも、おひとり様向けのActivityPubマイクロブログ「@hollo」、ActivityPubボットフレームワーク「@botkit」、ソフトウェア開発者向けフェディバースプラットフォームHackers' Pub、JavaScript・TypeScript用ロギングライブラリLogTapeなどの制作者でもあります。

東アジア言語（いわゆるCJK）とUnicodeにも興味があります。このアカウントでは主に英語で投稿していますが、時々日本語や国漢文混用体（漢字ハングル混じり文）の韓国語でも書いています。実はこの文体で書きたくてフェディバースを始めた、という経緯もあります。日本語、英語、韓国語、漢文でも気軽に話しかけてください！

#自己紹介

安寧(안녕)하세요! 저는 서울에 살고 있는 30代(대) 後半(후반)의 오픈 소스 소프트웨어 엔지니어 洪民憙(홍민희)입니다. 兩性愛者(양성애자)(bisexual)이자 논바이너리(non-binary)이며, 自由(자유)·오픈 소스 소프트웨어(F/OSS)와 聯合宇宙(연합우주)(fediverse)의 熱烈(열렬)한 支持者(지지자)이기도 합니다.

STF(@sovtechfund)의 支援(지원)을 받아 TypeScript用(용) ActivityPub 서버 프레임워크 @fedify 開發(개발)에 專業(전업)으로 任(임)하고 있습니다. 그 外(외)에도 싱글 유저用(용) ActivityPub 마이크로블로그 @hollo, ActivityPub 봇 프레임워크 @botkit, 소프트웨어 開發者(개발자)를 위한 聯合宇宙(연합우주) 플랫폼 Hackers' Pub, JavaScript·TypeScript用(용) 로깅 라이브러리 LogTape 等(등)의 製作者(제작자)이기도 합니다.

東(동)아시아 言語(언어)(이른바 CJK)와 Unicode에도 關心(관심)이 많습니다. 이 計定(계정)에서는 主(주)로 英語(영어)로 포스팅하지만, 때때로 日本語(일본어)나 國漢文混用體(국한문 혼용체) 韓國語(한국어)로도 씁니다. 聯合宇宙(연합우주)에 오게 된 動機(동기) 中(중) 하나가 바로 國漢文混用體(국한문 혼용체)로 글을 쓰고 싶었기 때문이기도 하고요. 韓國語(한국어), 英語(영어), 日本語(일본어), 아니면 漢文(한문)으로도 말을 걸어주세요!

#툿친소 #연친소 #별친소 #자기소개

The #CFP for the Fediverse & Social Web track at COSCUP 2026 (Taipei, Aug 8–9) is now open! If you're working on #ActivityPub, the #fediverse, or anything in the open social web space, we'd love to hear from you. The deadline is May 9. #COSCUP is free to attend.

👉 https://hackers.pub/@fedidevkr/2026/fediverse-social-web-track-at-coscup-2026-cfp

(Boosts appreciated!)

#SocialWeb #fedidev

@COSCUP 2026（台北、8月8–9日）にて、Fediverse & Social Webトラックが採択されました！#フェディバース、#ActivityPub、オープンなソーシャルウェブをテーマに、丸一日・計6時間のトラックを予定しています。

発表者向けのCFPはまだ始まっていませんが、公開され次第お知らせします。お楽しみに！

#Fediverse #SocialWeb #COSCUP #ActivityPub #fedidev

@COSCUP 2026(臺北(타이베이), 8月(월) 8–9日(일))에서 저희 Fediverse & Social Web 트랙이 承認(승인)되었습니다! #聯合宇宙(연합우주), #ActivityPub, 오픈 소셜 웹을 主題(주제)로 하루 終日(종일), 總(총) 6時間(시간)을 進行(진행)할 豫定(예정)입니다.

發表者(발표자) 募集(모집) CFP는 아직 열리지 않았지만, 始作(시작)되는 대로 바로 公知(공지)하겠습니다. 期待(기대)해 주세요!

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

So, an interesting issue came up in the #Fedify repo that I've been thinking about: #629.

You know how every #fediverse server uses schema:PropertyValue in actor attachment for profile metadata fields (like “Website”, “GitHub”, etc.)? Turns out, strict #AS2 validators like browser.pub reject it, because the AS2 spec says attachment should only contain Object or Link—and PropertyValue is a schema.org type, not an Activity Streams 2.0 type.

The thing is, we can't just drop the type like we did with Endpoints (#576), because Mastodon and others rely on seeing "type": "PropertyValue" to render profile fields. But at the same time, it's technically not spec-compliant.

I'm leaning towards writing a #FEP to formalize this existing practice rather than trying to invent a new type (like toot:PropertyValue extending Object), which would be a nightmare to migrate across the whole fediverse.

What do you all think? Has anyone else run into this? Would love to hear thoughts from implementers and spec folks.

#fedidev #ActivityPub #ActivityStreams #ActivityStreams2 #AS2 #PropertyValue

A daily minor annoyance: #GFM (GitHub Flavored Markdown) breaking standard #Markdown behavior by rendering single newlines as <br>.

If you're used to formatting plain text with hard wraps for mailing lists, you know the pain. You type up a perfectly readable 80-column text block, hit submit, and realize #GitHub has turned it into a jagged mess of arbitrary line breaks. I really miss standard Markdown paragraph collapsing in issue trackers.

Just had to add a workaround to #Fedify for http://joinmastodon.org/ns, a JSON-LD context URL that has never actually served a JSON-LD document. Mastodon has always inlined the term definitions, but some implementations put it as a bare URL in their @context, so Fedify's JSON-LD processor tries to fetch it and gets a 404 Not Found. Now Fedify ships a bundled copy of a context that never existed in the first place.

https://github.com/fedify-dev/fedify/pull/631

#fedidev #ActivityPub #JSONLD

Optique just crossed 600 GitHub stars!

For those unfamiliar: #Optique is a #CLI parsing library for #TypeScript that takes a parser combinator approach, inspired by Haskell's optparse-applicative. The core idea is “parse, don't validate”—you express constraints like mutually exclusive options or dependent flags through types, and TypeScript infers the rest automatically. No runtime validation boilerplate needed.

It started as something I built out of frustration while working on Fedify, an ActivityPub framework, when no existing CLI library could express the constraints I needed in a type-safe way. Apparently I wasn't the only one who felt that way.

Thank you all for the support.

https://github.com/dahlia/optique

Salvatore Sanfilippo (@antirez) and Armin Ronacher (@mitsuhiko) both argue that #AI reimplementation of #copyleft libraries is fine. Their legal reasoning might be correct. That's not the point.

Legal and legitimate are different things—and both pieces quietly assume otherwise.

https://writings.hongminhee.org/2026/03/legal-vs-legitimate/

#GPL #LGPL #license #opensource #freesoftware

I've been increasingly concerned about the corporate monopoly over frontier LLMs. While many ethically-minded people choose to boycott these models, I believe passive resistance alone cannot break the structural grip of big tech. To truly “liberate” these technologies and turn them into public goods, we need to look beyond moral high grounds and engage with the material basis of AI—specifically compute, data, and the relations of production.

I've written two posts exploring this through the lens of historical materialism. The first piece analyzes why current “open source” definitions struggle with LLMs, and the second discusses what it means to “act materialistically” in our imperfect world. My goal is to suggest a path forward that moves from mere boycotting to a more proactive, structural socialization of AI infrastructure.

If you've been feeling uneasy about the AI landscape but aren't sure if boycotting is the final answer, I'd love for you to give these a read:

• Histomat of F/OSS: We should reclaim LLMs, not reject them
• Acting materialistically in an imperfect world: LLMs as means of production and social relations

#LLM #AI #opensource #historicalmaterialism #histomat #materialism #digitalcommons

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

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

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

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

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

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

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

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

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

#Optique 1.0.0 is shaping up, and three API changes are worth knowing about in advance.

• Runner consolidation: run() from @optique/run now accepts source contexts directly, which makes runWith() and runWithConfig() redundant for most use cases. runWithConfig() is removed outright—no deprecation, since we have a major version to absorb the break. For the typical CLI, run() is now the single entry point.

• Meta command config redesign: help, version, and completion in RunOptions no longer use mode: "command" | "option" | "both". Each now takes independent command and option sub-configs, which makes it possible to give --help a -h alias, hide a meta command from usage lines while keeping it in the help listing, or group the command and option forms differently. String shorthands (help: "both", version: "1.2.3", etc.) still work exactly as before.

• Config-file-relative paths: bindConfig()'s key callback now receives config file metadata as a second argument—configDir and configPath—so you can resolve paths relative to the config file's location rather than the working directory. This matches how tools like the TypeScript compiler handle outDir and similar path options.

More details on the 1.0.0 milestone.

A couple days ago, I got a DM from a #Bonfire user. I happily replied and sent a follow request—but the Accept never came back, even though they hadn't enabled manuallyApprovesFollowers. My DM reply probably never arrived either. Classic interop bug.

I checked out the Bonfire source and dug in. Turns out Bonfire hasn't implemented RFC 9421 yet, so it was silently discarding any activity signed with it. That alone would be workable, except for one more issue: Bonfire was responding 200 OK even when signature verification failed, instead of 401 Unauthorized.

This matters because Fedify implements a double-knocking mechanism—if a request signed with RFC 9421 fails, it retries with the older draft cavage signature. But since Bonfire returned 200 OK on the failed first knock, #Fedify had no reason to send a second one.

I filed two issues on the Bonfire #ActivityPub repo—one requesting RFC 9421 support, and one about returning 401 on invalid signatures. For the latter, I also sent a PR, which got merged pretty quickly: bonfire-networks/activity_pub#9.

That said, individual Bonfire instances won't pick up the fix until they actually deploy it. So in the meantime, I patched Hollo and Hackers' Pub to use draft-cavage-http-signatures-12 as the firstKnock, so Bonfire instances can at least understand the first request.

One last thing: Fedify caches whether a given server supports RFC 9421, and the Bonfire servers I'd already talked to were cached as “supports RFC 9421”—because they'd been returning 200 OK. I had to manually clear that cache on both hollo.social and hackers.pub before everything finally worked.

After all that, the mutual follow went through and my DM reply landed. Worth it.

#fedidev #fediverse #Hollo #HackersPub

Hi #fediverse and #ActivityPub developers!

I'm currently working on interoperability testing for #Hollo and #Fedify, and I need a #Bonfire account to test federation with their implementation.

Since there aren't many open public Bonfire instances available, I was wondering if any Bonfire instance admins out there would be willing to grant me a test account? It would be a huge help for improving interop! Let me know if you can help. Thanks!

#fedidev #BonfireNetworks

Did you know there's a community space for #Fedify, #Hollo, #BotKit, and other Fedify ecosystem projects?

Whether you have questions, want to share what you're building, or just want to hang out with fellow fediverse developers—come join us!

• Matrix: #fedify:matrix.org
• Discord

I have deeply mixed feelings about #ActivityPub's adoption of JSON-LD, as someone who's spent way too long dealing with it while building #Fedify.

Part of me wishes it had never happened. A lot of developers jump into ActivityPub development without really understanding JSON-LD, and honestly, can you blame them? The result is a growing number of implementations producing technically invalid JSON-LD. It works, sort of, because everyone's just pattern-matching against what Mastodon does, but it's not correct. And even developers who do take the time to understand JSON-LD often end up hardcoding their documents anyway, because proper JSON-LD processor libraries simply don't exist for many languages. No safety net, no validation, just vibes and hoping you got the @context right. Naturally, mistakes creep in.

But then the other part of me thinks: well, we're stuck with JSON-LD now. There's no going back. So wouldn't it be nice if people actually used it properly? Process the documents, normalize them, do the compaction and expansion dance the way the spec intended. That's what Fedify does.

Here's the part that really gets to me, though. Because Fedify actually processes JSON-LD correctly, it's more likely to break when talking to implementations that produce malformed documents. From the end user's perspective, Fedify looks like the fragile one. “Why can't I follow this person?” Well, because their server is emitting garbage JSON-LD that happens to work with implementations that just treat it as a regular JSON blob. Every time I get one of these bug reports, I feel a certain injustice. Like being the only person in the group project who actually read the assignment.

To be fair, there are real practical reasons why most people don't bother with proper JSON-LD processing. Implementing a full processor is genuinely a lot of work. It leans on the entire Linked Data stack, which is bigger than most people expect going in. And the performance cost isn't trivial either. Fedify uses some tricks to keep things fast, and I'll be honest, that code isn't my proudest work.

Anyway, none of this is going anywhere. Just me grumbling into the void. If you're building an ActivityPub implementation, maybe consider using a JSON-LD processor if one's available for your language. And if you're not going to, at least test your output against implementations that do.

#JSONLD #fedidev

@reiver, is #FediCon going to be held in #Vancouver again this year?

Why #Markdown's emphasis syntax (**) fails outside of Western languages: A deep dive into #CommonMark's “delimiter run” flaws and their impact on #CJK users.

A must-read for anyone interested in #internationalization and the future of Markdown:

https://hackers.pub/@yurume/019b912a-cc3b-7e45-9227-d08f0d1eafe8

#Optique 0.9.0 is here!

This release brings #async/await support to #CLI parsers. Now you can validate input against external resources—databases, APIs, Git repositories—directly at parse time, with full #TypeScript type safety.

The new @optique/git package showcases this: validate branch names, tags, and commit SHAs against an actual Git repo, complete with shell completion suggestions.

Other highlights:

• Hidden option support for deprecated/internal flags
• Numeric choices in choice()
• Security fix for shell completion scripts

Fully backward compatible—your existing parsers work unchanged.

https://github.com/dahlia/optique/discussions/75

Released Vertana 0.1.0—agentic #translation for #TypeScript/#JavaScript.

Instead of just passing text to an #LLM, it autonomously gathers context from linked pages and references to produce translations that actually understand what they're #translating.

• Docs: https://vertana.org/
• GitHub: https://github.com/dahlia/vertana

#opensource

With high-performance #Python type checkers like #Pyright, #Pyrefly, and #ty now available, what's the value proposition of #Mypy? Is it the reference implementation? Or does Mypy still have the most features? I'm not trying to knock Mypy, I'm genuinely asking because I don't know.

Found this helpful resource by Ben Boyter (@boyter): a collection of sequence diagrams explaining how #ActivityPub/#WebFinger works in practice—covering post creation, follows, boosts, deletions, and user migration.

If you're trying to implement ActivityPub, the spec can be frustratingly vague, and different servers do things differently. This aims to be a “clean room” reference for getting federation right.

https://github.com/boyter/activitypub

#fediverse #fedidev

Here's a #TypeScript API design challenge I'm working on: adding async support to #Optique (CLI argument parser) without breaking the existing sync API.

The tricky part is combinators—when you compose parsers with object() or or(), the combined parser should automatically become async if any child parser is async, but stay sync if all children are sync. This “mode propagation” needs to work at both type level and runtime.

I've prototyped two approaches and documented findings. If you've tackled similar dual-mode API designs, I'd love to hear how you approached it.

https://github.com/dahlia/optique/issues/52

CLIパーサーの新しい記事を書きました。--reporterの値によって--output-fileが必須になったり禁止になったり…そういう関係、型で表現できたら楽じゃないですか？

https://zenn.dev/hongminhee/articles/201ca6d2e57764

#TypeScript #CLI #Optique

早晩間(조만간) 몇 個月(개월)만의 새 #Hollo 마이너 릴리스(v0.7.0)이 나올 것 같다.

It looks like a new minor release of #Hollo (v0.7.0) will be out soon, the first in several months.

Interesting design question for #Optique (a type-safe #CLI parser for #TypeScript): how should it handle unrecognized options in wrapper/proxy tools? Proposed three modes but wondering if the complexity is worth it. Thoughts?

https://github.com/dahlia/optique/issues/35

Every time I try to publish a package to #JSR (JavaScript Registry), it frequently gets stuck in the “processing” state, so I'm seriously considering whether I should stop publishing my TypeScript packages there altogether. 🤔

Holloをお使いの方は、できるだけ早く0.6.12バージョンにアップデートしてください。DMが公開投稿ページで露出する深刻なセキュリティ脆弱性が修正されました。

https://hollo.social/@hollo/0199aaaf-7979-7da3-9509-73c9e487de05

#Hollo #セキュリティ #脆弱性

#Hollo 쓰시는 분들은 可能(가능)한 限(한) 빨리 0.6.12 버전으로 올리시기 바랍니다. DM이 公開(공개) 揭示物(게시물) 페이지에서 露出(노출)되는 深刻(심각)한 保安(보안) 脆弱點(취약점)이 패치되었습니다.

https://hollo.social/@hollo/0199aaaf-7979-7da3-9509-73c9e487de05

#보안 #취약점

If you're running #Hollo, please update to version 0.6.12 as soon as possible. A critical #security #vulnerability has been fixed where direct messages were being exposed on public post pages.

https://hollo.social/@hollo/0199aaaf-7979-7da3-9509-73c9e487de05

Why is publishing packages to #JSR so slow? A lot of the CI time for the Fedify project is spent waiting for the JSR server to process the packages we've uploaded.

Today I discovered an interesting inconsistency in Activity Streams specs while investigating a Fedify issue.

The question: How should we interpret URLs like "icon": "https://example.com/avatar.png"?

JSON-LD context (https://www.w3.org/ns/activitystreams): @type: "@id" → “This is an IRI reference, dereference it to fetch an ActivityStreams object.”

Activity Streams Primer: “assume that a bare string is the href of a Link object, not an id” (no dereferencing)

Result: JSON-LD processor-based implementations try to parse PNG files as JSON and fail.

Turns out w3c/activitystreams#595 already discusses the same issue for href properties. I added a note that icon, image, etc. have the same problem.

Once again reminded of how tricky spec work can be…

#ActivityPub #Fedify #ActivityStreams #fedidev #specifications