블루스카이 작동 원리

 (steveklabnik.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • BlueSky는 Twitter·Mastodon과 비슷한 마이크로블로깅 앱이지만, 더 큰 목적은 AT Protocol(atproto) 위에서 대규모 분산 소셜 애플리케이션이 가능한지 검증하는 데 있음
  • atproto는 블록체인·DAO·NFT가 아니라, 암호화와 Merkle tree 등을 활용해 사용자가 서명한 기록을 PDS, Relay, App View가 나눠 처리하는 연합형 프로토콜임
  • 확장성은 사용자의 Personal Data Server(PDS) 가 모든 팔로워에게 직접 게시물을 보내지 않고, Relay가 네트워크 데이터를 모아 firehose로 제공하는 구조에서 나옴
  • 조정은 “speech vs reach” 모델로 나뉘며, 콘텐츠 복제와 노출 제어를 분리해 labeler, feed generator, App View가 필터링과 차단을 적용함
  • 안정적인 DID 와 도메인 기반 handle은 계정 이동성을 제공하지만, BlueSky가 운영하는 did:plc 해석 서비스는 중앙화 논점으로 남아 있음

BlueSky와 atproto의 관계

  • BlueSky는 현재 마이크로블로깅 애플리케이션으로 동작하지만, 전체 구상에서는 Authenticated Transfer Protocol, 즉 atproto의 가능성을 입증하는 초기 애플리케이션임
  • BlueSky 웹사이트는 “소셜 미디어는 몇몇 기업이 통제하기에는 너무 중요하며, 모두가 미래를 만들 수 있는 소셜 인터넷의 열린 기반을 만들고 있다”고 밝힘
  • BlueSky가 회사이기 때문에 “기업이 통제해서는 안 되는 것을 기업이 만든다”는 회의적 시각이 있을 수 있으나, 설계의 핵심은 앱보다 atproto에 있음
  • atproto는 대규모 분산 소셜 애플리케이션을 위한 연합형 프로토콜임

암호화폐가 아닌 분산 프로토콜

  • atproto는 “분산 네트워크”와 “프로토콜”이라는 표현 때문에 암호화폐처럼 보일 수 있지만, 암호화폐가 아님
  • 블록체인, DAO, NFT가 아니며 일부 암호화와 Merkle tree 같은 기술만 사용함

atproto의 기본 구조

  • atproto는 여러 주체가 시스템의 다른 부분을 운영하고 서로 통신하는 연합형 구조를 택함
  • 대규모 사용자 기반을 염두에 두고, 부하를 감당할 수 있는 주체에게 더 많은 역할을 맡기고 그렇지 않은 주체의 부담은 줄이는 방향으로 설계됨
  • BlueSky는 글 작성 시점 기준 그 주에 500만 사용자를 넘었고, 초기 Twitter보다 훨씬 안정적이라고 평가됨
  • 현재 atproto는 100% 공개 기반이며, 비공개 메시지 같은 기능은 없음
    • 연합 시스템에서 비공개 기능을 제대로 구현하기 어렵기 때문에, 심각한 단서가 있는 기능을 내기보다 제대로 구현하려는 선택임
    • 지금은 공개되어도 되는 내용에만 쓰는 것이 적합함

기록, 저장소, App View, Relay

  • 사용자는 암호학적으로 서명된 record를 만들고, 이 서명으로 작성자를 증명함
  • record는 Lexicon이라는 스키마를 따름
  • record는 repository에 저장되며, 이 저장소는 HTTP와 WebSocket을 노출하는 서비스로 동작함
    • 이런 서비스는 보통 PDS(Personal Data Server) 라고 불림
    • 사용자는 직접 PDS를 운영하거나, 다른 사람이 호스팅하는 PDS를 사용할 수 있음
  • 애플리케이션은 네트워크에 저장된 record를 읽고 그 위에서 기능을 만듦
    • 이런 서비스는 특정 정보 관점을 노출하므로 App View라고 불림
    • 애플리케이션을 만든다는 것은 Lexicon을 정의하고, 그 Lexicon을 쓰는 record를 읽으며, 나머지는 무시하는 방식임
  • PDS끼리 직접 알림을 주고받는 방식은 확장성 문제가 큼
    • 새 게시물을 올릴 때마다 모든 팔로워의 repository에 직접 보내야 한다면 비효율적이고, 인기 있는 repository 운영 비용이 커짐
  • Relay는 이 문제를 줄이기 위해 네트워크 정보를 모아 firehose로 노출함
    • 실제 App View는 repository를 직접 보기보다 Relay를 봄
    • 게시자가 글을 올리면 repository가 Relay에 알리고, 팔로워는 App View가 Relay 출력을 필터링한 결과를 봄
    • Relay는 크고 운영 비용이 클 수 있지만, 특정 사용자 하위 집합만 전파하는 더 작은 Relay도 상상할 수 있음

“speech vs reach” 조정 모델

  • atproto는 소셜 애플리케이션을 위한 프로토콜이므로 사람을 연결하는 방식뿐 아니라 연결을 끊는 방식도 고려함
  • BlueSky의 조정 모델은 speech vs reach로 나뉨
    • speech 계층은 콘텐츠를 의미 내용과 무관하게 네트워크에 복제하는 역할임
    • reach 계층은 사용자가 보고 싶지 않은 것의 도달 범위를 제한하는 도구를 제공함
  • BlueSky가 “조정을 하지 않는다”거나 “자유 발언만 중시한다”는 말은 부정확함
    • 조정 도구는 프로토콜 자체에 들어가 있으며, BlueSky가 아닌 애플리케이션의 콘텐츠에도 작동할 수 있음
    • 사용자는 다른 사람의 조정 선택이나 조정 부재에 종속되지 않고, 자신의 조정자를 선택할 수 있음

Feed generator

  • atproto에서는 피드가 별도 서비스인 feed generator로 분리됨
  • feed generator는 Relay가 만든 firehose를 받아 원하는 기준으로 콘텐츠를 필터링하고 정렬해 목록을 보여줌
  • 사용자는 자신이 만든 피드를 다른 사용자와 공유할 수 있음
  • 예시 피드:
    • Quiet Posters: 자주 글을 쓰지 않는 사람들의 게시물을 보여줌
    • the ‘Gram: 사진이 첨부된 게시물만 보여줌
    • My Bangers: 자신의 인기 게시물을 보여줌
  • BlueSky의 강점 중 하나는 사용자가 자신만의 알고리듬 피드를 만들고 쉽게 공유할 수 있다는 점임
  • feed는 atproto에 비교적 최근 추가된 기능이라 아직 완전하지 않을 수 있고, 앞으로 변경될 수 있음

Labeler와 네트워크 수준 조정

  • Labeler는 콘텐츠나 계정에 label을 붙이는 서비스임
  • 사용자는 특정 labeler를 구독하고, 게시물의 label에 따라 경험이 달라지게 만들 수 있음
  • labeler는 운영자가 원하는 방식으로 동작할 수 있음
    • 게시물에 자동 알고리듬을 돌릴 수 있음
    • 사람이 직접 승인·거부할 수 있음
    • 블록리스트나 NSFW 필터로 사용할 수 있음
  • label 기능은 존재하지만, 글 작성 시점에서 사용자가 직접 labeler를 실행할 수 있는지는 불확실함
    • BlueSky는 자체 labeler를 운영함
    • 외부 릴리스는 아직 알려진 것이 없음
  • feed, App View, labeler를 조합하면 사용자는 애플리케이션 안팎에서 조정 경험을 선택할 수 있음
    • 한 피드에서는 SFW만 보고, 다른 곳에서는 NSFW 콘텐츠를 허용할 수 있음
    • 블록리스트를 만들어 공유할 수 있음
  • 조정 도구가 애플리케이션이 아니라 프로토콜 수준에서 동작하므로, atproto 위의 다른 애플리케이션에도 같은 labeler를 쓸 수 있음
    • atproto 위에 Instagram 클론이 만들어져도 동일한 블록리스트 labeler를 쓸 수 있음
    • 한 곳에서 차단한 사용자를 원하는 경우 모든 곳에서 차단할 수 있음

Mastodon식 인스턴스 모델과의 차이

  • atproto 모델은 Mastodon처럼 특정 “인스턴스”에 “계정”이 있는 방식과 다름
  • “내 인스턴스가 defederate되면 어떻게 되는가” 같은 질문은 그대로 적용되기 어려움
  • 특정 PDS에서 온 게시물을 싫어해 무시하는 식으로 비슷한 목표를 달성할 수는 있음
  • 다만 그 선택은 서버 소유자가 사용자의 계정을 대신해 결정하는 것이 아니라 사용자 자신의 선택임

DID, handle, 계정 이동성

  • atproto의 신원 핵심은 DID(Decentralized Identifier) 임
    • 예시 DID는 did:plc:3danwc67lo7obz2fmdg6jxcr 형태임
  • 사용자가 실제로 보는 신원에는 handle이 함께 쓰이며, handle은 도메인 이름임
    • 예: @steveklabnik.com
    • BlueSky 가입자는 @username.bsky.social 형태의 handle을 받을 수 있음
  • DID가 안정적이기 때문에 handle을 @steveklabnik.bsky.social에서 @steveklabnik.com으로 바꿔도 팔로워에게 중단이 생기지 않고 UI에서 handle만 바뀜
  • 도메인을 handle로 쓰려면 PDS가 생성한 DID를 가져와 해당 도메인의 DNS에 TXT record를 추가함
  • DNS를 모르는 사용자도 BlueSky와 NameCheap의 제휴를 통해 기술 지식 없이 도메인을 등록하고 handle로 설정할 수 있음
  • 계정 이동성은 DID와 암호학적 서명에 기반함
    • 특정 DID를 쓰는 사람이 만든 콘텐츠는 서명되고 네트워크에 복제됨
    • “계정”을 종료하려면 사용자가 가진 키 사용을 강제로 막아야 하는데, 네트워크 설계상 다른 주체가 그 키에 접근하지 않음
    • PDS가 내려가도 네트워크에서 내용을 backfill하고 새 PDS로 이동했음을 알릴 수 있음

did:web과 did:plc의 논점

  • BlueSky는 두 가지 DID 방식을 지원함
    • did:web: 도메인 이름 기반 방식
    • did:plc: BlueSky가 구현한 자체 방식
  • did:plc의 plc는 “placeholder”를 뜻하며, BlueSky는 이를 계속 지원할 계획임
  • did:plc는 BlueSky가 운영하는 서비스를 통해 올바른 정보를 해석해야 한다는 약점이 있음
    • 예시 조회는 plc.directory에서 가능함
    • 이 구조 때문에 BlueSky가 네트워크 설계상 원래 가능한 것보다 더 강하게 사용자를 ban할 수 있다는 비판이 있음
  • 이 문제가 치명적이라고 보지 않는 이유도 있음
    • 원하지 않으면 did:web을 쓸 수 있음
    • 더 나은 시스템이 생기면 이동할 수 있도록 설계됨
    • 향후 did:plc 거버넌스를 합의 모델로 옮길 가능성이 있음
    • 다른 주체가 did:plc 서비스를 운영하고 그것을 사용할 수도 있음

BlueSky가 atproto 위에 올라가는 방식

  • BlueSky는 atproto 네트워크 위에 만든 애플리케이션임
  • BlueSky는 App View와 이를 사용하는 웹 애플리케이션을 운영함
  • 웹앱으로 가입한 사용자를 위한 PDS도 운영하고, 그 PDS들이 통신하는 Relay도 운영함
  • BlueSky는 두 종류의 Lexicon을 발행함
    • com.atproto.*: 네트워크의 어떤 애플리케이션에도 필요한 저수준 작업
    • app.bsky.*: BlueSky에 특화된 작업
  • BlueSky의 제품 목표는 사용자가 이런 기술 세부사항을 몰라도 쓸 수 있게 하는 것임
    • 인스턴스가 없기 때문에 계정 생성을 위해 인스턴스를 고르는 흐름이 없음
    • 호스트가 내려가도 이동할 수 있고, 팔로워는 이를 의식하지 않아도 됨

atproto 위에서 새 애플리케이션 만들기

  • atproto 애플리케이션은 Lexicon을 만드는 것에서 시작함
  • 이후 네트워크의 데이터 중 해당 Lexicon과 관련된 데이터를 처리하는 App View를 운영함
  • 애플리케이션은 사용자가 자신의 PDS에 해당 Lexicon을 사용해 데이터를 쓸 수 있게 해야 함

설계상의 핵심 분리

  • atproto와 BlueSky의 역할 분리는 중요한 설계 요소임
  • BlueSky 같은 “killer app”은 네트워크를 사용할 이유를 제공함
  • BlueSky 자체도 atproto 위에 실제 애플리케이션을 만들 수 있는지 검증하는 dogfooding 역할을 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 굉장히 잘 설계된 것 같고, ActivityPub의 큰 문제들을 일부 해결하는 듯함
    예전엔 Bluesky에 관심이 없었는데, 이제는 계정을 만들어볼 생각이 듦

    • Bluesky와 AT Protocol의 주된 문제는 기술적 장점보다도 강한 NIH(Not invented here) 태도에 있음
      모두가 쓰는 user@host와 WebFinger 같은 기존 프로토콜 대신 “도메인을 신원으로 쓰기”를 택했고, 인증서에서 ACME가 이미 처리하는 방식을 참고하지 않아 누군가 s3.amazon.com 도메인을 Bluesky에서 가져가는 일도 생김 https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
      또 새 원격 호출 프로토콜인 XRPC를 만들고, protobuf나 jsonld보다 새롭다는 것 말고 장점이 불분명한 코드 생성 기반 데이터 스키마 Lexicon도 씀
      계속해서 다른 생태계를 존중하거나 대화하려 하지 않는 모습을 보이는 “열린 네트워크”를 신뢰하기 어렵고, 공통 지식을 거부하다가 설계에 흔한 실수가 얼마나 더 들어갔을지도 의심됨
    • AT Protocol은 기술적으로 더 나아 보이지만, 사회적으로는 실패하기 쉬운 구조로 보임
      실제 커뮤니티와 분리된 릴레이와 중재 서비스를 누군가 설치·유지할 사회적 유인이 없어서, 남는 건 유료 서비스, 광고 삽입, 데이터 채굴, 정보 조작 같은 금전적 유인뿐임
      데이터 배포와 중재가 중앙화되면 호스팅 비용과 인적 비용 모두 큰 사업이 되고, Bluesky가 아닌 누군가가 자체 릴레이나 중재 서비스를 운영하기를 사실상 막는 방향으로 감
      ActivityPub의 단점에도 불구하고 “게이트가 있는 커뮤니티” 같은 접근은 사용자가 서버에 소속감을 느끼고, 운영자와 중재자가 사용자에게 서비스를 제공한다는 자부심을 갖게 해줌
      AT Protocol은 여러 릴레이와 중재 서비스를 기술적으로 허용하지만, 현실에서 얼마나 생겨날지는 의문임
      소셜 네트워크 프로토콜을 순수하게 기술적·적대적 관점에서만 판단하는 건 실수라고 봄. 서버에 종속되지 않는 대신 촘촘한 커뮤니티와도 분리되고, 더 이상 걸린 것이 없어짐
      데이터, 신원, 커뮤니티 측면에서 잃을 것이 없다는 건 양날의 검임

  • 현재는 릴레이가 하나뿐인 것으로 알고 있음
    여러 릴레이가 생기면 각각 네트워크를 다르게 보게 되고, 더 많은 게시물을 포함하는 릴레이가 더 나은 릴레이가 될 것임
    단일 지배적 릴레이 대신 릴레이 다양성을 확보하기는 꽤 어려울 수 있고, 대체 DNS 시스템이 traction을 얻으려는 것과 비슷해 보임. 그러면 내 게시물이 지배적 릴레이에 잡히지 않으면 방법이 없어 보임
    아직 아주 초기라 그렇게 되지 않을 수도 있고, 지배적 릴레이가 있더라도 GitHub도 그렇게 나쁘진 않으며 대안도 있긴 함

    • 예전엔 Bluesky가 꽤 헷갈렸는데, 최근엔 주로 용어 때문에 헷갈렸다는 걸 깨달음
      시스템을 [마이크로블로그] -> [인덱서] -> [클라이언트]라고 부르면 더 이해하기 쉬움
      실제로는 더 많은 요소가 있지만, Bluesky의 기본 작동 방식은 대략 이렇고 이름만 예상과 다르게 붙인 것 같음
      인덱서가 필요한 이유는 사용자 ID가 시스템에서 정적으로 유지되지 않기 때문임. DID:PLC가 해시의 부분 문자열로 시작했다가 “키 회전” 때문에 시간이 지나며 사용자 본인도 모르게 사용자 ID가 바뀌는 이상한 암호학적 재배치가 일어남
      LiveJournal 같은 시스템인데 핸들이 계속 바뀌고, 그 변화를 추적할 권위자가 필요한 상황을 떠올리면 됨. 물론 제목이나 Markdown 지원 없이 짧은 메시지만 올릴 수 있음
      개인적으로는 정적 공개키를 받고 개인키로 메시지에 서명하는 새로운 DID:PLC를 기다리고 있음. 추적해야 할 것이 훨씬 줄고, 자체 호스팅과 로컬 우선 개발이 훨씬 쉬워질 것 같음
    • 필요하다면 클라이언트인 App View가 여러 릴레이를 병렬로 사용할 수 있을 거라고 봄
      서로 다르지만 겹칠 수도 있는 저장소 집합을 호스팅하는 여러 GitHub 인스턴스에서 데이터를 가져오는 로컬 GitHub UI 같은 구조임
      여러 NNTP 서버에서 뉴스그룹을 모아 보여주는 Usenet 클라이언트와도 비슷함
    • 모든 릴레이가 불법 콘텐츠에 대한 판단 차이를 제외하면 전체 데이터를 갖는 구조일 거라고 예상함
      왜 릴레이마다 네트워크를 다르게 보게 된다고 생각하는지 궁금함

  • 궁금한 건 BlueSky가 프로토콜의 열린 부분만 사용하겠다고 어떻게 신뢰성 있게 약속할 수 있느냐임
    BlueSky는 사실상 꽤 중앙화되어 보이므로, 1사 클라이언트가 꼭 ATProto 클라이언트일 기술적 이유는 없어 보임
    단기나 중기에는 그렇게 하면 사용자 신뢰를 크게 배신하는 일이겠지만, ActivityPub의 사실상 분산 구조가 여기서는 더 강한 안전장치처럼 보임

    • 1사 BlueSky 클라이언트가 무엇을 뜻하는지 모르겠음
      1사 릴레이와 PDS가 다른 프로토콜로 통신할 수 있다는 뜻이라면, 무엇을 걱정하는지 잘 이해가 안 됨
      ActivityPub 클라이언트 두 개도 ActivityPub이 아닌 프로토콜로 서로 대화할 수 있음
    • 모든 코드가 오픈소스라서 신뢰할 수 있음
      실제로 그렇게 하고 있고, 만약 하지 않는 방향으로 바꾸기 시작하면 사람들이 아주 빨리 알아차릴 것임

  • “발화와 도달 범위” 구분까지 간 건 좋지만, 장기적으로는 단순성 때문에 Mastodon이 더 똑똑한 선택처럼 느껴짐
    단기적으로는 Mastodon의 피드 선별이 확실히 더 어렵기 때문에 덜 재미있거나 덜 유용할 수는 있음
    핵심 질문은 가상의, 아마도 부유하거나 권력 있는 악의적 행위자가 여기서 판을 흔들고 싶다면 어떻게 할 수 있느냐임
    글에서 “피드가 어떻게 작동하는지 잘 모른다”는 식으로 이 부분을 너무 대충 넘겨 매우 의심스러움. 피드가 어떻게 작동할지 잘 알고 있고, 그 지점에 권력과 돈이 있다는 것도 알아서 붙잡으려는 것처럼 보임

    • “피드가 어떻게 작동하는지 잘 모른다”는 요약은 적절하지 않아 보임
      글쓴이는 이렇게 말함: “피드는 atproto에 최근 추가된 기능이라 존재하긴 하지만 아직 기능이 완성되지 않았을 수 있고, 앞으로 바뀔 수도 있다. 지켜보자. 내 관점에서는 잘 작동하지만, 낮은 수준의 기술 세부사항까지 따라가고 있지는 않다.”
      바로 위 문단에는 이런 맥락도 있음: “다른 마이크로블로그 도구 대비 BlueSky의 킬러 기능 중 하나는 완전한 사용자 선택권이다. 내가 직접 피드 알고리즘을 만들고 싶으면 만들 수 있고, 다른 사람과 쉽게 공유할 수 있다.”
    • 어느 부분에서 피드 작동 방식을 모른다는 뜻이 나왔는지 모르겠음
      피드는 오픈소스이고, 지금 존재하며, 직접 실행할 수도 있음
      “판을 흔든다”는 게 어떤 판을 어떤 의미로 말하는지도 분명하지 않음. 여기엔 움직이는 부분이 많음

  • 사용자가 호스팅 제공자와 독립된 중재 제공자를 선택하면 인스턴스 선택을 덜 걱정해도 된다는 아이디어는 멋져 보임
    다만 인스턴스는 여전히 현지에서 불법인 콘텐츠를 호스팅하지 않기 위해 중재해야 할 것 같음
    결국 인스턴스를 운영하는 사람들에게 꽤 어려운 일이 되고, 꽤 큰 혼란으로 이어질 수 있음. 내가 오해했을 수도 있음

    • 콘텐츠를 호스팅하는 사람은 자신이 호스팅하는 콘텐츠의 법적 결과를 처리해야 하고, 결국 피할 수 없음
      다만 어떤 프로토콜을 쓰든 이건 마찬가지임
    • 오해한 게 아님. Bluesky의 분산화는 가짜에 가깝다고 봄
      PDS는 적당한 Ubuntu 박스면 되지만, 이 글조차 릴레이가 비싸고 거대한 중앙 통제 지점임을 인정함
      Bluesky의 스팸 대응 계획은 뭘까? 아마 릴레이에서 차단하는 식일 것임
      DID 서버도 또 다른 중앙 통제 지점임
      그래도 PDS는 마음껏 돌릴 수 있겠지만

  • Bluesky에 관한 재미있는 잡학으로, 얼마 전 글과 연결해 보면 이것도 사람 이름에서 따온 셈임
    CEO의 이름이 중국어로 말 그대로 blue sky임

    • 재미있게도 Twitter가 내가 참여하기 전에 이미 프로젝트 이름을 bluesky로 지었음
      우연임. 다만 내 중간 이름은 중국어로 bluesky를 뜻함

  • 이 짧은 만화도 좋음: https://bsky.social/about/welcome-to-bluesky-comic

  • Bluesky가 did:plc 지원을 중단하면 기존 PLC 신원은 전부 망가지는 건가?
    PLC는 그쪽 서비스에 핑을 보내는 구조라서 궁금함

    • https://plc.directory는 미러링할 수 있고, 그런 일이 생기면 새 미러가 권위 서버가 될 수 있음

  • 서드파티 라벨러에는 회의적임
    악용을 어떻게 막을 수 있나?

    • 사용자가 어떤 3자 라벨러를 구독할지 선택함
      라벨러 서비스가 지위를 악용하기 시작하면 사용자가 끊으면 됨
      Bluesky가 라벨러를 생태계에 어떻게 맞추려는지에 대한 자세한 설명은 https://github.com/bluesky-social/proposals/tree/main/0002-l...에 있음
    • 어떤 종류의 악용을 말하는지에 따라 답이 달라짐
      견해를 말할 수는 있지만, 질문이 너무 넓어서 어디서부터 답해야 할지 모르겠음
    • 곧 중재에 대해 훨씬 더 많이 공개할 예정이지만, 라벨러의 기본은 이렇다
      네트워크 안의 누구든 다른 라벨러를 포함해 무엇이든 라벨링할 수 있음
      앱은 현재 Bluesky의 맞춤 피드처럼 사용자가 구독할 라벨러를 노출할 수 있음
      앱은 현재 좋아요와 저장으로 표현되는 인기도에 따라 맞춤 피드를 노출하고 순위를 매기듯, 라벨러가 어떻게 노출되고 순위가 매겨질지도 선별할 수 있음

  • “중재 도구는 도달 범위 계층에 속한다. 모든 발화를 가져오되, 내가 보고 싶지 않은 것의 도달 범위를 제한하는 방법을 제공한다”는 접근은 결국 “보기 싫으면 눈을 감아라”식 중재처럼 보임
    Silicon Valley에서 좋아하는 철학인 건 알지만, 근본적으로 결함이 있다고 봄
    특정 사안에 대해 관련 없는 다른 사람들이 말하거나 특정 콘텐츠를 획득하지 못하게 막아야 하는 정당한 상황이 있음
    전형적인 예가 사이버 괴롭힘, 신상털이, 리벤지 포르노임. 두 명 이상이 제3자를 해치는 방법을 이야기하거나, 사적이고 모욕적이거나 거짓인 정보를 공개하는 식임
    피해자의 피드에서 이 정보를 제거하는 건 완전히 쓸모없고, 애초에 피해자 피드에는 나타나지 않을 가능성이 큼. 피해는 다른 사람들이 그 콘텐츠를 보거나 토론에 참여한다는 데서 오지만, 그 피해는 실제임
    전통적 중재 시스템에서는 중재자가 게시물을 모두에게서 삭제하거나 가해자를 차단해 이런 행동을 멈출 수 있음. “콘텐츠를 숨기기만 하는” 시스템에서는 이게 불가능함
    공유 차단 목록이나 “라벨”도 작동하지 않음. 콘텐츠 소비자는 그걸 차단할 동기가 없고, 오히려 리벤지 포르노를 보고 싶어함
    차단하고 싶은 건 피해자지만, 피해자는 모두에게 특정 차단 목록을 쓰도록 강제할 힘이 없음. 이 시스템의 핵심이 누구도 다른 사람에게 차단 목록을 강제할 수 없다는 데 있기 때문임

    • 이 영역에는 앞으로 더 나올 것이 있음. 이 글에서는 정상적인 경우에 집중했고, 나쁜 경우는 다루지 않았음
      팀은 이런 문제를 검토했고 “전문가와도 상담”했지만, 아직 진행 중인 작업이라 내가 말할 자격이 있다고 느끼지 않음
      “사람들이 그걸 막기보다 보고 싶어하니 라벨이 작동하지 않는다”는 부분은 팀이 명시적으로 인정한 문제 공간에 포함됨
      추가로 여기 참고: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei
답변달기