洪 民憙 (Hong Minhee)

[Federated systems need better affordances]
by @voboda
https://blog.voboda.com/better-affordances-for-federated-systems

#moim_live #fedidev

I'm building an open source ActivityPub service called "Moim" — 모임 in Korean, meaning gathering or meetup. It started as a federated RSVP service, but I realized I wanted to connect people even beyond events. Events are where people come together, yes — but places carry meaning on their own, even in quiet, ordinary moments.

So Moim is about helping people feel connected: through events, and through the simple act of sharing where they are.

Right now, I'm focusing on three areas:

• CRM for Event Organizers A proper SaaS-like experience built for people who run events. I'm actively reaching out to organizers to shape this.
• A Federated RSVP Service I want Moim's RSVP experience to feel just as polished as anything outside the Fediverse — and ideally, better. Being federated shouldn't mean settling for less.
• A Check-in Sharing System I miss what Foursquare Swarm used to be. I want to bring that feeling back, built for the Fediverse.

I don't know yet if I'm building the right thing. But I'll keep going, and do my best to make it something worth using. If I'm ready, I will officially announce to public.

선비 브라우저 擴張 프로그램 테스트 用 글.

moim.live 에 authorized fetch 지원 완료

Let's stop saying Fediverse is federated + universe and start saying it's federated + diverse

最近、開発作業でよく使うツールをいくつか変更した。

最初のきっかけは、コードエージェントをもう少し快適に使える環境を探していて Warp を試してみたことだったと思う。そこから連鎖的に環境を見直すことになり、

• tmux → zellij
• zsh → fish
• vi → hx (Helix)
• iTerm2 → Ghostty という感じで、思った以上に大きく変わった。
• 最初は軽く触ってみるだけのつもりだったのだが、使い心地がかなり良くて、業務用のMacはほぼ完全にこの環境へ移行した。個人用のMacは、時間があるときに少しずつ切り替えていく予定。
• とはいえ、まだいくつか気になるバグもある。例えば、zellijで韓国語フォルダ名が文字化けする問題、fish + Ghostty の組み合わせで、ウィンドウサイズを小さくすると thread 'main' panickedが出る問題 など。
• 完全に安定しているとは言い難いが、今のところは許容しながら使っている。

Obsidian への完全移行

• ただ、それ以上に大きな変化だったのは ドキュメント管理を Obsidianに移したこと。実は3年くらい前にも、業務日誌を書く用途で少しだけ使っていたのだけど、そのときは結局定着しなかった。今回は思い切って、個人用・業務用を含めたすべての「第二の脳」的なメモ保管庫として使い始めた。過去のメモも、時間を見つけて少しずつ移行している。これまで使っていたメモツールはこんな感じ。Heynote, Simplenote, vscode-memo-life-for-you, Dynalist, Notion, そのほか、Google DriveやDropboxに散らばっているドキュメント。正直、かなり分散していた。

移行のきっかけ

きっかけは、Claude Codeとの会話ログや plan.md（計画ファイル）を保存する場所を探していたこと。ちょうど良い Markdown ベースの保存場所を探していて、「そういえば Obsidian があったな」と思い出した。さらに調べてみると、今後 CLIサポートも予定されている、プラグインが非常に豊富、 Markdownベースでローカル管理できる。など、改めて見るとかなり自分の用途に合っている。それに、今の時代は AIに相談しながら段階的に環境を整えられるので、プラグインの多さにもそこまで抵抗を感じなかった。

一番気に入っているポイント

そして、個人的に一番気に入っているのはアプリ内のフォントを自由に変更できること。 Macでも、モバイルアプリでもフォントを変えられるのは、自分にとってはかなり大きい。 Obsidian自体もそのままで十分気に入っているのだけど、正直このフォント変更機能だけでも、多少の不満点はすべて相殺できるくらいのメリットだと思っている。

メタモンのシロノワールブルーベリーフロマージュ食べにコメダ珈琲店に来た。

モスバーガーに来て焼肉のライスバーガーを食べた。写真は無い。

getting reccomended a Korean video teaching a Chinese part of Japanese auto-translated to English

I'm sure this will be very useful to me.

京鴨汁つけうどんを食べに来た。

@wildwestrom 그냥 놀러 왔어요! 사람들도 좀 만나고요. ㅎㅎ

宿にチェックインした。

@Yohei_Zuho 😭

Always forgetting to use `.at(-1)` to get last element in an array.

#JavaScript

@Yohei_Zuho 花粉症のせいですか？

成田空港に着いた。

仁川空港に来た。

문제

Nix는 설계 철학상 Nix 언어(순수 함수형 평가 언어)와 Nix store(콘텐츠 주소 기반 저장소)가 별도의 레이어로 분리되어 있다. 그러나 현실에서는 Nix 언어가 store에 대해 특권적 지위를 갖고 있으며, 이 둘 사이에 명시적인 인터페이스 경계가 존재하지 않는다.

특권적 지위의 구체적 양상

