at://의 위치는 어디인가

• AT 프로토콜은 분산형 소셜 네트워크의 기반이 되는 프로토콜로, 모든 데이터는 at:// URI로 식별함
• at:// URI는 데이터의 생성자(사용자) 를 authority로 지정하며, 해당 데이터가 실제로 호스팅되는 위치는 별도로 찾아야 함
• URI 해석 절차는 핸들을 정체성(DID)으로 변환, DID 문서 조회를 통한 호스팅 서버 확인, 그리고 해당 서버에서 JSON 데이터 요청의 순서로 이루어짐
• 두 종류의 DID 방식(did:web, did:plc)이 지원되며, 각각 장단점과 데이터 보존 방식에 차이가 있음
• 이 접근 방식은 데이터 소유권이 사용자에게 있음을 강조하며, 핸들과 호스팅이 변경되어도 연결이 유지되는 영속성을 보장함

---

AT 프로토콜, at:// URI, 그리고 소셜 데이터의 정체성 해석 과정

# AT 프로토콜과 at:// URI 기본 구조

• AT 프로토콜은 분산된 여러 서버들이 특정 표준에 따라 소통하게 하며, 이들 전체를 'atmosphere'라 명명함
• atmosphere 내의 각 데이터는 고유한 at:// 로 시작하는 URI가 부여되며, 이 URI는 일종의 JSON 데이터의 링크 역할을 수행함
• 전통적인 URI 구조와 달리, AT 프로토콜에서는 데이터의 생성자(사용자) 가 URI의 authority로 설정됨
  • 예를 들어, at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z">at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z 형태에서는 ruuuuu.de가 해당 데이터의 소유자임을 명시함
• 실제 데이터가 호스팅되는 물리적 서버는 URI에 직접 포함되지 않으며, 이를 찾기 위해 추가적인 해석 절차가 필요함

# at:// URI 해석 절차의 세 단계

