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

1 month ago 8

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

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

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