• 유일한 공식 진입점: derivation을 생성하고 store에 등록하는 사실상 유일한 경로가 Nix 언어 평가기다. nix build, nix develop 등 CLI 도구도 내부적으로 Nix 평가기를 호출한다.
• 생태계 종속: nixpkgs 전체가 Nix 언어로 작성되어 있고, flake 시스템도 Nix 평가기를 전제한다. 대안 언어는 항상 이등 시민이다.
• 순수성에 대한 신뢰 의존: store의 무결성이 Nix 언어의 순수성(부작용 없음, string context를 통한 의존성 추적 등)에 의존한다. 이는 언어 구현의 정확성을 믿어야 하는 취약한 신뢰 모델이다.

기존 우회 시도의 한계

• Guix: Nix 언어 대신 Guile을 프론트엔드로 사용하지만, nixpkgs를 재사용하지 못하고 생태계를 처음부터 다시 구축해야 했다.
• Tvix: store를 다른 방식으로 구현하려 했지만, 결국 Nix 언어의 호환 평가기를 만드는 데 상당한 비용을 치르고 있다.
• Recursive Nix: 빌드 시점에 다른 언어에서 Nix daemon을 호출할 수 있지만, 최상위 진입점은 여전히 Nix 언어가 쥐고 있다. 탈출구는 생겼지만 그 문을 여는 열쇠는 Nix 언어에 있다.

제안: 모든 언어를 Sandbox 안으로

핵심 아이디어: Nix 언어 평가기를 포함한 모든 프론트엔드 언어를, Nix sandbox 안에서 마운트된 Nix daemon 소켓을 통해서만 store와 상호작용하도록 한다.

구조 변경

[현재]
Nix 언어 평가기 ──(특권적 접근)──▶ Nix Store

[제안]
┌─── Sandbox ────────────────────┐
│  Nix 언어 평가기                  
│  Guile / Python / Rust / ...   │──(daemon 소켓)──▶ Nix Daemon ──▶ Nix Store
│  (네트워크 없음, FS 격리)           
└────────────────────────────────┘

동작 방식

1. 프론트엔드 언어(Nix 포함)는 sandbox 안에서 실행된다. 네트워크 접근 불가, 파일시스템 격리.
2. Store 관련 모든 동작(derivation 등록, store path 조회, 빌드 요청 등)은 sandbox 안에 마운트된 Nix daemon 소켓을 통해서만 수행한다.
3. Daemon이 store의 무결성을 보장하는 유일한 주체가 된다.

이점

1. 신뢰 모델의 단순화

언어의 순수성을 신뢰할 필요가 없다. Sandbox가 커널 레벨에서 격리를 강제하므로, 어떤 언어가 sandbox 안에서 무엇을 하든 store의 무결성은 daemon이 보장한다. 언어 의미론에 의존하는 신뢰보다 OS 레벨 격리에 의존하는 신뢰가 훨씬 견고하다.

2. 언어 간 동등한 지위

Nix, Guile, Python, Rust 등 어떤 언어든 sandbox 안에서 daemon 소켓 프로토콜을 사용하는 것은 동일하다. nixpkgs가 Nix로 작성되어 있다는 것은 생태계의 역사적 선택일 뿐, 아키텍처가 강제하는 것이 아니게 된다.

3. 기존 특수 케이스의 일반화

• IFD(Import From Derivation): 평가 중에 빌드를 트리거하는 특수 케이스가 아니라, sandbox 안에서 daemon에게 빌드를 요청하는 일반적 동작이 된다.
• Recursive Nix: 별도 기능이 아니라 당연한 패턴이 된다.
• 평가와 빌드의 경계가 모호해져도 sandbox가 격리를 보장하므로 문제가 되지 않는다.

요약

현재 Nix 아키텍처에서 언어 레벨의 순수성이 담당하는 보안 역할을, OS 레벨의 격리(sandbox + daemon 프로토콜)로 내리자는 것이 이 제안의 핵심이다. 이를 통해 Nix 언어의 특권적 지위가 제거되고, 모든 프론트엔드 언어가 동등한 조건에서 Nix store를 활용할 수 있게 된다.

@esna 이미 國漢文混用體(국한문 혼용체)로 쓰고 있습니다. 😎

明日からHaze Leeさん（@nebuleto）と一緒に一週間東京に旅行に行くんだ。楽しみ！

지난 며칠 동안 〈F/OSS 史唯(사유): 우리는 LLM을 拒否(거부)할 게 아니라 되찾아 와야 한다〉 및 〈不完全(불완전)한 世上(세상)에서 唯物論的(유물론적)으로 行動(행동)하기: 生產(생산) 手段(수단)으로서의 LLM과 社會的(사회적) 關係(관계)〉를 둘러싸고 사람들과 論爭(논쟁)하며 느낀 點(점)…

