▲

Nostr

 (nostr.com)
1P by GN⁺ 1일전 | ★ favorite | 댓글 1개
  • Nostr는 중앙 통제를 배제한 개방형 커뮤니케이션 프로토콜로, 다양한 클라이언트·릴레이 조합을 통해 정보를 자유롭게 유통하도록 설계된 아키텍처
  • 사용자는 개인 키·서명 기반 신원과 메시지 진위를 확보하며, 클라이언트는 여러 릴레이에 동시 접속해 분산 전파와 조회를 수행
  • 프로토콜은 소유권이 없지만 각 릴레이 운영자가 자체 정책에 따라 검열·차단 기준을 설정하고, 이용자는 어떤 릴레이를 읽을지 선택함
  • 트위터형 마이크로블로깅을 넘어 폐쇄 그룹(NIP-29), 마켓플레이스, 분산 위키, 코드 협업/토렌트/라이브스트리밍 등 서브-프로토콜과 생태계를 확장 중
  • 아직 완성 제품이라기보다 개발자·얼리어답터 참여가 필요한 단계로, 스팸·스케일링·발견성 같은 과제를 클라이언트·릴레이 조합 전략으로 해결해가는 중

An open protocol with a chance of working

  • Nostr는 정치적 성향과 무관한 커뮤니케이션 공용지를 지향하며, 누구나 구현·사용 가능한 단순 표준으로서 확장성 있는 클라이언트/서버 아키텍처를 정의함
  • 특정 기업·정부가 통제하지 않으며, 다양한 클라이언트가 같은 정보층을 각기 다른 관점으로 보여주는 개방·혼돈의 인터넷 초기 감수성을 수용함
  • 사이트는 실제 클라이언트 스크린샷을 제시하며, 생태계의 다양성과 실사용 지향성을 강조함

Many clients, many servers

  • 중앙집중형 서비스와 달리 Nostr 클라이언트는 복수의 릴레이에 동시에 연결함
    • 각 릴레이는 웹소켓 기반 서버로, 관심 있는 이벤트를 질의하고 구독하는 분산 게시 저장소 역할을 수행함
    • 특정 릴레이만을 단일 신뢰원으로 삼지 않기에 검열·섀도우밴 위험 분산 효과가 있음
  • 참고 자료 링크를 통해 기존 모델과의 차이를 학습 자료로 안내함

A new paradigm for communication

  • 사용자 신원은 비밀 번호인 프라이빗 키로 표현되며, 모든 메시지는 디지털 서명을 포함해 권위기관 없이도 작성자 진위를 검증할 수 있음
  • 이 암호학적 신뢰 기반이 검열 저항적 브로드캐스팅을 가능케 함
  • 사람 친화적 설명 영상 링크를 제공해 입문 난도를 낮춤

The protocol is ownerless, relays are not

  • 프로토콜은 무주체이지만 릴레이는 사적 소유로, 각 운영자가 임의의 수용·거부 기준을 설정할 수 있음
  • 사용자는 읽을 릴레이를 자유롭게 선택하므로, 표현의 다양성과 접속 선택권이 공존함
  • “검열 찬성/반대” 이분법 대신, 서버별 규칙 다원성과 이용자 선택을 핵심으로 둠

Freedom of association

  • 네트워크 효과가 단일 조직에 묶이지 않으므로 특정 이용자 그룹이 다른 이들을 구조적으로 해치기 어려운 구조임
  • 관련 영상을 통해 결사·분리의 자유를 강조함

Your own piece of Nostr

  • 프로그래머는 손쉽게 자체 릴레이를 구동해 자체 규칙을 적용 가능함
  • 릴레이 구현 레포지토리로 안내해 기여와 실험을 독려함