• at:// URI를 실제 데이터(JOSN)에 매핑하기 위해서는 세 단계가 필요함
  1. 핸들(ruuuuu.de 등)을 정체성(DID: Decentralized Identifier)로 변환
     • 핸들은 사용자 식별을 위한 별칭이며 바뀔 수 있음
     • 불변의 글로벌 ID인 DID로 변환 필요
     • 변환 방식:
       • DNS TXT 레코드에서 _atproto.<핸들> 질의 → did=... 값 확인
       • 또는, https://<핸들>/.well-known/atproto-did 접속
  2. DID 문서(DID Document) 조회를 통한 데이터 호스팅 정보 확인
     • DID 문서에는 해당 정체성의 공개 키, 서비스 엔드포인트(서버) 등 정보가 포함됨
     • did:web:~의 경우, 도메인 기반 접근 (https://도메인/.well-known/did.json)
     • did:plc:~의 경우, PLC 디렉토리(https://plc.directory/DID)에서 조회
     • 서비스 엔드포인트(serviceEndpoint)가 실제 데이터 호스팅 서버임
  3. 호스팅 서버의 API를 통해 JSON 데이터 요청
     • com.atproto.repo.getRecord 엔드포인트에 at:// 각 부분을 파라미터로 전달해 데이터 요청
     • 반환된 JSON은 at:// URI와 매핑된 실제 데이터임

# 예시를 통한 해석 과정 설명

• 예시: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z">at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • 1단계: ruuuuu.de → did:web:iam.ruuuuu.de (DNS TXT record 또는 .well-known으로 확인)
  • 2단계: https://iam.ruuuuu.de/.well-known/did.json에서 DID Document 조회 → serviceEndpoint가 https://blacksky.app
  • 3단계: https://blacksky.app/xrpc/com.atproto.repo.getRecord?...로 요청 → 실제 JSON 반환

    {
      "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z"">at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z";,
      "cid": "...",
      "value": {
        "text": "posting from did:web, like a boss",
        "$type": "app.bsky.feed.post",
        ...
      }
    }
    

• handle이 바뀌어도, DID 기반 at:// URI(permalink)를 쓰면 계정과 데이터 간 연결이 유지됨

# DID 방식: did:web과 did:plc의 차이

• did:web:
  • 자신의 도메인을 관리하고 인증할 수 있음
  • 도메인 통제 권한이 사라지면 ID 전체를 잃을 가능성 있음
• did:plc:
  • PLC(Public Ledger of Credentials)가 ID 운영 주체
  • 도메인에 귀속되지 않지만, PLC 운영자가 업데이트를 거부하는 등 제한적 제어 가능성 존재
  • 모든 변경 내역은 해시로 검증 및 추적 가능

# 정체성, 호스팅, 데이터의 분리와 영속성

• at://는">at://는 정체성과 데이터 호스팅을 분리해, 사용자 데이터의 포터블화 및 영구적 링크 생성 가능
• Handle(별명)은 언제든 변경할 수 있고, 호스팅 서버도 동일하게 이사 가능
• DID(정체성)는 불변으로, 이 기반의 at:// URI는 영속적인 퍼머링크로 활용 가능
• DID Document에는 handle의 소유 증명, 서명 검증 키, 호스팅 정보가 모두 담겨있어 신뢰성과 유연성 보장

# 실제 응용과 개발 언급

• 현실적으로 대다수 AT 기반 앱은 Websocket 등으로 데이터를 push받아 내부 DB에 집계함
• 그럼에도 불구하고 at:// URI 해석법 숙지는 네트워크 특성 이해 및 데이터 이식성 확보에 필수적임
• at:// 체계는 HTTP, DNS, JSON의 위에 소셜 네트워크 추상화를 제공하며, 데이터 소유권이 사용자에 있음을 기술적으로 구현함

# 결론

• AT 프로토콜과 at:// URI는 소셜 데이터의 정체성, 연결성, 영속성을 기술적으로 한층 진화시킴
• 개발자들은 핸들 해석, DID 활용, DID 문서 구조, 실제 데이터 요청법 등 핵심 워크플로우 숙지 필요
• 이 구조 덕분에 자신의 컨텐츠와 정체성, 그리고 호스팅 위치 사이의 유연성과 소유권을 획득할 수 있음

[GN⁺]

Hacker News 의견

• 최근 ATProto 관련 글에서 영감을 받아 bsky에 가입해 봄, 그런데 보이는 건 끝없는 미국 정치 이야기 뿐임, "이런 글 덜 보이기"를 계속 눌러도 별 효과가 없음, 이런 게 이 플랫폼의 본질인지 궁금함, 해외의 이상한 논쟁에 대한 뻔한 의견만 계속 봐야 하는 게 정신적으로 별로임

  • 새로운 계정에서는 "Discover" 피드가 크게 좋지 않음, 좋아요나 팔로우 데이터 쌓이면 점점 나아지긴 하지만 여전히 최고라고 할 수 없음, 개인적으로 "For You" 피드를 추천함, 이 피드는 좋아요 반영이 빠르고 랜덤한 콘텐츠를 덜 밀어줌, "Dev Trending" 피드도 꽤 좋음 For You Feed, Dev Trending
  • 내가 한 방법은, 괜찮은 계정 몇 개 찾아서 팔로우하고 "Discovery" 탭을 아예 숨겼음, 그 이후에는 팔로워/팔로잉에서 나오는 사람들의 상호작용을 보고 자연스럽게 팔로잉 목록을 늘렸음, 또는 블로그나 웹사이트에서 계정 찾아 팔로우함, 내 생각엔 이게 진짜 소셜미디어처럼 작동하는 방식이고, 자동화된 추천 콘텐츠를 강제로 받는 건 별로임
  • 다행히 bsky에는 팔로우한 사람들의 글만 보여주는 비알고리즘 피드가 있음, 이런 식이 정신 건강을 지키는 유일한 방법이라고 생각함
  • 1년 넘게 bsky를 써봤지만 미국 정치 콘텐츠가 대부분이었음, 유럽인인 나에겐 그냥 소음처럼 느껴짐, 그래서 Mastodon으로 다시 돌아갔음, 기술계 사람 팔로우하기엔 Mastodon이 훨씬 나았음, 뉴스는 feedly의 RSS로 다 받아봄, 지금은 Bluesky가 왜 필요한지도 모르겠음, 그냥 트위터의 좌측 버전 같은 느낌임, 테크놀로지는 Nostr의 발전형으로 흥미로웠지만 그뿐임
  • 설정으로 들어가서 Contents and Media > Your Interests > News and Politics 항목을 끄는 걸 추천함, 혹시 미국 정치가 아닌 다른 국가의 뉴스와 정치 콘텐츠만 보고 싶으면 별다른 방법을 모르겠음

• 이 프로젝트가 정체성과 데이터 소유권 문제를 정말 의미 있게 해결하는지 아직 모르겠음, 정체성 측면은 자기 도메인이 있거나 남의 도메인(블루스카이 등)을 쓰는 게 전부임, 대부분 사람들은 도메인이 없으니 결국 그들의 정체성은 제3자가 가지게 됨, 데이터 역시 마찬가지임, Bluesky나 다른 서버에서 계정이 블록되면 저장소도 닫히고, 데이터를 다른 곳으로 옮길 기회조차 잃게 됨, 이건 이메일과 똑같음, 자기 도메인과 서버가 없다면 실질적으로 아무것도 조종 못함

  • AT에서는 데이터가 핸들(handle)이나 호스팅이 아니라 DID(Decentralized Identifier, 분산 정체성)에 귀속됨, 내가 쓴 글에서는 이 점을 풀어서 설명했음, 만약 "핸들" 도메인을 잃어도, 그저 핸들이 무효화되고 앱에서 사용자명 대신 "invalid handle"이라고 뜨는 느낌임, 포스트와 팔로워 등 데이터는 DID로 조회 가능하니 그대로 남음, 핸들은 그냥 별명 같은 거임, 핸들 변경도 앱의 "핸들 변경" 기능으로 할 수 있음, 호스팅도 마찬가지로 (장애물은 있지만) 저장소 백업만 해두면 다른 곳으로 옮길 수 있음, 백업 자동화도 가능하고, 이미 자동 백업해주는 써드파티 앱도 나와 있음, 공식 Bluesky 앱에서도 저장소를 내보낼 수 있음, 호스팅 업체가 협조적일 때는 PDSMover 같은 케이스가 생김, 만약 협조 안 해도 adversarial pds migration을 보면 가능함, 지금은 기술적 지식이 필요하지만 언젠가는 이 과정도 쉬워질 걸 기대함, 저장소를 새 호스트로 올리면 이전과 차이 없이 동일한 정체성으로 모든 포스트, 팔로워 등이 다 돌아옴, 이건 이메일과 아주 다름, 지금은 좀 어렵지만 AT 생태계 발전에 따라 훨씬 편하게 될 거라 기대함
  • 도메인을 가진 것도 언젠가 못 가지게 될 수 있음, 서버와는 달리 도메인은 등록기관(레지스트라)에 의존해야 해서 좀 더 취약하다고 느낌, 그래서 레지스트라를 고를 때 내 나라 법 아래에 있는 업체로 골랐음, 그래야 문제가 생겼을 때 어느 정도 복구 가능성에 더 희망을 가져봄
  • 도메인이 없는 대다수 유저는 호스팅 업체가 "적"이 되는 순간 발생하는 위험(예: 갑작스런 계정 블록)에 늘 노출됨, 완전 방어는 결국 중립 TLD로 도메인 자체를 직접 소유하고 DNS로 트래픽 라우팅을 해야만 가능함, 그래도 이런 현실(자기 도메인을 쓸 사람이 거의 없음) 아래에서, 이 프로젝트가 부분적인 유연성과 보호를 추가해 기존 Big Social(Facebook, X, Instagram 등)에서 데이터가 영원히 갇히는 것과 비교하면 발전임, Bluesky는 이런 환경에서 핸들은 그대로 두고 데이터 호스팅만 이전하는 것도 가능해 관심을 가지는 듯함, 업계는 완벽을 한 번에 이루지 못하고 현실적 문제를 조금씩 개선하면서 발전한다고 생각함
  • 정체성 증명의 최선은 프라이빗 키 소유라고 생각함, 호스팅은 BitTorrent가 제일 견고하지 않을까 싶음, 컨텐츠를 git 저장소에 두고 커밋에 싸인해서 토렌트로 배포하는 방식도 고려할 수 있음, 업데이트 알림은 NNTP나 RSS를 생각해봤음, 문제라면 검색성(discoverability)과 상호작용 부재(댓글 없음)임
  • 최소한 이메일은 PGP/SMIME 키를 가져와서 다른 곳으로 옮길 수 있음, ATproto도 비슷한 컨셉 아닌지 궁금함

• Dan의 설명은 매번 훌륭함, 최근 Bluesky가 PLC 운영권을 이전한다는 뉴스와 맞물려 시의적절함, 우리 팀도 fair.pm에서 WordPress 플러그인 분산 배포를 위해 같은 DID 시스템을 선택했음 (말하자면 App Store 같은 패키지 관리임), Bluesky 쪽(특히 Bryan)이 많이 도와줬고, 우리는 libsodium을 쓸 수 있도록 Ed25519 키 지원까지 받아냈음, 우리 프로토콜은 DID와 Bluesky의 stackable moderation 위에 설계 중이지만 atproto를 직접 쓰진 않음, 중요한 건 DID는 W3C 표준이라 PLC가 atproto에 얽매여 있지 않다는 점임

  • "우리"가 누군지, 그리고 이게 WordPress 드라마를 기술적으로 해결하려는 시도라면 좀 더 자세한 설명이 궁금함
  • PLC가 atproto에 종속되지 않는다고 했지만, PLC(did method)는 결국 bluesky나 어떤 중앙 권위에 묶인 것 아님? 이렇게 중앙화되어 있는데 왜 DID라고 부르는지 궁금함, did:plc는 포터블도 아니고, 왜 did:web처럼 작성해서 PLC같은 동작을 넣지 않았는지, 왜 method-specific-id가 public key 해시 기반 등으로 이식 가능하게 만들지 않았는지, 왜 DHT(예: did:pkarr)처럼 분산화로 안 갔는지도 궁금함, PLC는 결국 또다른 중앙집권적 시스템으로 보임

• at:// 를 찾으려면 plc.directory에 GET 요청을 보내야 하는데, 이 부분에서 시스템이 100% 중앙집중식 모델로 변하는 듯함, 최소한 여러 신뢰 디렉터리를 프로토콜과 분리해 둘 수 있었으면 했음, (DNS 루트나 CA처럼)

  • 개별적으로 하고 싶으면 did:web:fqdn도 쓸 수 있음, 이건 글에서도 설명함

• at:// 링크 저장하는 모든 서버는 결국 DNS/HTTPS를 거쳐서 정식(permalink) 표현을 찾아야 할 듯함, DNSSEC가 제대로 안 되면 이 구조 자체가 좀 취약해보임, 아직 깊이 생각해본 건 아니지만, 즉각적으로 떠오르는 걱정은 DNS 포이즈닝 같은 문제로 공격자가 내 이름으로 게시글을 올릴 수 있을 것임(공개키가 DNS에서 가져온 DID에 포함되어 있어서)

  • DNS 포이즈닝이 걱정일 수 있지만 실제로는 항상 그런 건 아님, at://에서 권한(authority) 자리에 DID를 집어넣는 게 일반적이라 핸들 대신 DID로 요청하면 결국 HTTPS와 웹 PKI 환경에 의존함, 핸들로부터 시작한다 해도 web PKI와 TXT 레코드를 거치게 됨, 추천하는 방식은 handles를 서버 쪽에서 해석하고, 만약 직접해야 한다면 신뢰 가능한 DoH(HTTPS DNS) 제공자로 쿼리하는 것임, 완벽하진 않지만 공격면을 크게 줄여줌, DNSSEC는 물론 해당 문제의 해법이지만, 실제 운영네트워크에서 DNSSEC 문제로 여러 번 곤란을 겪었음, 예를 들어 미국 상원의원들이 identity 확인용으로 senate.gov 도메인을 쓰는데 최근 DNSSEC 설정이 꼬여서 수십명의 상원의원이 Bluesky에서 "invalid handle"로 나왔던 적 있음, 이런 실망스러운 경험 탓에 지금은 DNSSEC 의무화를 강하게 밀지 않고 있음, 만약 다른 대형 프로토콜이 성공적으로 DNSSEC를 강제했다면 재고할 만함
  • 공격자가 당신으로 위장해 글을 올리려면 private key가 반드시 필요함, DNS 레코드는 단지 DID 문서를 어디서 받아올지 알려줄 뿐인데, 이 DID 문서가 DNS에서 다시 검증되어야 함, 이 프로세스에 검증 로직이 있음, DNSSEC는 DNS 레코드 변조 위험을 줄여주지만, DNSSEC 없다고 해서 임의 인물이 당신으로 위장해서 포스트하는 건 불가능함, 서버도 이를 거부함
  • 해당 부분은 좀 어렵지만, DNS TXT method에서도 "DNSSEC 불필요"라고 명시함, 어쨌든 DNS는 Handle->DID 변환만 담당하고, 검증은 DID->Handle을 거치는 쌍방향 프로세스임

• 글에서 DID 변경 기록에 사용되는 키에 대한 정보가 부족함, 예를 들어 내가 foobar.bsky.social이라면 키를 스스로 업로드한 기억이나 내려받으라는 안내가 없었음, 키가 정확히 어디에 있는지, 누가 소유하는지, 어떻게 언제 쓰이는지 궁금함, 또 DID가 plc.directory에 있다면, 그 사이트 운영자가 내 DID를 임의로 덮어써서 내 정체성을 도용하지 못하게 하는 기제가 무엇인지 궁금함

• at://라는 컨셉이 흥미로움, 하지만 실질적으로 데이터 소유 기반 시스템에서 발생할 수 있는 이슈들도 걱정임, 예를 들어 유저가 데이터를 가지고 있으니 언제든 내용을 마음대로 바꾸거나 삭제할 수 있음, 처음에는 괜찮은 글을 써놓고 나중에 악의적으로 바꿔버리면, 옛날 글 해시를 저장하고 변화 방지해도 새 서비스는 그 기록을 알 수 없게 됨, 또 좋아요(upvote) 같은 것 추적도 어렵고, 모두가 각자 객체로 저장한다면 누가 업보트 했는지 찾기도 힘듦, 가짜 계정 만들어 자기 글만 계속 올려도 제한이 없을 듯함, 마지막으로, 다양한 플랫폼에서 유입되는 막대한 수의 계정이 있으면 스팸이나 악의적 활동의 모더레이션이 불가능하지 않을까, 각 계정이 자기 데이터를 스스로 관리한다는 가정에서 투명성과 책임, 모더레이션, 스팸 차단 등 모든 요소의 시스템 설계가 성립하는지 잘 모르겠음

  • 변화관리(history)는 같이 공개하면 됨, 데이터(json)에 원하는 정보를 충분히 포함시킬 수 있으니, 기존 글 주소를 at://로 계속 연결식(링크드 리스트)으로 기술 가능함, DID는 identity moderation에 대해 잘 설명함, 즉, 누구인지 파악하고 차단하거나 판단할 근거를 충분히 제공함, 요점은 이게 블록체인이 아니라 데이터 소유자 중심으로 언제든 공유 가능한 방식이라는 점임, 누가 악의적으로 망치려 들지 않는 한 나름 매력적인 구조임, "이 사람의 어떤 데이터가 어디에 있는지"를 명확히 알 수 있으니, 이런 투명성 등에 관심없다면 안 써도 된다고 생각함
  • 원본 내용 악의적 수정 방지를 위해 strongRef라는 해시 기반 진짜 permalink가 존재함, Dan이 글에서 자세히 언급하진 않았지만, strongRef를 저장해두면 기존 게시글 내용이 바뀌어도 금방 감지할 수 있음, Bluesky가 에딧(edit) 기능을 안 도입한 이유도 악의적 수정 때문임, (참고: permalinks와 record editing 관련 permalink 실험 정리, record editing 히스토리 실험 보기), 업보트 추적은 네트워크를 크롤링해서 데이터를 모으면 roaring bitmap 등으로 대충 가능함(roaring-bitmaps 예시), 모더레이션 문제는 stackable moderation이 있는데, 기존 시스템보다 훨씬 쿨함, labeler/ feedgen을 DAG(집합연산 기반 규칙 조합 체계)로 만든다는 논의도 있음, 데이터 위조 문제는 각자의 CID 해시를 통해 변경 여부를 감지함, 변화이력(history) 추적도 기술적으로 가능함

• 다양한 크립토 프로토콜들이 탈중앙화를 말하지만 결국 한 플랫폼에 묶이는 현실과 비슷하게 느껴짐

  • 아직 초기 단계이지만 tangled.org (GitHub 유사), leaflet.pub (Medium 유사) 등도 이미 활발히 쓰임, 네트워크 인덱싱을 자동으로 해주는 도구(slices.network) 등으로 새로운 앱의 개발 장벽이 계속 낮아지고 있어서 더 많은 앱이 올 것 같음, 글에서 어떻게 작동하는지를 설명했음, 중요한 건 "일반" 이용자에게는 이런 기술이 중요하지 않다는 점임, 대다수 Bluesky 이용자들은 사실상 "탈중앙화"에 무관심하거나 심지어 반감도 있음, 하지만 탈중앙화 구조가 제품 위에 직접적으로 드러나지 않으니(웹서핑과 마찬가지로), 이런 류의 채택이 가능하다고 봄, 사용자는 그냥 "잘 동작"하는 걸 원함
  • Git, GitHub의 과거와도 비슷하게 느껴짐(기능이 늘면서 조금씩 분산화, 유연화되긴 했음)

• "at:// URI로 JSON을 어떻게 찾나"라는 구조적 질문이 있음, 설명서를 읽어도 왜 '그 JSON'이 필요한지 감이 안 옴, 개인적으로 이런 방식이 맞지 않음

  • 소개가 갑작스러운 점은 미안함, at:// 프로토콜은 앱들 사이에서 데이터를 자유롭게 임베드하고 내보내며, 사용자 아이덴티티를 공유하고, 컨텐츠 자가호스팅 혹은 이동이 가능하도록 만듦, 핸들/서버에 귀속되지 않는 영구 URI를 제공함, 기술적인 원리는 글 전체에 설명했음, 실례로 leaflet.pub와 bsky.app 두 앱이 각각 같은 공개 네트워크에서 데이터를 취합하니, 별도 API 없이 서로의 데이터를 쉽게 연동해 보여줄 수 있음 (데모 포스트)
  • 이해를 돕자면 "https:// URI로 HTML을 어떻게 찾나요?"라는 질문에 비유해볼 수 있음, 오버심플이긴 하지만 DNS, HTTP, TLS를 처음 배우는 사람에게 설명하는 데 적합함

• 프로토콜이 거대한 퍼블릭 Kafka 토픽 같은 역할인지 궁금함, 예를 들면 새 웹앱을 만들 때 데이터를 직접 저장하지 않고, 모든 사용자가 각자 데이터를 자기 공간에 저장하면 그걸 듣는 리스너를 두고, 프로토콜이 데이터 전파를 보장해서 앱에서 듣고 캐싱하면 된다는 모델 아니냐는 질문임, 개념적으로 신기하긴 한데, 업데이트 놓치지 않게 오프셋, 스케일 위해 파티션 등 Kafka의 개념이 적용되는지도 궁금함

  • 맞음, firehose가 거의 그 역할을 함, 누구든 구독하거나 직접 firehose를 돌릴 수 있음, ATProto 분산시스템 엔지니어용 설명 참고, firehose, jetstream에는 커서가 있어서 늦게 접속해도 최신 데이터까지 업데이트 수신 가능, 커버 기간은 인스턴스에 따라 1–72시간 사이임, 전체 기록이 필요하면 backfill 방식으로 처리 가능함