西歐圈(서구권) 聯合宇宙(연합우주)에서는 LLM 및 AI 全般(전반)에 對(대)해 情緖(정서)가 매우 안 좋다보니, 애當初(당초) LLM이나 AI의 쓸모 自體(자체)를 否定(부정)하는 境遇(경우)가 많은 듯. 쓸모가 없는 技術(기술)이라면, 그 技術(기술)에서 물을 한 방울만 쓰더라도 浪費(낭비)가 된다. 價値(가치)와 費用(비용)의 셈 自體(자체)가 달라져 버리는 것. 그래서 均衡(균형) 잡힌 論議(논의)를 이루기까지 미리 說明(설명)하고 說得(설득)해야 하는 地點(지점)이 너무 많다.

While I have no ill will toward the “ATmosphere” (Bluesky/AT Protocol), the contrast in funding models is hard to ignore. The fediverse's support from strategic investments in open infrastructure (like NLnet or STF) feels far healthier than ATmosphere's heavy backing from crypto-linked VCs—a sector often fraught with bubbles and social harm. I'm a bit envious of their smooth R&D resources, but I'm ultimately convinced that building on a foundation of digital public goods is the more sustainable path for a truly decentralized web.

@mathieui Thanks for engaging with this. I appreciate the pushback, and I think some of your concerns are worth taking seriously.

That said, I want to clarify something about my position: TGPL (or any specific licensing mechanism) is just one possible avenue among many. The broader argument isn't tied to any single instrument. Regulatory pressure on governments to mandate that models trained on public data be returned to the public, expanded public funding for open research infrastructure, international treaty reform—these are all on the table. The point is strategic pluralism, not a bet on one tool.

On the copyright concern: yes, major players have shown contempt for copyright. But that's precisely why I think purely technical or market-based solutions are insufficient, and why political and legislative pressure matters. The history of generic medicine access is instructive here—no single mechanism won that fight, but the combination of compulsory licensing advocacy, treaty pressure, and public funding reform produced real change over time.

Now, your Luddite parallel: I actually think it argues for my position rather than against it. You're right that the weavers never reclaimed the technology. But the lesson I draw from that isn't “therefore reclamation is impossible.” It's that refusing or destroying the means of production doesn't work. What eventually produced change was organized labor movements that took the existence of that technology as a given and fought over who controls it and under what conditions. That's exactly the kind of struggle I'm advocating for here.

The real question you're raising, I think, is about the subject: is there an organized political force capable of carrying this through? That's a fair and hard question. But it's an argument for building that force, not for abandoning the goal.

@fabrice I hear your concerns about burnout, and as someone who has actually secured STF investment for my project (Fedify), I won't pretend the administrative overhead is non-existent. It's a real challenge.

However, in my experience, that effort is a price well worth paying for the autonomy and long-term value it secures. For me, navigating “administrative fragility” is a manageable hurdle compared to the structural risk of VC influence. It's not about finding a perfect, effortless funding source—it's about choosing which struggles are worth our time to preserve the integrity of the decentralized web.

@mro Valid points. The “Large” in LLM indeed mirrors the “Big” in Big IT—that is precisely the materialist contradiction I'm highlighting. Currently, the scale required for these models forces a centralized, corporate structure.

Regarding productivity: as a developer, I view LLM not just as a “code generator” (where the ±20% debate happens), but as a new layer of interface for complex information. Whether it's asbestos or X-ray, the reality is that the “means” are already being deployed at a massive scale, shaping our digital society.

You mentioned focusing on the ends. I agree. But in our current system, the “ends” are dictated by those who own the “means.” If the means (LLMs) remain a corporate monopoly, the “ends” will always be profit and surveillance.

My argument for socialization isn't about “more software” for the sake of it; it's about reclaiming the power to define the “ends.” We can't democratically decide how to use (or even limit) a technology if we don't own the infrastructure it runs on. Even if we decide to use it “narrowly and carefully” like X-rays, that decision should belong to the public, not a boardroom.

@mro Hi, thanks for the sharp analogy! The X-ray/asbestos comparison is a classic way to view the risks of new tech.

However, my argument for “socialization” stems from the belief that LLMs are a significant productive force. If we view them as “asbestos,” the logical step is a total ban. But if we see them as a “utility” (like electricity), the current corporate monopoly is the real poison.

In a historical materialism framework, the “toxic” side effects we see today—like reckless resource consumption or data exploitation—are often driven by the capitalist mode of production (profit-first scaling). By “liberating” or socializing the material basis of AI, we gain the democratic power to regulate its use and minimize those downsides, turning it into a true public good rather than a corporate hazard.

@fabrice You're right that constant grant-hopping is fragile, and I don't see it as a perfect endgame. However, my point about “healthiness” was less about financial stability and more about the alignment of incentives.

VC money inevitably demands a return on investment, which often leads to extractive business models down the line. I'd rather deal with the administrative “fragility” of public funding than the structural “shackles” of venture capital that might eventually compromise protocol neutrality. AT Protocol's rapid development is impressive, but for me, who owns the infrastructure is just as important as how fast it's being built.

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