ATproto는 Mastodon과 연합 방식이 꽤 다르고, 여기엔 instance라는 개념이 없음
계정은 PDS에 호스팅되고 기록도 거기로 가지만, 앱에서 보이는 내용은 여러 PDS의 데이터를 모은 AppView가 제공함
그래서 어느 PDS에 있든 앱 경험은 중앙집중형 서비스처럼 느껴지고, AppView도 여러 개 둘 수 있으며 직접 호스팅도 가능함
AppView는 fediverse와 꽤 다르고, 명시적 federation보다 shared relay에 의존함
지금처럼 사실상 전역 발견성이 생기는 비용은 좀 고민되지만, 그렇다고 이걸 그냥 또 다른 Mastodon이라고 보긴 어려움
왜 꼭 한쪽 편을 들거나 정답인 편을 골라야 하는지 모르겠음
그냥 입장을 안 정하거나, 스스로 맞다고 생각하는 쪽으로 가면 되는 것 아닌가 싶음
좀 과장하긴 했지만, 설령 그렇다 해도 지금처럼 GitHub와 GitLab에 의존해야만 존재감이 생기는 구조보다는 훨씬 나아 보임
atprotocol 쪽에서 꽤 활발히 쓰는 편이라 편향됐을 수는 있지만, Tangled는 정말 만족스럽게 쓰고 있음
GitHub 대체제로 내가 원하던 모습에 제일 가깝고, 기능은 더 단순하지만 지난 1년 동안 개인 오픈소스 프로젝트의 주력 social/git 서비스였음
내 계정은 https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf임 Bluesky에서 알던 소셜 그래프가 이어져서 커밋, PR, 이슈 뒤에 있는 사람을 감각적으로 연결해 볼 수 있는 점이 좋고, 로그인도 다른 atproto 서비스와 같아서 편함
최근엔 정적 사이트 내장 지원도 들어가서 클라이언트 사이드 웹사이트나 간단한 index.html을 repo에서 바로 호스팅하기 좋음 Spindles가 빌드 시스템/액션 역할을 하는데, 내가 Nix 팬은 아니어도 필요한 용도엔 꽤 잘 맞았음 open API도 좋아서 atproto 기반 표준을 활용해 쉽게 정보 렌더링을 만들 수 있었고, 봇도 만들고 npmx.dev 기능도 몇 개 붙였음
직접 knot(git 서버)와 runner(Spindles)를 운영할 수도 있고 호스팅된 걸 써도 되는데, 핵심은 소셜 기능이 분리돼 있어서 git 서버가 따로 있어도 이슈나 PR 대화는 공용 소셜 레이어에서 이어진다는 점임
완벽하진 않고 네브바에 붙은 alpha 표시가 괜히 있는 건 아니지만, 오픈소스 작업용으로는 계속 쓰게 될 가능성이 큼
atproto가 Bluesky의 존재감 부족에 끌려갈까 봐 좀 걱정됨
그게 타당한 불안인지는 아직 잘 모르겠음
댓글 분위기는 꽤 부정적이지만, 나도 VC 자금을 경계하는 편이면서도 이 영역의 경쟁은 장려해야 한다고 봄
지금 시점에 이런 걸 bootstrap으로 시작하는 건 매우 어렵거나 사실상 불가능해 보이고, 어제 HN 상단에 있던 GitHub 비판 글들과 타이밍을 잘 맞춘 것도 맞지만 그래도 이런 시도 자체는 응원하고 싶음
의미 있는 규모로 자리 잡았으면 좋겠음
내가 보기에 이건 단순한 부정론이 아니라 실제 우려임
제목만 봤을 땐 기대했지만 VC 자금이 들어갔다는 걸 아는 순간 바로 고려 대상에서 빠졌음
돈도 못 버는 내 애정 프로젝트를 플랫폼에 올릴 거라면, 5년쯤 뒤에 rug pull이 나올 가능성이 낮은 곳을 고르고 싶음
VC 프로젝트는 투자금 회수를 해야 하니 결국 어떤 식으로든 rug pull이 올 거라고 봄
그래서 지금은 돈을 내는 고객으로 쓰거나, 조합원처럼 회비를 내고 의사결정에 투표권이 있는 서비스 쪽을 선호함
VC가 들어간 프로젝트는 결국 rug pull, 광고, 프라이버시 침해, 혹은 억지스러운 유료 기능 강화로 가기 쉬움
그래서 사용자 입장에선 그 가능성을 미리 알아야 함
곧 다가올 현실이 그런데도 지나치게 이상주의를 내세우는 서비스는 별로 좋아하지 않음
차라리 서비스 요금을 받거나, 정말 이상을 추구한다면 non-profit으로 시작하거나, 최소한 수익화 계획은 분명히 밝혀야 함
bootstrap이 왜 불가능하다고 보는지 잘 모르겠음
어렵다는 건 당연하지만, 특히 federation을 지향한다면 같은 비용이나 더 큰 비용이 아니라 오히려 더 저렴한 인프라로도 만들 수 있어야 하는 것 아닌가 싶음
과소평가에 가까움
지금까지 본 ATProto 입문 글 중에 제일 좋았음
혹시 이 글들을 한곳에 모아둔 태그나 목록이 따로 있는지 궁금함
내가 보기에 필요한 건 forge federation이 아니라 더 풍부한 git repo 자체임 Fossil은 티켓, 포럼, 위키를 저장소 일부로 통합해서 거의 90%쯤 와 있고, clone하면 그것들까지 같이 내려받아 오프라인에서도 볼 수 있음
비행기 안에서도 답글을 써둘 수 있고, 권한만 맞으면 바로 혹은 나중에 연결이 복구됐을 때 동기화할 수 있음
다만 특정 아티팩트 종류를 VCS에 하드코딩하는 대신, repo 안에 앱을 담고 그 앱이 어떤 아티팩트를 허용할지, 어떤 규칙을 따를지, 누가 언제 업로드/다운로드할 수 있을지 정하게 하는 방향이 더 좋아 보임
forge는 그 정책을 실행하고 웹 사용자에게 원하는 방식으로 렌더링만 해주면 됨
이렇게 되면 다른 forge로 옮기는 일도 결국 repo를 push하는 정도로 끝남
이거 정말 고마움
요즘 티켓 시스템이나 에이전트 같은 걸 git repo 안의 flat files로 만들고 있었는데, 이제 그걸 repo 관리 자체까지 확장해야겠다는 생각이 듦
엄청 좋아질 듯함
내가 느끼는 federated solution의 핵심 문제는 결국 cold start임
기존 대형 서버에 들어가면 벗어나려던 바로 그 중앙집중 문제를 다시 껴안게 되지만, 대신 처음부터 큰 네트워크는 얻음
반대로 직접 서버를 열면 네트워크는 0, 발견성도 0, 피드는 비어 있고, 다른 사이트들이 연합해주거나 1인 서버라는 이유로 막지 않게 설득해야 함
나만 이렇게 느끼는 건지, 아니면 federation을 잘못 이해한 건지 모르겠음
어쩌면 이건 그냥 Mastodon 특유의 문제일 수도 있음
그래서 Tangled는 ActivityPub 대신 ATproto를 택한 것 같음
개별 서버들을 중앙 AppView들이 한데 모아서, 중앙집중형 네트워크처럼 일관된 단일 뷰를 주도록 설계됐기 때문임
AppView는 누구나 호스팅할 수 있음
이득은 중간 지점에 있다고 봄
대형 서버가 moderation, 정책, 콘텐츠, 기술 문제로 수상해지면 비교적 쉽게 빠져나와 다른 꽤 큰 서버를 키우거나 옮길 수 있음
처음부터 어느 정도 평판과 규모가 있는 피난처를 만들 수 있다는 뜻임
이미 GitLab, Codeberg, freedesktop, Fedora, Debian 같은 대안 forge들이 있으니, 프로젝트의 가시성과 발견성만 유지된다면 충분히 안전한 대피처가 될 수 있음
나도 지금까지는 딱 그렇게 느껴서 federated 서비스들을 멀리했음
그런데 며칠 전 이 프로젝트를 보고는 이건 진짜 될 수도 있겠다고 생각했음
대상 사용자가 self-hosting에 익숙한 층과 꽤 많이 겹치기 때문임
내 전체 네트워크가 다 올 필요는 없고, 실제로 여기 올 가능성이 높은 그 하위 집단만 있어도 충분히 유용함
여기서 매력적인 건 self-host도 가능하고, 큰 제공자들 사이를 migration하는 것도 가능하다는 점임
프런트엔드 서버 비용은 아주 낮을 테니 거의 영구 운영도 가능해 보이고, 실제 데이터는 다른 호스트들이 공급함
Tangled가 VC 지원을 받는다는 점은 안정감보다 무조건 성장해야 한다는 압박으로 들림
매력을 잘 모르겠음
설령 federated라 해도 개발이 멈추면 버그를 고치고 유지보수할 사람이 누군가 싶음
Tangled는 전부 공개적으로 개발 중이고 https://tangled.org/tangled.org/core, 목표도 permanent software임
즉, 완전히 재현 가능하고 최소 비용으로 전부 self-host 가능하게 만들려는 것임
VC 자금은 목적이 아니라 수단일 뿐이고, 유럽에 있는 인도인 창업자 둘 입장에선 보조금은 실제로 나오기까지 4~12개월 이상 걸려 거의 비현실적이었다고 함
팀을 꾸리고 인프라를 세우고 개발을 가속하는 가장 빠른 길이 VC였고, 투자자와 목표 정렬도 강하게 맞췄으며 그 파트너를 찾는 데 6개월 넘게 썼다고 함
그걸 쓰는 사람들이 유지보수하면 됨 Tangled는 구조적으로 흥미로운 선택이 많지만 코드 자체는 비교적 단순하고, 직접 들여다본 바로도 유지보수 난이도는 높지 않아 보였음
대부분은 느슨하게 연결된 Go modules이고, 거기에 정적 HTML+CSS, 그리고 약간의 TypeScript와 오케스트레이션용 Nix가 얹힌 정도임
기억이 맞다면 하드웨어 요구량도 아주 작아서 지금 규모라면 개인 한 명이 직접 호스팅할 수 있음
실제 인프라 부담의 큰 부분은 사용자들의 knots, spindles, PDS와 atproto 전체가 맡음
지금 이 댓글도 VC 자금을 받은 뉴스 집계 사이트에 쓰고 있는데, 그걸 생각하면 꼭 그렇게 단정할 일인가 싶음
VC는 괜찮아도 YC 자금만 아니면 된다고 봄
이런 VC가 들어오면 두 가지를 묻게 됨
왜 꼭 VC가 필요한가, 왜 Ladybird처럼 기업 후원을 받지 않는가
그리고 투자자들이 10배 수익을 기대하는데, 결국 나중에 enshittification될 개발자 도구에 왜 시간을 써야 하는가
표준이 4개나 있어서 하나로 통일하자며 새 표준을 만들면 결국 표준이 5개가 되는 농담이 떠오름
농담은 그렇다 쳐도, 왜 ActivityPub으로는 부족한지 더 강한 근거가 필요하다고 봄
탈중앙 커뮤니케이션 문제를 또 다른 방식으로 다시 풀려 하기 전에 말임
ActivityPub과 atproto는 모양 자체가 다름
이걸 맞붙이는 건 이메일이 있는데 왜 웹이 필요하냐고 묻는 것과 비슷함
ActivityPub은 이메일처럼 서버가 받은편지함 역할을 하며 서로 메시지를 주고받는 구조임
반면 atproto는 웹처럼 사용자 저장소가 데이터를 호스팅하고, 앱이 그 저장소들에서 데이터를 모아 보여줌
이런 topology 차이 때문에 성질도 달라져서, atproto에선 사용자 호스팅을 바꿔도 앱 경험이 끊기지 않고, 기존 데이터를 바탕으로 새로운 앱을 누구나 만들 수 있음
ActivityPub은 그런 걸 허용하지 못하고, 결국 호스팅과 앱이 결합된 작은 중앙집중 서비스들이 서로 메시지를 주고받는 형태에 가까움
왜 Tangled는 자금 조달 전에도 ATProto 위에서 제품을 내놓을 수 있었는데, ForgeFed는 몇 년째 진척이 더딘지 그 차이도 봐야 한다고 생각함
Nostr 위에서 돌아가는 비교적 성숙한 GitHub 대안으로 https://gitworkshop.dev/도 있음
핵심 아이디어는 저장소를 여러 GRASP 호환 nostr relay에 올릴 수 있다는 점이고, 서버 하나가 내려가도 다른 곳을 통해 투명하게 동기화 가능함
그래서 신뢰할 만한 서버를 고르면 사실상 100% 가동에 가깝고, 저장소와 활동, 이슈 등도 암호학적으로 서명됨
그 사이트에서 어떤 저장소도 제대로 열 수 없었음
어떤 건 브라우저가 ssh나 https URL을 지원하지 않는다고 하고, 어떤 건 Failed to load file tree만 뜨며 무한 로딩됨
그래서 fairly mature하다는 평가는 잘 납득되지 않음
나는 federation을 강하게 지지하지만, federation of forges의 용도는 늘 잘 이해되지 않았음
forge들끼리 대체 무슨 데이터를 교환해야 하는가
Blender용 forge가 왜 Ubuntu용 forge와 연결돼야 하는가 싶음
내가 GitHub에서 얻는 가장 큰 가치는 프로젝트를 옮겨 다닐 수 있는 단일 로그인인데, 독립 forge들도 복잡한 forge federation 없이 social login만 지원하면 그 가치는 상당 부분 줄 수 있다고 봄
사람들이 소프트웨어를 찾을 때는 결국 GitHub 검색부터 함
직접 forge를 호스팅하면 Blender 같은 이미 큰 이름이 아닌 이상 아무도 소프트웨어를 못 찾음
그래서 코드가 공허 속으로 사라지지 않게 하려면 최소한 GitHub 미러링은 거의 강제됨
이걸 피하고 더 작은 forge들이 하나의 집합으로 경쟁력을 가지려면, 어느 호스트에 있든 소프트웨어를 찾게 해주는 단일 네트워크가 필요하고 ForgeFed가 바로 그걸 노림
초보 기여자에게 매번 전용 forge 로그인을 요구하는 마찰도 줄어드는데, 그건 부차적이지만 연결된 문제이기도 함
Git은 설계상 탈중앙적임
GitHub가 UI, 이슈, PR을 잘 풀어서 초보자도 화면에서 작업하게 만들었을 뿐이고, 그 과정에서 중앙집중화됐음
federation은 Git 철학에 더 가깝지만, 어느 노드가 꺼지면 upstream이 사라지거나 찾을 수조차 없는 수준의 극단적 분산까지 갈 필요는 없음 Git은 가용성을 해결하지 못하고, federation은 탈중앙 철학을 유지하면서 그 가용성을 보완할 수 있다고 봄
가장 큰 문제는 결국 discoverability임
흩어진 서버들 위의 오픈소스 프로젝트를 쉽게 찾을 방법이 필요함
GitHub 프로젝트 검색은 GitHub 안에서만 통함
상호운용 가능한 identity provider는 분명 유용함
거기에 더해 프로젝트 호스트가 사라지거나 정책을 바꾸거나 정부에 의해 차단될 때도 더 resilient해질 수 있음
여기서 이점은 데이터가 한곳, 즉 PDS에 살고 원하면 self-host할 수 있다는 데 있음
그리고 AppView가 여러 PDS의 데이터를 한 화면으로 모아 보여줌
만약 tangled.org가 enshittify되더라도 다른 어떤 AppView에서든 똑같이 이어서 쓸 수 있고, tangled.org 자체가 특권적 위치를 가지지 않음
독립 forge들의 social login도 도움은 되지만, 개인적으로는 관리할 계정이 하나인 편이 더 낫고, AT protocol 덕분에 개별 forge가 사라져도 데이터는 다른 AppView를 통해 계속 접근 가능함
Hacker News 의견들
이게 Mastodon보다 얼마나 더 나아질지 잘 모르겠음
앱과 무관한 호스팅 계층이 있고 누구나 자기 데이터를 호스팅할 수 있으며, 그 위에서 앱들이 모든 호스트의 데이터를 모아 보여줌
그래서 Mastodon식 defederation 개념 자체가 없음
더 궁금하면 https://overreacted.io/open-social/와 https://overreacted.io/a-social-filesystem/를 보면 됨
계정은 PDS에 호스팅되고 기록도 거기로 가지만, 앱에서 보이는 내용은 여러 PDS의 데이터를 모은 AppView가 제공함
그래서 어느 PDS에 있든 앱 경험은 중앙집중형 서비스처럼 느껴지고, AppView도 여러 개 둘 수 있으며 직접 호스팅도 가능함
지금처럼 사실상 전역 발견성이 생기는 비용은 좀 고민되지만, 그렇다고 이걸 그냥 또 다른 Mastodon이라고 보긴 어려움
그냥 입장을 안 정하거나, 스스로 맞다고 생각하는 쪽으로 가면 되는 것 아닌가 싶음
atprotocol 쪽에서 꽤 활발히 쓰는 편이라 편향됐을 수는 있지만, Tangled는 정말 만족스럽게 쓰고 있음
GitHub 대체제로 내가 원하던 모습에 제일 가깝고, 기능은 더 단순하지만 지난 1년 동안 개인 오픈소스 프로젝트의 주력 social/git 서비스였음
내 계정은 https://tangled.org/did:plc:rnpkyqnmsw4ipey6eotbdnnf임
Bluesky에서 알던 소셜 그래프가 이어져서 커밋, PR, 이슈 뒤에 있는 사람을 감각적으로 연결해 볼 수 있는 점이 좋고, 로그인도 다른 atproto 서비스와 같아서 편함
최근엔 정적 사이트 내장 지원도 들어가서 클라이언트 사이드 웹사이트나 간단한 index.html을 repo에서 바로 호스팅하기 좋음
Spindles가 빌드 시스템/액션 역할을 하는데, 내가 Nix 팬은 아니어도 필요한 용도엔 꽤 잘 맞았음
open API도 좋아서 atproto 기반 표준을 활용해 쉽게 정보 렌더링을 만들 수 있었고, 봇도 만들고 npmx.dev 기능도 몇 개 붙였음
직접 knot(git 서버)와 runner(Spindles)를 운영할 수도 있고 호스팅된 걸 써도 되는데, 핵심은 소셜 기능이 분리돼 있어서 git 서버가 따로 있어도 이슈나 PR 대화는 공용 소셜 레이어에서 이어진다는 점임
완벽하진 않고 네브바에 붙은 alpha 표시가 괜히 있는 건 아니지만, 오픈소스 작업용으로는 계속 쓰게 될 가능성이 큼
그게 타당한 불안인지는 아직 잘 모르겠음
댓글 분위기는 꽤 부정적이지만, 나도 VC 자금을 경계하는 편이면서도 이 영역의 경쟁은 장려해야 한다고 봄
지금 시점에 이런 걸 bootstrap으로 시작하는 건 매우 어렵거나 사실상 불가능해 보이고, 어제 HN 상단에 있던 GitHub 비판 글들과 타이밍을 잘 맞춘 것도 맞지만 그래도 이런 시도 자체는 응원하고 싶음
의미 있는 규모로 자리 잡았으면 좋겠음
제목만 봤을 땐 기대했지만 VC 자금이 들어갔다는 걸 아는 순간 바로 고려 대상에서 빠졌음
돈도 못 버는 내 애정 프로젝트를 플랫폼에 올릴 거라면, 5년쯤 뒤에 rug pull이 나올 가능성이 낮은 곳을 고르고 싶음
VC 프로젝트는 투자금 회수를 해야 하니 결국 어떤 식으로든 rug pull이 올 거라고 봄
그래서 지금은 돈을 내는 고객으로 쓰거나, 조합원처럼 회비를 내고 의사결정에 투표권이 있는 서비스 쪽을 선호함
그래서 사용자 입장에선 그 가능성을 미리 알아야 함
곧 다가올 현실이 그런데도 지나치게 이상주의를 내세우는 서비스는 별로 좋아하지 않음
차라리 서비스 요금을 받거나, 정말 이상을 추구한다면 non-profit으로 시작하거나, 최소한 수익화 계획은 분명히 밝혀야 함
어렵다는 건 당연하지만, 특히 federation을 지향한다면 같은 비용이나 더 큰 비용이 아니라 오히려 더 저렴한 인프라로도 만들 수 있어야 하는 것 아닌가 싶음
atproto 데이터 모델이 궁금하면 https://overreacted.io/a-social-filesystem/에 입문용 글을 써뒀음
좀 길긴 하지만 전체 그림을 꽤 선명하게 잡아줌
지금까지 본 ATProto 입문 글 중에 제일 좋았음
혹시 이 글들을 한곳에 모아둔 태그나 목록이 따로 있는지 궁금함
내가 보기에 필요한 건 forge federation이 아니라 더 풍부한 git repo 자체임
Fossil은 티켓, 포럼, 위키를 저장소 일부로 통합해서 거의 90%쯤 와 있고, clone하면 그것들까지 같이 내려받아 오프라인에서도 볼 수 있음
비행기 안에서도 답글을 써둘 수 있고, 권한만 맞으면 바로 혹은 나중에 연결이 복구됐을 때 동기화할 수 있음
다만 특정 아티팩트 종류를 VCS에 하드코딩하는 대신, repo 안에 앱을 담고 그 앱이 어떤 아티팩트를 허용할지, 어떤 규칙을 따를지, 누가 언제 업로드/다운로드할 수 있을지 정하게 하는 방향이 더 좋아 보임
forge는 그 정책을 실행하고 웹 사용자에게 원하는 방식으로 렌더링만 해주면 됨
이렇게 되면 다른 forge로 옮기는 일도 결국 repo를 push하는 정도로 끝남
요즘 티켓 시스템이나 에이전트 같은 걸 git repo 안의 flat files로 만들고 있었는데, 이제 그걸 repo 관리 자체까지 확장해야겠다는 생각이 듦
엄청 좋아질 듯함
내가 느끼는 federated solution의 핵심 문제는 결국 cold start임
기존 대형 서버에 들어가면 벗어나려던 바로 그 중앙집중 문제를 다시 껴안게 되지만, 대신 처음부터 큰 네트워크는 얻음
반대로 직접 서버를 열면 네트워크는 0, 발견성도 0, 피드는 비어 있고, 다른 사이트들이 연합해주거나 1인 서버라는 이유로 막지 않게 설득해야 함
나만 이렇게 느끼는 건지, 아니면 federation을 잘못 이해한 건지 모르겠음
어쩌면 이건 그냥 Mastodon 특유의 문제일 수도 있음
개별 서버들을 중앙 AppView들이 한데 모아서, 중앙집중형 네트워크처럼 일관된 단일 뷰를 주도록 설계됐기 때문임
AppView는 누구나 호스팅할 수 있음
atproto는 각 서버가 반쯤 고립된 구역처럼 동작하지 않음
분산 시스템 관점 설명은 https://atproto.com/articles/atproto-for-distsys-engineers가 잘 풀어줌
대형 서버가 moderation, 정책, 콘텐츠, 기술 문제로 수상해지면 비교적 쉽게 빠져나와 다른 꽤 큰 서버를 키우거나 옮길 수 있음
처음부터 어느 정도 평판과 규모가 있는 피난처를 만들 수 있다는 뜻임
이미 GitLab, Codeberg, freedesktop, Fedora, Debian 같은 대안 forge들이 있으니, 프로젝트의 가시성과 발견성만 유지된다면 충분히 안전한 대피처가 될 수 있음
그런데 며칠 전 이 프로젝트를 보고는 이건 진짜 될 수도 있겠다고 생각했음
대상 사용자가 self-hosting에 익숙한 층과 꽤 많이 겹치기 때문임
내 전체 네트워크가 다 올 필요는 없고, 실제로 여기 올 가능성이 높은 그 하위 집단만 있어도 충분히 유용함
프런트엔드 서버 비용은 아주 낮을 테니 거의 영구 운영도 가능해 보이고, 실제 데이터는 다른 호스트들이 공급함
Tangled가 VC 지원을 받는다는 점은 안정감보다 무조건 성장해야 한다는 압박으로 들림
매력을 잘 모르겠음
설령 federated라 해도 개발이 멈추면 버그를 고치고 유지보수할 사람이 누군가 싶음
즉, 완전히 재현 가능하고 최소 비용으로 전부 self-host 가능하게 만들려는 것임
VC 자금은 목적이 아니라 수단일 뿐이고, 유럽에 있는 인도인 창업자 둘 입장에선 보조금은 실제로 나오기까지 4~12개월 이상 걸려 거의 비현실적이었다고 함
팀을 꾸리고 인프라를 세우고 개발을 가속하는 가장 빠른 길이 VC였고, 투자자와 목표 정렬도 강하게 맞췄으며 그 파트너를 찾는 데 6개월 넘게 썼다고 함
Tangled는 구조적으로 흥미로운 선택이 많지만 코드 자체는 비교적 단순하고, 직접 들여다본 바로도 유지보수 난이도는 높지 않아 보였음
대부분은 느슨하게 연결된 Go modules이고, 거기에 정적 HTML+CSS, 그리고 약간의 TypeScript와 오케스트레이션용 Nix가 얹힌 정도임
기억이 맞다면 하드웨어 요구량도 아주 작아서 지금 규모라면 개인 한 명이 직접 호스팅할 수 있음
실제 인프라 부담의 큰 부분은 사용자들의 knots, spindles, PDS와 atproto 전체가 맡음
왜 꼭 VC가 필요한가, 왜 Ladybird처럼 기업 후원을 받지 않는가
그리고 투자자들이 10배 수익을 기대하는데, 결국 나중에 enshittification될 개발자 도구에 왜 시간을 써야 하는가
표준이 4개나 있어서 하나로 통일하자며 새 표준을 만들면 결국 표준이 5개가 되는 농담이 떠오름
농담은 그렇다 쳐도, 왜 ActivityPub으로는 부족한지 더 강한 근거가 필요하다고 봄
탈중앙 커뮤니케이션 문제를 또 다른 방식으로 다시 풀려 하기 전에 말임
이걸 맞붙이는 건 이메일이 있는데 왜 웹이 필요하냐고 묻는 것과 비슷함
ActivityPub은 이메일처럼 서버가 받은편지함 역할을 하며 서로 메시지를 주고받는 구조임
반면 atproto는 웹처럼 사용자 저장소가 데이터를 호스팅하고, 앱이 그 저장소들에서 데이터를 모아 보여줌
이런 topology 차이 때문에 성질도 달라져서, atproto에선 사용자 호스팅을 바꿔도 앱 경험이 끊기지 않고, 기존 데이터를 바탕으로 새로운 앱을 누구나 만들 수 있음
ActivityPub은 그런 걸 허용하지 못하고, 결국 호스팅과 앱이 결합된 작은 중앙집중 서비스들이 서로 메시지를 주고받는 형태에 가까움
Nostr 위에서 돌아가는 비교적 성숙한 GitHub 대안으로 https://gitworkshop.dev/도 있음
핵심 아이디어는 저장소를 여러 GRASP 호환 nostr relay에 올릴 수 있다는 점이고, 서버 하나가 내려가도 다른 곳을 통해 투명하게 동기화 가능함
그래서 신뢰할 만한 서버를 고르면 사실상 100% 가동에 가깝고, 저장소와 활동, 이슈 등도 암호학적으로 서명됨
이름부터 git의 상표 정책을 위반하는 듯함
https://git-scm.com/about/trademark
어떤 건 브라우저가 ssh나 https URL을 지원하지 않는다고 하고, 어떤 건
Failed to load file tree만 뜨며 무한 로딩됨그래서 fairly mature하다는 평가는 잘 납득되지 않음
나는 federation을 강하게 지지하지만, federation of forges의 용도는 늘 잘 이해되지 않았음
forge들끼리 대체 무슨 데이터를 교환해야 하는가
Blender용 forge가 왜 Ubuntu용 forge와 연결돼야 하는가 싶음
내가 GitHub에서 얻는 가장 큰 가치는 프로젝트를 옮겨 다닐 수 있는 단일 로그인인데, 독립 forge들도 복잡한 forge federation 없이 social login만 지원하면 그 가치는 상당 부분 줄 수 있다고 봄
직접 forge를 호스팅하면 Blender 같은 이미 큰 이름이 아닌 이상 아무도 소프트웨어를 못 찾음
그래서 코드가 공허 속으로 사라지지 않게 하려면 최소한 GitHub 미러링은 거의 강제됨
이걸 피하고 더 작은 forge들이 하나의 집합으로 경쟁력을 가지려면, 어느 호스트에 있든 소프트웨어를 찾게 해주는 단일 네트워크가 필요하고 ForgeFed가 바로 그걸 노림
초보 기여자에게 매번 전용 forge 로그인을 요구하는 마찰도 줄어드는데, 그건 부차적이지만 연결된 문제이기도 함
GitHub가 UI, 이슈, PR을 잘 풀어서 초보자도 화면에서 작업하게 만들었을 뿐이고, 그 과정에서 중앙집중화됐음
federation은 Git 철학에 더 가깝지만, 어느 노드가 꺼지면 upstream이 사라지거나 찾을 수조차 없는 수준의 극단적 분산까지 갈 필요는 없음
Git은 가용성을 해결하지 못하고, federation은 탈중앙 철학을 유지하면서 그 가용성을 보완할 수 있다고 봄
흩어진 서버들 위의 오픈소스 프로젝트를 쉽게 찾을 방법이 필요함
GitHub 프로젝트 검색은 GitHub 안에서만 통함
거기에 더해 프로젝트 호스트가 사라지거나 정책을 바꾸거나 정부에 의해 차단될 때도 더 resilient해질 수 있음
그리고 AppView가 여러 PDS의 데이터를 한 화면으로 모아 보여줌
만약 tangled.org가 enshittify되더라도 다른 어떤 AppView에서든 똑같이 이어서 쓸 수 있고, tangled.org 자체가 특권적 위치를 가지지 않음
독립 forge들의 social login도 도움은 되지만, 개인적으로는 관리할 계정이 하나인 편이 더 낫고, AT protocol 덕분에 개별 forge가 사라져도 데이터는 다른 AppView를 통해 계속 접근 가능함