Hello, I'm an open source software engineer in my late 30s living in #Seoul, #Korea, and an avid advocate of #FLOSS and the #fediverse.
I'm the creator of @fedify, an #ActivityPub server framework in #TypeScript, @hollo, an ActivityPub-enabled microblogging software for single users, and @botkit, a simple ActivityPub bot framework.
Has anyone made a good guide for how to ask for survival money on the fediverse yet? One that outlines how tagging strangers isn't a good long term strategy. That it can temporarily work for engagement but sooner or later you will either loose your account or get blocked so much that you don't have much reach. There is this influx of people trying to crowd fund for their survival coming here and we should help provide them with the means to continue to do so sustainability.
ALT text detailsAlt text: Screenshot of a Japanese homepage for distributed SNS users. Left shows colorful speech‑bubble mock posts with text and images; center displays a rainbow interconnected‑nodes logo; right shows a cluster of federated service icons. Large Japanese heading welcomes visitors and mentions ActivityPub; a blue button reads “サーバーを見てみる” (View servers).
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.
ALT text detailsCheck-in screen on Mobile
ALT text detailsAdmin Panel for managing group/place/moderation action
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.
ALT text detailsHand practices writing Japanese Kanji on paper with a pen. The paper displays the character 雜 and its reading "zatsu," along with annotations in Korean and Katakana. Below the video frame, text reads: "[Japanese Today] 715 / 雜 / This is a Chinese character that means to mix." and the channel name "오늘도 일본어."
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 포함)는 sandbox 안에서 실행된다. 네트워크 접근 불가, 파일시스템 격리.
Store 관련 모든 동작(derivation 등록, store path 조회, 빌드 요청 등)은 sandbox 안에 마운트된 Nix daemon 소켓을 통해서만 수행한다.
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를 활용할 수 있게 된다.