New Ideas — Exploring the commons

  • 트위터형 마이크로블로깅을 넘어, 동영상/장문/이미지/보이스 노트 등 다양한 데이터 타입을 수용함
  • 폐쇄 그룹, 분산 위키피디아, 카우치서핑, 마켓플레이스, 웹 주석 같은 서브-프로토콜 실험이 활발함
  • git 기반 분산 코드 협업, 파일 호스팅, 토렌트 공유, 비디오 라이브 등에서 Nostr를 발견·조정 레이어로 사용하는 시도가 진행 중임
  • 표준 제안 모음 NIP을 통해 기능 확장과 상호운용성을 도모함

Ecosystem — Still under construction

  • 오픈소스 소프트웨어와 큰 사용자 기반이 있으나, 아직 세련된 완제품 단계는 아님
  • 초기 사용자·개발자 참여가 프로토콜 플로우와 UX 개선에 중요함

Microblogging — The outbox model

  • 아웃박스 모델이 검열 저항적 클라이언트 구현의 정석으로 소개되나, 파라미터는 유동적임
  • 구현 가이드는 릴레이를 저장소처럼 다루는 방식과 구독/발행 전략을 설명함

Relay-based groups — NIP-29

  • NIP-29는 포럼/채팅형 폐쇄 그룹을 릴레이 기반으로 효율적으로 구현하는 방식을 제시함
  • 단일 릴레이 의존을 줄이면서도 검열 저항성을 유지하는 구조를 안내함

How Nostr works

  • 가혹한 환경에서도 사용자-청중 연결을 유지하는 진정한 자유 제공을 목표로 함
  • 복수 릴레이, 로컬 인덱싱, 선택적 판독 등으로 지속적 접근성을 담보함

FAQ — 핵심 질문과 답변

  • “프로토콜”이란 무엇인가

    • 여러 소프트웨어가 상호 통신하는 공통 언어로, e-mail/HTML/HTTP처럼 특정 앱에 종속되지 않는 상호운용성을 의미함
    • 하나의 언어를 공유하는 여러 앱이 대체 가능하며, 각자 표현·UI를 달리함

  • 스팸과 원치 않는 콘텐츠는 어떻게 다루는가

    • 기본 피드는 내가 팔로우한 사람의 정보만 가져오므로 푸시 스팸이 어려움
    • 댓글 보기처럼 개방된 조회는 스팸에 노출될 수 있어, 2도 이웃 제한, 신뢰 릴레이 화이트리스트, 유료/인증 릴레이 등 접촉면 축소 전략을 활용함
    • 완벽한 해법은 없으나, Nostr는 회복탄력성을 전제로 설계됨

  • 대규모 채택 시 스케일은 가능한가

    • 기본은 클라이언트-서버 아키텍처이며, 사용자가 수백 릴레이로 자연 분산되므로 부하 분산이 내재함
    • 많은 릴레이 연결이 우려될 수 있으나, 사람들은 유사 관심사 계정 묶음을 팔로우해 릴레이가 자연 공통분모를 형성함
    • 네이티브 앱은 수백 웹소켓을 감당 가능하며, 로컬 데이터베이스로 배치 요청을 통해 성능을 확보함

  • 온라인 괴롭힘은 어떻게 대응하는가

    • 스팸과 유사하게 원치 않는 게시가 가능하므로, 차단, 공유 차단 목록, 제한 읽기 릴레이 등으로 노출 최소화를 구현함
    • 친구만 보기 등 보호 기능을 릴레이 정책으로 에뮬레이션 가능함

  • 왜 Mastodon/페디버스가 아닌가

    • 암호학 부재로 멀티 마스터가 불가하여 서버 소유 신원 문제와 서버 간 신뢰 전이 문제가 발생함
    • 서버 운영자에 대한 과도 신뢰가 필요하며, 도메인·DNS 의존성도 문제로 지적됨
    • Nostr는 서버 비귀속 신원과 릴레이 선택으로 진짜 커뮤니티를 릴레이 단위로 형성 가능함

  • 왜 Bluesky/ATProto가 아닌가

    • PLC 기반 신원 중앙화와 Relay-AppView-Client 단일 정본 흐름으로 검열·재정렬·섀도우밴 위험이 큼
    • 다중 소스화로 개선 가능하나, 그렇게 되면 사실상 Nostr와 유사 구조로 수렴함

  • 릴레이 운영 인센티브는 정렬되어 있는가

    • 서버 운영 비용이 낮고, 커뮤니티/개인/조직/호스팅 업체 등 다양한 주체가 릴레이를 저렴하게 제공 가능함
    • 사용자가 어디든 갈 수 있어 다양한 경제 주체가 동기화됨

  • 여러 릴레이로 흩어진 콘텐츠를 모두 볼 수 있는가

    • 세상 만사를 모두 볼 수 없듯, 초점과 접근 허용 범위 내에서만 관찰 가능함
    • 이는 주의 집중과 릴레이 선택에 따른 자연스러운 제약임

  • 검색은 어떻게 동작하는가

    • 본질적으로 본 것이어야 검색 가능하므로, 공개 검색을 원하면 크롤러/인덱서가 선택적으로 네트워크를 수집해야 함
    • 클라이언트는 로컬 저장을 통해 내가 본/상호작용한 콘텐츠를 로컬 검색으로 빠르게 찾을 수 있음
    • 주제 릴레이는 자체 인덱싱으로 유용한 범위 검색을 제공할 수 있음

  • 알고리듬이 없으면 신규 콘텐츠는 어떻게 발견하는가

    • 팔로잉의 상호작용 그래프 탐색이 기본이며, Nostr도 로컬/릴레이/AI 기반 알고리듬을 가질 수 있음
    • 클라이언트 로컬에서 하이라이트/복귀 서피싱, 릴레이 측 큐레이션 등 다양한 발견성 메커니즘을 적용 가능함

  • 비트코인과의 관계는 무엇인가

    • 암호학 원리를 공유하고 비트코인 커뮤니티에서 출발했으나 의존성은 없음
    • Zaps는 일부 클라이언트가 구현한 비트코인 팁 표준으로 완전 선택 사항임
