소셜 파일시스템

• 파일 중심 개인 컴퓨팅의 개념을 소셜 컴퓨팅으로 확장해, 사용자가 만든 모든 콘텐츠를 앱이 아닌 자신이 소유하는 구조로 설명
• AT 프로토콜을 기반으로, 앱 간 데이터 상호운용을 가능하게 하는 분산형 소셜 파일시스템 개념을 제시
• 각 사용자는 자신의 ‘everything folder’ 또는 저장소(repository) 를 가지며, 게시물·좋아요·팔로우 등이 JSON 기반 파일(record) 로 저장
• DID(Decentralized Identifier) 와 at:// URI 체계를 통해, 호스팅 변경이나 핸들 교체에도 영구적으로 식별 가능한 링크를 유지
• 이 구조는 앱이 아닌 데이터 중심의 소셜 생태계를 형성해, 누구나 새로운 앱을 만들어 기존 데이터 위에서 작동시킬 수 있게 함

파일 패러다임과 사회적 확장

• 파일은 원래 앱 내부가 아닌 사용자가 제어하는 공간에 존재하며, 앱은 파일을 읽고 쓰는 도구 역할만 수행
  • .svg 같은 개방형 파일 포맷은 여러 앱이 동일한 데이터를 공유하도록 함
  • “파일 포맷이 곧 API”라는 원칙 아래, 앱 간 상호운용이 가능
• 이 개념을 소셜 앱에 적용하면, 게시물·팔로우·좋아요 같은 행위도 파일처럼 다룰 수 있음
  • 사용자의 모든 온라인 활동을 담은 ‘everything folder’ 가 존재
  • 앱은 이 폴더의 데이터를 반영하며, 폴더가 단일 진실의 원천(source of truth) 역할 수행

AT 프로토콜과 소셜 파일시스템

• AT 프로토콜은 이러한 구조를 실제로 구현한 기술로, Bluesky, Leaflet, Tangled, Semble, Wisp 등이 이를 기반으로 작동
• 앱은 사용자 데이터를 소유하지 않고, 파일 단위의 분리된 데이터 저장을 통해 새로운 앱이 기존 데이터를 재활용 가능
• 모든 사용자의 폴더가 모여 분산형 소셜 파일시스템을 구성

레코드와 컬렉션 구조

• 각 게시물은 JSON 파일(record) 로 표현되며, 작성자 정보나 파생 데이터(좋아요 수 등)는 포함하지 않음
  • 예시: { text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
• 파일명은 타임스탬프 기반 키(record key) 로 생성되어 충돌을 방지
• 파일 구조는 lexicon이라 불리는 스키마로 정의되며, 각 앱은 자신만의 lexicon을 설계 가능
  • 예: com.twitter.post, fm.last.scrobble, io.letterboxd.review
• 동일한 개념이라도 앱마다 다른 lexicon을 가질 수 있으며, 도메인 기반 네임스페이스로 충돌을 피함

검증과 신뢰

• Lexicon Police는 존재하지 않음 — 어떤 앱도 다른 앱의 데이터를 강제할 수 없음
  • 앱은 입력된 데이터를 검증(validate on read) 하며, 유효하지 않으면 무시
• lexicon 변경 시에는 하위 호환성 유지가 필수이며, 깨지는 변경은 새 lexicon으로 분리
• lexicon은 공개적으로 배포 가능하며, DNS를 통해 도메인 소유 증명을 수행

링크와 정체성(Identity)

• 사용자가 만든 ‘좋아요’나 ‘답글’은 다른 레코드를 참조해야 하므로, 영구적 링크 체계가 필요
• 여러 시도 끝에 DID(Decentralized Identifier) 를 사용해 정체성을 확립
  • did:plc:6wpkkitfdkgthatfvspcfmjo 같은 식별자는 변경 불가
  • 각 DID는 현재 호스팅, 핸들, 공개키 정보를 담은 문서로 해석됨
• at:// URI는 DID·컬렉션·레코드 키를 조합해 호스팅 변경에도 깨지지 않는 링크 제공
  • 예: at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5

JSON 하이퍼링크와 관계 표현

• 각 ‘좋아요’, ‘리포스트’, ‘답글’은 다른 레코드를 참조하는 하이퍼링크형 JSON 구조
  • 예: parent 필드가 다른 게시물의 at:// URI를 참조
• UI의 모든 정보(작성자, 텍스트, 좋아요 수 등)는 이러한 파일 간 연결로부터 계산 가능

저장소(Repository)와 데이터 흐름

• 사용자의 ‘everything folder’는 저장소(repository) 로 불리며, DID로 식별
  • 내부에는 여러 컬렉션(collection) 과 레코드(record) 가 존재
• 저장소는 어디서나 호스팅 가능하며, 이동해도 링크가 유지
• 앱은 저장소를 파일시스템처럼 읽거나, 스트림(WebSocket) 으로 구독해 실시간 동기화 가능
  • 각 커밋은 서명된 해시 트리(Merkle tree) 로 검증되어 데이터 위조 방지
  • 중계(relay) 서버는 단순히 이벤트를 재전송하며, 검증 가능한 구조로 신뢰 확보

Atmosphere 탐험과 실제 사례

• pdsls.dev는 DID나 핸들을 입력해 소셜 파일시스템 탐색기처럼 작동
  • 각 컬렉션과 레코드를 직접 조회 가능
• 예시 앱 Sidetrail 은 사용자의 레코드 변경을 실시간 반영하며, 데이터가 앱이 아닌 저장소에 존재함을 보여줌
• teal.fm Relay 데모는 실제 API 없이도 fm.teal.alpha.feed.play 레코드를 인덱싱해 음악 재생 기록(scrobble) 을 시각화
  • lex-gql 도구를 이용해 Lexicon 기반 GraphQL 쿼리 실행 가능
• Bluesky 에서는 사용자들이 직접 만든 커스텀 피드 알고리듬을 배포 가능
  • 예: @spacecowboy17.bsky.social의 “For You” 피드는 독립적으로 작동하며, 공유 데이터 위에서 제3자가 기능을 개선할 수 있음

결론

• 소셜 파일시스템은 앱 중심이 아닌 데이터 중심의 인터넷 구조를 제시
• 사용자는 자신의 데이터 저장소를 소유하고, 앱은 그 위에서 반응적으로 작동
• “모든 것을 하는 앱”이 아니라, “모든 것이 가능한 생태계” 로의 전환을 목표로 함