atproto에는 인스턴스가 없다

 (overreacted.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • “Bluesky 인스턴스”를 찾는 질문은 Mastodon의 인스턴스 모델을 atproto에 그대로 대입한 것으로, atproto는 호스팅과 앱 집계를 분리해 설계됨
  • RSS와 Google Reader처럼 데이터는 앱 안에 갇히지 않고 호스팅된 저장소에 있으며, 여러 앱이 그 데이터를 가져와 보여주는 방식으로 동작함
  • Mastodon 인스턴스는 호스팅·앱·정체성·연합 관계가 한 상자에 묶인 구조라, 관리자 결정이나 인스턴스 장애가 사용자 경험에 직접 영향을 줌
  • atproto에서는 사용자가 호스팅을 옮기거나 새 앱을 만들고 써볼 수 있으며, Tangled, Semble, Sidetrail 같은 앱은 Bluesky와 별개로 동작함
  • atproto의 분산성을 보려면 “Bluesky 인스턴스 수”보다 대체 호스팅 이동과 새 앱 생태계가 실제로 작동하는지를 봐야 함

RSS와 Google Reader에 가까운 모델

  • RSS 시대에는 사용자가 자기 블로그에 글을 올리고, Google Reader나 Feedly 같은 앱이 여러 블로그의 글을 집계했음
  • 글은 Google Reader 안에 “사는” 것이 아니라 각자의 블로그나 호스팅 위치에 남아 있음
  • 핵심은 호스팅과 집계의 분리임
    • 호스팅은 실제 콘텐츠가 존재하는 곳임
    • 집계 앱은 여러 출처의 콘텐츠를 보여주는 투영(projection)에 가까움

중앙화된 소셜 미디어와 Mastodon의 대응

  • 전통적 소셜 미디어는 모든 사용자를 하나의 앱과 공간 안에 모으는 방식으로 운영됨
  • 이 구조에서는 중앙화와 강한 네트워크 효과가 생기며, 분산형 소셜 네트워크 논의는 이 문제를 어떻게 나눌지에서 출발함
  • Mastodon식 접근은 각 커뮤니티가 자기만의 “작은 Facebook” 또는 “작은 Twitter”를 운영하는 방식이고, 이 상자가 인스턴스임

Mastodon 인스턴스가 묶는 것들

  • 사용자는 특정 인스턴스 “안에” 속하게 됨
    • Mastodon 로그인 형식이 [email protected]인 이유도 정체성에 인스턴스가 포함되기 때문임
    • 사용자는 추상적인 “Alice”가 아니라 “instance #1의 Alice”가 됨
  • 서로 다른 인스턴스의 사용자가 소통하려면 인스턴스들이 메시지를 주고받아야 함
    • Alice가 instance #1에 있고 Bree가 instance #2에 있을 때, Alice가 Bree를 팔로우하면 Bree의 글이 instance #1로 전달됨
    • 이런 전달 관계가 연합(federation) 임
  • 호스팅과 앱이 함께 묶여 있어 사용자는 인스턴스에 강하게 의존하게 됨

인스턴스 결합이 만드는 제약

  • 인스턴스 관리자 간 갈등이 생기면 서로 연합을 중단할 수 있음
    • 이 경우 사용자는 친구의 글을 더 이상 보지 못할 수 있음
  • 사용자의 인스턴스가 내려가면 해당 인스턴스에 묶인 정체성도 사라짐
    • 팔로워가 따른 것은 “그 인스턴스의 사용자”이기 때문임
  • 인스턴스 사이의 연결 화살표는 O(n²) 로 증가함
    • 현재는 큰 문제가 아닐 수 있지만, 이 방식의 소셜 네트워크가 인기를 얻으면 중요해질 수 있음

atproto의 핵심 차이

  • atproto는 Mastodon식 인스턴스 개념을 전제로 하지 않고, RSS와 Google Reader 모델로 돌아감
  • 네트워크 수준에서 호스팅과 집계를 분리함
    • 데이터는 호스팅에 있음
    • 앱은 여러 사람의 호스팅에서 데이터를 집계함
  • 그래서 atproto에는 인스턴스가 없음
    • 호스팅은 바꿀 수 있음
    • 앱은 여러 호스팅의 데이터를 집계함
  • 이 구조는 “하나의 앱을 여러 복사본으로 운영하는 것”보다 더 풍부한 분산 구조로 읽힘

사용자가 직접 할 수 있는 분산화

  • 사용자는 호스팅을 교체할 수 있음
  • 새 앱을 시도하거나 직접 만들 수도 있음

“Bluesky 인스턴스 수”가 빗나가는 이유

  • Mastodon에서는 분산성을 인스턴스 수로 재는 방식이 자연스러움
    • Mastodon에서 할 수 있는 주된 분산 방식이 호스팅과 앱이 결합된 상자를 더 많이 운영하고 서로 말하게 하는 것이기 때문임
  • atproto에서는 모든 앱이 전체 Atmosphere의 투영에 가까움
    • Feedly와 Google Reader가 전체 Blogosphere를 보여주는 것과 같은 구조임
  • Bluesky 데이터베이스 서버 전체 복사본을 여러 개 운영하는 것은 가능하지만, Google Reader 복사본을 많이 운영하는 것만큼 일반적으로 유용하지 않음
  • 일부 복사본은 특정 필요를 위해 존재함
    • Blacksky는 다른 모더레이션 철학 같은 특정 요구를 위한 사례임
    • reddwarf.app 클라이언트는 전용 데이터베이스 없이, 커뮤니티가 운영하는 무료 캐시인 constellation을 사용함
  • Relay 같은 공유 네트워크 인프라는 1년 동안 저렴하게 운영돼 왔다고 함

atproto에서 봐야 할 기준

  • atproto의 분산성을 보려면 “Bluesky 인스턴스 수”가 아니라 다음을 봐야 함
    • 사람들이 대체 호스팅으로 이동하고 있는가
    • 사람들이 새 앱을 만들고 사용하고 있는가
  • 호스팅과 앱을 분리하면 닫힌 소셜과 연합형 소셜 모두에서 깨진 인센티브를 고칠 수 있음
  • 사용자의 데이터는 앱 밖에 두고, 앱은 그 데이터 위에서 집계하는 구조가 atproto의 핵심임

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • “Bluesky 인스턴스가 어디 있냐”는 질문을 일부러 오해해서 ATProto를 띄우고 ActivityPub을 깎아내리는 식으로 보임
    이렇게 하면 ATProto의 릴레이와 장단점, ActivityPub의 계정 이전과 장단점 같은 흥미로운 기술적 사실을 빼거나 비틀게 되고, 비슷한 문제를 푸는 두 플랫폼 사이에 불필요한 갈등을 만듦
    “인스턴스”를 서버, 실행 중인 소프트웨어, 가상 머신, 컨테이너 같은 일반적인 의미로 쓰는 사람도 있을 텐데, 왜 굳이 Mastodon식 개념으로만 받아들이는지 모르겠음
    다이어그램과 설명은 좋았지만, ActivityPub을 향한 은근한 찌르기는 정보 전달보다 적대감에서 나온 느낌이라 아쉬움

    • 글의 톤은 일부러 약간 장난스럽게 썼지만, “Bluesky 인스턴스는 어디 있냐”는 질문이 앱 인스턴스 수를 탈중앙화의 척도로 보는 아키텍처 오해에서 자주 나온다고 봄
      “Google Reader 인스턴스는 어디 있냐”와 비교하면 그 질문의 어색함이 잘 드러난다고 생각했고, 글 말미의 두 그림이 초기 atproto/ActivityPub 논의에서 자주 놓치던 부분을 꽤 잘 풀어준다고 봄
      릴레이를 넣지 않은 이유는 여기에서 썼음: https://news.ycombinator.com/item?id=48600963
      릴레이는 모델의 핵심이라기보다 성능 최적화에 가까워서, 글에서는 모델 자체에 집중하고 싶었음
    • 맥락에 따라 다르지만 ATProto, ActivityPub, Mastodon 주변 논의에서는 “인스턴스”가 보통 사용자 데이터와 프로필 URL을 호스팅하는 ActivityPub 노드를 뜻하는 경우가 많고, 글도 그 맥락을 겨냥한 것 같음
      단어에 특정 개념과 구조가 붙기 시작하니, “탈중앙 소셜미디어”를 보면 많은 사람이 ActivityPub식 연합 구조를 떠올리고, ATProto를 보며 “왜 사람들이 가입하는 Bluesky 인스턴스가 하나뿐이지?”라고 묻게 됨
      완전히 새로운 관점은 아니어도, 이런 기존 연상이 머릿속에 굳어진 사람들에게 나중에 다시 링크할 만한 유용한 글로 보임
    • ATProto 대 ActivityPub은 Fediverse의 동서 교회 대분열처럼 보일지도 모르겠음
      “filioque” 칙령 대신 “연합”의 정의를 두고 양쪽이 서로 다른 얘기를 하는 블로그 글이 오가는 셈임
    • Mastodon과 ATProto의 구분과 비교는 필요하다고 봄
      Fediverse 모델은 기존 소셜 네트워크 관점에서 이해하기 쉽지만, ATProto는 사용자에게 데이터 주권을 주면서도 중앙화 소셜 네트워크의 확장성을 얻으려는 새로운 개념임

  • 여기의 비유는 깨져 있다고 봄
    RSS는 Google Reader에 전혀 의존하지 않았고, 전성기에도 지금 이메일이 Gmail에 의존하는 것보다 덜 의존했음
    ATProto에서는 AppView가 유용해지려면 릴레이에 크게 의존하고, 릴레이 운영 비용도 꽤 큼
    또 RSS 그림의 노란 원이 블로그를 뜻하는 것과 Facebook 게시물을 뜻하는 원은 성격이 다름. 블로그는 그 자체로 독립적임
    ATProto가 나쁘다는 뜻은 아니지만, 이 글은 명확하게 하기보다 혼란을 더하는 느낌임

    • 릴레이는 이제 실제로 꽤 저렴해졌음
      예전에는 모든 트래픽을 보관해서 조금 더 비쌌지만, sync 1.1에서 그 부분이 빠졌고 지금은 월 20달러짜리 가상 머신에서도 꽤 쉽게 돌릴 수 있음
    • 릴레이가 AT Protocol 인프라 중 상대적으로 무거운 편이긴 하지만, 운영비는 지금 대략 월 30달러라 대부분 감당 가능한 수준임
      진짜 비싸고 어려운 것은 중앙화든 탈중앙화든 변하지 않는 모더레이션임
      이 글의 작성자가 9개월 전에 릴레이에 대한 흔한 오해를 다룬 적이 있음: https://news.ycombinator.com/item?id=45077291#45078223

  • 내가 보기엔 릴레이가 ATProto를 성능 좋게 작동시키는 접착제임
    콘텐츠에는 무관하게 데이터를 운반하고, 각 AppView가 알아야 하는 서비스 수를 줄이는 역할로 보임
    글에서도 말하듯 Mastodon 대비 큰 개선점은 릴레이, AppView, PDS가 서로 다른 확장 요구를 가진 별도 서비스라는 점이고, 시스템 설계 문제에 대한 꽤 아름다운 해법임
    [1] https://atproto.com/guides/glossary

    • 맞음, 릴레이는 그걸 하는 한 방법임
      다만 보이지 않는 최적화이고 다른 전략도 있어서 글에서는 대부분 생략했음
      예를 들어 오늘날 많은 작은 앱은 자체 데이터베이스 색인을 만들지 않고 Constellation(https://constellation.microcosm.blue/)에 의존하므로 릴레이를 전혀 쓰지 않음
    • 릴레이에서 콘텐츠를 직접 제거하기도 함
      호스팅하면 불법인 콘텐츠만 제거한다고 주장하지만, 그게 얼마나 사실인지는 모르겠고 앞으로 바뀔 위험도 항상 있음
      https://docs.bsky.app/blog/blueskys-moderation-architecture#...

  • 두 방식의 차이를 설명한 점은 좋았음
    다만 “인스턴스가 해결하는 문제를 ATProto는 어떻게 해결하느냐”는 질문에는 답하지 않아서 답답했음
    예를 들어 글이 디페더레이션을 친구 글이 안 보일 수 있는 알 수 없는 이유 정도로 치부하면, “그럼 atproto는 디페더레이션이 해결하는 문제를 어떻게 해결하느냐”에 답하지 못함
    이 프레이밍에서 자연스럽게 나오는 기본 답은 “해결하지 않는다”임

    • 모더레이션을 묻는 거라면, 모든 것이 RSS인 세계에서 기대할 법한 방식과 비슷하게 작동함
      호스팅 수준에서는 blogspot.com이나 Cloudflare가 특정 사안에서 차단하듯, 명백히 불법인 것 때문에 호스팅 업체가 계정을 막을 수 있음
      애플리케이션 수준에서는 앱 관리자와 모더레이터가 사용자 생성 콘텐츠를 다루는 다른 웹서비스처럼 조정함
      앱 개발자가 선택할 문제이고, Reddit처럼 사용자 영역 모더레이션 기본 요소를 제공하거나 Bluesky처럼 별도의 모더레이션 서비스를 꽂을 수도 있음
      서로 싸울 수 있는 “커뮤니티 인스턴스”에 해당하는 것이 없기 때문에 디페더레이션도 없음. 호스팅, 앱, 앱 개발자의 선택에 따른 앱 수준 모더레이션이 있을 뿐임
    • 더 나은 질문은 “ActivityPub은 디페더레이션이 만드는 문제를 어떻게 해결하느냐”라고 봄
      이는 Microsoft가 이메일에서 하는 일과 본질적으로 비슷함. 가장 큰 제공자들 말고는 메시지를 버리고, 기본적으로 디페더레이션해서 사용자가 메시지를 전달하려면 Microsoft나 다른 대형 기존 사업자를 쓰게 만듦
      그러면 새 인스턴스는 메시지를 전달하지 못하고 사용자를 얻지 못함. 대형 기존 사업자에게 새 인스턴스와 연합하지 않을 왜곡된 유인이 생김
      이런 아키텍처 선택은 장기적으로 과점을 굳히는 효과가 있음
      스팸 방지에 필요하다고 하지만, DKIM과 역방향 DNS 등을 제대로 설정하면 Gmail에는 보통 전달 가능한 것처럼 그렇게 하지 않는 제공자도 있고, 그들이 스팸 문제를 더 많이 겪는 것도 아님
      명백한 대안은 클라이언트에서 필터링하는 것임. Microsoft 같은 운영자가 아니라 uBlock 같은 성격의 필터 목록 제공자가 필터를 공급하면, 특정 인스턴스를 운영하지 않기 때문에 모두를 자기 인스턴스로 몰아갈 유인이 없음
    • 그런 문제를 해결하지 못함
      전체 firehose를 소비할 수 있는 AppView가 아주 많고, 그 사이를 자유롭게 고를 수 있으며, 직접 저렴하게 운영할 수 있는 대체 우주라면 모를까
      ATProto는 데스크톱이나 모바일 RSS 리더 없이 Google Reader 또는 같은 규모의 복제 서비스로만 RSS를 읽을 수 있는 세계의 RSS에 가까움

  • 오리처럼 꽥꽥거리면 오리임
    계정에는 단일 PDS가 있고, DID는 사용자의 정식 데이터 피드이자 쓰기 대상인 PDS를 가리킴
    데이터는 복제될 수 있지만 PDS가 정본으로 취급됨
    이는 분산 아키텍처보다 클라이언트/서버 아키텍처에 훨씬 가까움
    P2P 데이터베이스도 없고, DHT나 피어에 쓰는 것도 아님. PDS에 쓰고, 그 쓰기가 선택적으로 미러링됨
    발견도 DNS로 이뤄지니 피어에게 데이터를 묻지도 않음
    릴레이에는 피어가 아니라, PDS에 정본으로 호스팅된 데이터 사본을 요청하는 클라이언트로 연결함
    PDS를 인스턴스, 릴레이를 미러라고 부르는 것이 무리라고 생각하지 않음

    • 그렇게 표현해도 괜찮음
      다만 Mastodon을 말하는 사람들이 “인스턴스”라고 할 때 보통 뜻하는 것과는 다름
      Mastodon에서 인스턴스는 데이터 호스팅, 앱, 커뮤니티, 모더레이션이 결합된 분리 불가능한 묶음임

  • ATproto는 일관성을 위해 진짜 탈중앙화를 희생하고, Mastodon과 ActivityPub은 더 접근 가능한 탈중앙화를 위해 진짜 일관성을 희생한다고 이해함
    ActivityPub 노드를 운영하는 편이 일반 자가 호스팅 사용자에게 AT의 콘텐츠 릴레이 운영보다 훨씬 접근 가능하기 때문임
    AT에서 “탈중앙화”할 수 있는 것은 결국 자기 데이터뿐이고, 네트워크의 일부를 공동으로 소유한다기보다 자기 데이터 소유에 더 가까움
    HN에서 이미 여러 번 반복된 얘기이기도 함

    • 흥미로운 관점이지만, 내 현재 이해로는 AtProto가 더 접근 가능하고 더 탈중앙화된 것처럼 느껴짐
      ActivityPub에서는 인스턴스 운영이 데이터, 애플리케이션, 이후의 확장 문제까지 모두 맡는 것이어서, 운영 책임을 직접 지거나 남의 인스턴스에 묶이는 것 중 하나를 골라야 함
      고른 인스턴스가 마음에 들지 않아 옮기려 해도, 아직 바뀌지 않았다면 거의 새로 시작해야 하는 상태임
      AtProto에서는 같은 정체성을 유지한 채 다른 애플리케이션 플랫폼으로 옮기기가 쉽고, 플랫폼에서 데이터를 내보내 자가 호스팅하는 것도 사용자 경험은 어렵지만 최소한 가능함
      예를 들어 최근 Tangled를 처음 써봤는데 기존 bsky 기반 도메인(h14h.com)으로 로그인할 수 있었음. 새 계정이나 새 사용자명을 만들 필요 없이 이미 거기 있던 것 같았음
      VPS에서 git 저장소를 자가 호스팅하는 설정도 길어야 오후 한나절 일이었고, 거의 신경 쓸 필요 없는 백엔드 서비스로 돌아감
      최악의 경우 tangled.org에 “저장소가 오래되어 최신 Tangled와 호환되지 않을 수 있다” 같은 배너가 뜨고, 최신 버전으로 Docker 이미지를 다시 빌드해 배포하면 해결됨
      아키텍처로는 AtProto가 확실히 머리에 넣기 더 어렵지만, 실제 사용자와 접하게 만드는 것은 훨씬 단순하다고 봄
    • “진짜” 탈중앙화라는 게 있는지 잘 모르겠음
      내 머릿속에서는 하나의 슬라이더라기보다 트레이드오프의 뷔페에 가까움
      참고로 AP 세계에서도 개인과 작은 팀들이 릴레이, 미러, 캐시, AppView 등을 운영하고 있음. 다만 규모가 커질수록 더 비싸질 수 있다는 점은 맞음
    • 그 말도 일부지만 전체를 다 설명하진 못함
      AT는 일관성뿐 아니라 앱 전반의 공유 데이터 모델도 제공함
      그래서 앱들이 다른 앱의 콘텐츠를 참조하고 렌더링할 수 있음. 타입 있는 JSON의 웹 같은 형태이고, 서로 다른 앱은 같은 네트워크를 보는 렌즈임
      누구나 기존 데이터 위에 새로운 경험을 만들 수 있고, AP에는 이에 해당하는 것이 거의 없음
      AP는 데이터를 앱에 결합하지만, AT에서는 전 세계 데이터가 들어 있는 하나의 전역 데이터베이스를 모든 앱이 질의하는 것에 더 가까움
      왜 논의가 항상 릴레이에서 막히는지 모르겠음. 요즘은 원하면 릴레이를 대략 월 30달러로 돌릴 수 있고, Bluesky나 커뮤니티 릴레이를 무료로 쓸 수도 있음
      많은 앱은 릴레이를 전혀 쓰지 않고 Constellation(https://constellation.microcosm.blue/) 같은 커뮤니티 색인에 의존함. 자체 서버나 데이터베이스조차 안 돌리는 앱도 있음
    • Mastodon에도 콘텐츠 릴레이가 있음
      하지만 오히려 반대로, ATproto가 더 탈중앙화되어 있거나 적어도 그렇게 되려 한다고 주장하고 싶음
      ActivityPub 세계에서는 정체성, 애플리케이션, 호스팅이 본질적으로 연결돼 있음
      Lemmy를 쓰려면 그 Lemmy 인스턴스에 두 번째 영구 분리 ActivityPub 계정을 만들거나, 내 Mastodon 인스턴스가 Lemmy가 이해하는 메시지를 보낼 줄 아는 범위에서만 Lemmy를 써야 함
      모든 새 ActivityPub 앱은 새 상호운용성 문제를 만든다. 각 앱이 자기 정체성과 호스팅을 소유하기 때문임
      내가 자가 호스팅한 Mastodon 인스턴스가 Lemmy 서버에 정체성을 제공하고, 그 Lemmy 서버가 내 인스턴스에 내 대신 콘텐츠를 호스팅하라고 시킬 방법이 없음
      ATProto가 말하는 수준에 맞추려면 최소한 그 정도는 필요함. 다만 실제 존재하는 ATProto에 얼마나 해당하는지는 모르겠고, 실제 존재하는 ActivityPub도 지지자들이 말하는 만큼 상호운용되지는 않음

  • 이 블로그는 아키텍처를 잘 설명함
    하지만 실제로는 Bluesky 회사가 주 앱을 운영하고 사용자 데이터 대부분을 호스팅한다는 것이 “문제”라고 생각했음
    프로토콜 수준에서는 탈중앙화되어 있지만, 실제 시스템은 통제 주체 관점에서 여전히 매우 중앙화되어 있음
    꼭 Bluesky의 잘못이라는 뜻은 아니지만, 지금까지는 그렇게 흘러온 것 아닌가 싶음

    • “문제”는 사람들이 문제를 찾고 있다는 데 있음
      이 문제는 Bluesky나 ATProto에 특유한 게 아니고, 영리 조직이든 비영리든 자원봉사자 그룹이든 누군가는 항상 문제 삼을 대상을 찾아냄
      투자자도 아니고 초기 사용자였다는 것 외에 Bluesky와 이해상충도 없음. 내 한계 안에서 프로토콜, 회사, 웹사이트도 이해하고 있음
      사이트와 앱은 잘 작동함. 사람들은 더 크고 나은 해법을 만들기보다 문제 찾기에 너무 집중함
      대다수는 Lemmy나 Mastodon 같은 임시적인 P2P 해법을 원하지 않음. 콘텐츠가 한곳에 있기를 원하고, 그 주체에게 책임을 물을 수 있기를 원함
      그래서 P2P 소셜 네트워크는 결코 대중화되지 않을 거라고 봄. Lemmy와 Mastodon 주변의 드라마가 Twitter, Reddit, Facebook 등을 합친 것보다 더 많았음
      내 2센트이고, 배우자와 친구들도 같은 생각인 듯함
    • 다른 앱, 다른 사용자 데이터 호스팅, 개인 호스팅, 다른 백엔드 서비스가 있음
      이론과 실제 모두에서 탈중앙화되어 있음
      다만 Bluesky가 가장 큰 부분을 운영하므로 커뮤니티나 마인드셰어 수준에서는 탈중앙화되지 않았다고 말할 수는 있지만, 그 점도 바뀌고 있음
    • 정말 잘 설명한 걸까?
      “인스턴스가 없다”고 말할 뿐, 그 아키텍처가 인증, 동기화, 발견 같은 문제를 어떻게 우회하는지는 설명하지 않음

  • Google Reader를 비유로 고른 건 불길하게 느껴짐
    RSS는 Google Reader 종료 후에도 살아남았지만, RSS를 쓰던 모든 커뮤니티가 살아남은 건 아니고, 그중 다수는 지금도 RSS가 뭔지 모름
    탈중앙화된 것이라고 주장하면서, 탈중앙 생태계의 거대한 사회적 중앙화를 좋은 사례처럼 계속 가리키는 건 거의 프로이트식처럼 느껴짐
    특히 우리는 그 결말을 이미 알고 있음
    Google Reader는 많은 RSS 집을 하나로 묶고, 소셜 그래프와 댓글 같은 가치를 더했지만, Google 임원들의 변덕으로 무너지며 RSS를 거의 죽이고 인상적인 소셜 그래프를 파괴했음
    그런 비유라면 ATProto에 큰 신뢰가 생기지 않음

    • atproto의 핵심은 소셜 그래프도 “블로그/RSS” 쪽에 산다는 것임
      앱은 그걸 색인할 뿐임
      그래서 이 비유에서는 누구든 같은 그래프를 사용해 Google Reader를 되살리거나 경쟁할 수 있음
      궁금하다면 지금 http://leaflet.pub가 실제로 그런 식으로 작동함
    • 불길하지만 정확함
      데스크톱이나 모바일 RSS 리더를 못 쓰고, Google Reader나 비슷한 규모의 복제 서비스로만 RSS를 읽을 수 있다고 상상하면 됨
    • 그 대신 지금은 훌륭한 RSS 리더가 많음
      최근에도 누군가 NetNewsWire를 이야기했음

  • 중요한 차이는 블로그에는 자기 웹사이트가 있고, RSS 피드에 전체 글을 반드시 실을 필요가 없다는 것임
    Bluesky는 보통 그렇게 작동하지 않음. PDS에 있는 모든 것이 복제됨
    또 쉬운 복제를 위해 전체 블로그 글을 PDS에 넣도록 장려하고 있음
    그러면 색인하려는 누구나 사본을 가져가고, 그들이 뭘 하든 통제할 수 없음
    꼭 그렇게 해야 하는 건 아님. 자기 웹사이트에 블로그를 올리고 Bluesky에는 링크만 올릴 수도 있음

    • 그게 블로그를 직접 긁어가는 스크래퍼와 어떻게 다른가?
    • 솔직히 그건 atproto가 원시 데이터 프로토콜이기 때문이기도 함
      atproto 계정 위에 HTTP 프런트엔드를 얹는 건 권장하는 방식이고, 실제로 많이들 그렇게 함
      나도 pfrazee.com에서 그렇게 하고 있고, 정본은 atproto에 있는 내 leaflet 블로그 글도 내 블로그에서 렌더링됨

  • RSS 비교는 오해를 부름
    Atproto 앱은 사용자 컴퓨터에서 실행되며 콘텐츠 출처에 직접 연결하는 RSS 리더와 다름
    Atproto 앱은 독자에게 제공할 콘텐츠를 통제하고, 필터링하고, 형태를 만드는 서버임
    Atproto 앱은 검열, 섀도밴, 광고 노출, 알고리즘 피드화를 원하는 대로 할 수 있음
    사용자는 무력하고, 창작자는 울부짖는 것 말고 할 수 없는 피해자가 됨
    누구나 데이터를 어디에든 호스팅할 수 있다는 사실은, 그 데이터를 배포할 방법이 없다면 완전히 무의미함

    • 그건 사실이 아님
      우선 그런 일을 하지 않는 다른 AppView를 쓸 수 있음
      피드는 사용자가 원하는 방식으로 알고리즘화될 수 있고, 여러 앱이 있으면 한 중앙 제작자가 원하는 알고리즘에 묶이지 않음
답변달기