▲
GN⁺ 1일전  [-]
Hacker News 의견

  • Nostr의 암호화 기술이 심각하게 허술함을 알 필요가 있음
    이 논문에서 발표된 주요 취약점은 다음과 같음

    • 이벤트 프로토콜이 공개키 인증을 안 해서, 대칭키 서명은 형식적인 수준에 불과함

    • Damus, Iris 같은 주요 클라이언트 둘은 서명 자체를 검증도 안 함

    • 시스템 내 DM이 인증되지 않은 CBC 암호화 방식이라, 공격자가 메시지 비트플립으로 내용을 바꿀 수 있음

    • 앱들이 자동 링크 프리뷰를 하면서 예전 EFAIL 공격이 재현 가능한 상태임

    • 시스템에서 키 구분이 없어, 사용자를 속여 세션 키를 잘못 쓰게 만들 수 있음

    • 전반적으로 2000년대 중반 수준의 초보적 실수임

    • Nostr의 다른 장점이 있을 수 있지만, 종단간 보안을 원한다면 적합하지 않은 플랫폼임

    • Nostr 커뮤니티에서 오래 활동했고 Safari용 확장도 만들어봤음
      해당 논문을 안 읽었지만, 지적된 부분은 Nostr 프로토콜 자체에 대한 오해 혹은 착각이 있다고 생각함
      Nostr에서 공개키가 곧 아이덴티티로 작동함
      암호학적으로는 공개키 기반 신원은 위조 불가임(다만 구현 버그는 논외로 함)
      UX적으로 '공개키 주인의 진짜 신원 검증'이 어려운 점은 있지만, 이는 암호화 안전성과는 별개의 이슈임

    • '이벤트 프로토콜이 공개키 인증을 안 한다'는 건 완전 말이 안 됨
      대부분의 클라이언트와 릴레이는 실제로 서명 체크를 함
      Damus 저자로서 밝히자면 이는 예전 버전 얘기임 — 해당 문제는 해결됨
      초기에는 신뢰된 릴레이만 연결했고, 이 릴레이들이 서명을 검증함
      최적화된 서명 검증을 위해 nostrdb라는 임베디드 DB까지 만듦
      DMs가 인증되지 않은 CBC라서 공격 가능하다는 지적도 틀림
      전체 노트가 secp256k1 서명으로 커버되고 있음
      자동 링크 프리뷰, 이미지 등은 껐다 켰다 할 수 있고 걱정된다면 VPN 권장함

    • Nostr에서 어떤 키 알고리즘이 쓰이는지 찾으려 했으나 문서 어디도 직접적으로 명시 안 돼 있음
      검색하면 다 Blech32 (비트코인 키 인코딩) 관련 내용으로 연결됨
      hellonostr.dev 소개 문서를 보면, 인코딩 자체에 버전 정보가 내포되어 있음을 알 수 있음
      npub1abcxyz... 형식에서 npub가 헤더, 1이 버전, 뒤가 키에 해당함
      관련 문서 참고 바람

    • 지적된 문제들은 실제로는 구현 의존적이거나(서명 안 하는 앱, 이는 프로토콜의 본질을 무너뜨리는 행위),
      초창기 임시 암호화 방식에 기인한 것임(이미 NIP44 등으로 대체되고 독립 감사를 거침)
      현재로선 치명적이거나 실질적으로 대응이 필요한 문제점이 없음

    • 왜 이런 문제를 이제서야 처음 듣는지 모르겠음
      신속하게 논의되어야 함
      프로토콜 관점에서 더 안전한 연방형 플랫폼은 bluesky(at protocol)일지, fediverse일지 궁금함

  • 많은 사람들이 Nostr 릴레이가 연방을 이루며 메시지를 공유한다고 오해하고 있음
    실제로 그렇지 않음
    트위터 클론을 만든다면, 클라이언트 앱이 여러 릴레이를 직접 검색·포스트해야 하고
    공통 릴레이를 사용하지 않으면 서로의 메시지를 못 봄
    단일 릴레이만 쓸 경우 완전 중앙집중화되어 버리고,
    여러 릴레이를 쓰면 느리고 번거로워서 사용자가 어떤 릴레이를 연결하는지 직접 알아야 함
    NIP 문서도 뒤죽박죽이라 유지보수에 어려움이 있었음

    • 릴레이들도 연방이 가능함
      Nostr 프로토콜은 연방 여부에 대해 아무것도 명시하지 않음
      나는 인덱서(릴레이)를 운영 중이며, 이 인덱서가 다른 릴레이와 연동함
      ActivityPub 릴레이처럼 아무 클라이언트나 인덱서에 연결해 부트스트랩, 이벤트 메타데이터 검색 가능
      같은 릴레이에 연결 안 해도 클라이언트 사이엔 다양한 방법으로 정보 소통이 가능함

    • 굉장히 흥미로운 난제라고 생각함
      NIP65 처럼 프로필 메타데이터에 읽고 쓰는 릴레이를 명시하면,
      클라이언트가 모든 적합한 컨텐츠를 쉽게 찾을 수 있음
      그 외에도 여러 아이디어가 실험 중임
      해결 가능한 문제라고 봄

    • 릴레이는 사용자 생성 컨텐츠를 소유하지 않으므로 연방의 필요가 없음
      클라이언트는 보통 유저가 직접 선택한 릴레이 세트에 의존함
      그래도 주요 릴레이 중 상당수가 타 릴레이의 이벤트도 저장하는 식(일종의 연방)을 운영함
      예: Primal, TheForrest, nostr.land
      nostr.land는 스팸 필터링과 여러 퍼블릭 릴레이의 노트 집계를 주목적으로 하며 유료 릴레이임
      원하지 않으면 다른 릴레이 선택 가능
      대부분 사용자는 현재의 릴레이 연방에서 99% 이상의 노트를 볼 수 있지만, 실제 수치는 검증 불가
      일부 클라이언트와 서명자는 노트를 비공개로 저장하며,
      만약 릴레이가 노트 검열 시 다른 릴레이로 언제든 재게시하는 식으로 대응 가능
      실제로 인기 유료 릴레이를 사용하면 3/4 쓰기 이벤트에서 “이미 다른 릴레이에 등록됨” 경고를 빠르게 경험하게 됨
      마지막으로 릴레이는 스스로 클라이언트 역할도 하며, 이 기능 덕분에 모바일이나 네트워크 느릴 때 캐시로 편리함
      아웃박스 방식은 문제점도 있지만 클라이언트 개발자가 옵션 제공할 수 있으므로,
      연방형에서 P2P까지 유연하게 확장 가능함

    • 대부분 클라이언트가 아웃박스를 지원해서, 같은 릴레이를 쓸 필요가 없음
      각 사용자는 별도 인박스, 아웃박스 릴레이를 가질 수 있음

    • NIP 문서에 이상한 부분도 있었지만
      대부분의 NIP는 잘 개선되고 있고,
      공식 정기 릴리스가 있으면 사소하게 해결될 문제임
      많은 개발자들이 빠르게 대응하고 있음

  • 이런 프로젝트들이 사용사례, 철학, 구현을 명확히 구분해서 설명하면 좋겠음
    처음 보면 이게 소셜 네트워크인지, 프로토콜인지 구분이 안 됨
    “검열지향인가? 블로그 아티클 읽어야 하나?”
    Scuttlebutt, Mastodon, ActivityPub, Diaspora 등도 똑같음
    도대체 “이메일과 뭐가 다름?”, “트위터랑 비교해 뭐가 나음?”
    알기 전에 “이게 기술 구현인지, 제품인지, 사이트인지, 앱인지부터 헷갈림”
    Urbit도 정확히 설명 가능한 사람 별로 없을 것
    그래도 “Web3”보다는 낫다고 봄
    Bluesky, Gemini 정도가 이 부분 명확함

    • Nostr는 P2P 구조와 웹 아키텍처 사이에서 타협한 솔루션임
      웹 서버를 활용해 인터넷 흐름에 맞추면서,
      사용자는 서버 의존도를 낮추고 공개키/서명으로 신원 및 데이터 인증을 강화함
      그 결과 사용자에게 “credible exit”과 같은 권한 이양이 생김
      따라서 새로운 사용사례라기보다 “새로운 인터넷”이라 부름
      플랫폼 중심이 아닌 사용자 중심 트레이드오프가 존재함(UX 패턴 차이도 포함함)
      기존 소셜 네트워크의 검열 저항과 유사한 가치를 제공하기에
      사회적 응용사례가 많아 보이는 것임

    • 직접 그런 사이트를 만들어보면 좋겠음

  • “apolitical”이라는 단어를 제품 설명 첫줄에 쓴 게 너무 이상함
    동시에 “open”이라는 단어도 들어가 있는데, 여기선 본질적으로 정치적 의미임
    Nostr에 암호화폐 연관성이 있었는지 기억 안 나는데, 뭔가 헷갈렸던 거 같음

    • Nostr는 “nostr 코인”도 없고, 온체인 액션도 없음
      이 점이 굉장히 마음에 듦
      특별히 Nostr와 암호화폐 커뮤니티의 교집합이 완전히 겹쳐 보였기 때문임

    • 비트코인을 주로 쓰는 이용자가 많음

    • 우익들이 자신을 “apolitical”이라 부르는 역사가 길었음

  • Nostr, Mastodon, Discord 같은 연방/분산 구조 서비스는
    클라이언트앱 자체에 자기 릴레이를 내장해 모든 사용자가 서버 역할도 해야 진짜 분산형 SNS 실현 가능함
    고전적 P2P 소프트웨어는 이미 그렇게 해왔고, 실제로 잘 작동함
    단, 사용자가 자신이 직접 얻지 않은 데이터도 임의로 호스팅하면
    불법 컨텐츠로 인해 처벌을 받는 문제(예: 공항에서 불법 약물 소지 적발 케이스)와 비슷함
    이런 리스크 때문에 다음 세대 P2P 구조는 AI 기반의 “불법 컨텐츠 필터링(예: CP, 영화)”이 필요함
    아니면 완전히 폐쇄적 커뮤니티로 만들어
    만약 문제가 발생해도 커뮤니티 내부에서만 책임지게 해야 함
    결국 모든 클라이언트가 서버도 되는 모델이 최고의 분산형 소셜 모델임

    • iroh라는 프로젝트가 이렇게 작동함
      “릴레이”는 두 클라이언트 간 연결 중계 역할을 할 뿐임
      iroh 개념 설명 링크 참고

    • 멋지긴 하나, 실제 P2P 구조는 잘 안 돌아감
      iroh조차 릴레이를 내부적으로 의존함
      Nostr는 릴레이에 정책 집행 권한을 직접 부여함(이를 별도 해킹 없이 구현 가짐)

  • Nostr가 HN 톱을 찍어 반가움
    아직 초기 단계지만 Nostr는 “zapps”(Bitcoin-Lightning 기반 인스턴트 소액 페이)도 가능함
    광고나 알고리즘 이슈 없이 창작자에게 직접 소액 보상이 가능한,
    탈중앙 광고 없는 SNS 모델임

    • Nostr 클라이언트 PR 작업에도 zaps로 보상 가능함
      관련 바운티 예시 참고

    • Bitcoin은 이미 규제가 심함

    • 이런 댓글을 읽고 가입충동이 들다가도, 실제 탐색 페이지에서
      사람들이 진짜 상품(기, 카카오, 대안 교육 등)을 거래하고 있어 인상 깊었음
      단순 “일기 공개하고 돈 달라”가 아니라는 점에서 색다름
      실질적인 상품이나 서비스, 창작자를 위한 플랫폼임

    • Nostr는 적어도 5년 전부터 존재함
      팬데믹 때도 트위터에서 Nostr로 이동하는 사람 많았음
      이제 막 초기 단계라는 표현엔 동의 어려움

  • 다양한 Nostr 앱 소개
    openux.app - Mobbin 대체 서비스
    kinostr.com - 실시간 영화 채팅
    zap.stream - Twitch 스타일 라이브 스트리밍
    dtan.xyz - 토렌트
    zapstore.dev - 허가 필요 없는 앱 스토어
    nostrnests.com - 오디오룸 채팅
    zapmeacoffee.com - Buy Me A Coffee와 유사

    • Nostr 기반으로 Quora/StackOverflow 대체 서비스도 개발 중임
      asknostr.site
      이렇게 분산 소셜 프로토콜이 여러 다양한 사용사례를 가능하게 하며,
      이용자 측면에서의 장점은
      • VC 회사에 “데이터 빼앗김” 방지
      • 기여할 때 보상(zaps/머니) 가능
      • 데이터는 모두가 자유롭게 접근 가능(서명은 저자만 가능)

  • Nostr는 마이크로블로깅 서비스로만 쓰지 않아도, 하위 레이어로 다양한 쓰임이 있음
    예: Trystero는
    중앙 서버 없이 P2P WebRTC 연결을 맺을 때 Nostr를 이용함
    (MIT 라이선스)

    • 나도 Nostr, Bittorrent DHT, Mastodon 등으로 검열 저항 다중채널 브로드캐스트를 고민한 적 있음
      모든 방법이 실패해야지만 네트워크 단절이 일어나게 하는 게 목표임

    • 이와 비슷하게 Nostr나 ATProto가
      P2P 인스턴트 메신저의 “오프라인 메시지 저장소”로도 활용 가능할지 궁금했음
      연결 성립용으로 쓴 것도 참신한 방식임

    • 진짜 멋진 아이디어임
      나도 비슷한 거 해보고 싶었지만 남이 이미 만들어줘서 시간 절약됐음

  • 이런 기술적 소셜 네트워크는 왜 기존 웹처럼
    각자 개인 홈페이지(오리지널 웹처럼) 연동 구조에서
    별도의 계정 기반 플랫폼으로 가는지 이해 안 됨
    RSS 말고, 개인 사이트 운영을 장려하면서
    중앙화된 소셜 미디어(채팅, 피드 등)를 덧붙인 네트워크 시도는 없었는지 궁금함

    • 여기서 “계정”이란 사실상 공개/비공개 키 쌍임
      자기 릴레이도 직접 운영할 수 있고,
      같은 공개키로 어떤 릴레이든 쓸 수 있음
      포스트도 원하는 모든 릴레이에 브로드캐스트 가능
      원한다면 매 포스트마다 새로운 키 생성도 가능
      Mastodon 등은 계정이 서버에 귀속되니 이동성과 자유도가 떨어짐
      단, 계정 복구 방법은 아예 없어서 문제될 수 있음

    • RSDS(Really Simple Decentralized Syndication) 참고하면 좋을 듯함

    • 대체로 nostr가 그런 구조임
      다만 웹사이트 대신 “노트” 자료형으로, 서버 대신 “릴레이”만 씀

    • “명확히 기술자 대상 서비스”라고 왜 생각하는지 질문함
      창업자 머릿속을 단정하는 건 아닌지 반문함

    • 본질적으로 이미 여러 기술을 조합해서
      개인 홈페이지/채팅/피드 시스템을 직접 만들 수 있음
      대신 이런 혼합 모델의 현실적 문제는

      • 진입장벽: 비기술자 접근성 개선
      • 발견성: 정보 탐색/서로 연결의 문제
      • 지속가능성: 운영 비용 분담
      • 거버넌스: 커뮤니티 내 자치 기능
        이 모든 걸 동시에 풀려다 보면 필연적으로 절충이 생김
        완전한 분산화는 발견성·접근성 문제와 맞바꿈
        “더는 계정이 필요하지 않다”는 주장도 온라인·오프라인 복수 신분 문제와 얽힘
        결국 이는 가치 선택의 문제로, 기술자들에게 인기 있는 다양한 실험적 분산 서비스(Ex. Mastodon, Nostr, Smolweb)는
        초기 인터넷의 마인드셋(반문화, 오픈, 표준화, 조합성)의 영향을 품고 있음
        모든 사람이 만족하는 방안은 있을 수 없으니,
        인터넷 본연의 가치는 다양성, 표준화, 오픈에 있다고 생각함

  • “apolitical communication commons”
    일부는 ‘비정치적’이란 꼬리표 자체가
    이미 정치적 발언이자, 권력적 입장임을 지적함

    • “정치”에 대한 두려움이 왜 큰지 의문임
      시민으로서 정치참여는 당연한 의무라는 고대 그리스의 기본 원칙을 예시로 듦
      실제 ‘idiot’라는 단어의 어원이 apolitical인 사람임

    • “apolitical”이라는 개념은
      실제론 권위주의 체제 아래선 침묵하며 현 체제를 암묵 지원하는 자로 인식됨
      러시아처럼 독재 체제에서는 이게 곧 자유 억압·탄압으로 이어지는 지름길임
      Nostr 같은 서비스는 정부가 “릴레이 운영 불법/범죄화” 선언하는 식으로 막혀왔음

    • “모든 게 정치면, 정치가 아무것도 아닌 것”
      저자는 그냥 비기술적 논쟁을 피하고 싶은 듯 보임

    • “apolitical”이란 누구나 환영이라는 의미로 해석할 수도 있음
      진입장벽은 오직 인터넷 연결뿐이며
      최근 10년간 SNS 검열 트렌드에 대한 반작용 맥락에서 썼을 것임

    • 어떤 사람들은, “특정 지위의 특권을 활용해 남을 도와야 한다”고도 주장함
      여기에서도 적용될 수 있음

답변달기