Nostr 프로토콜, 평문으로 설명

프로토콜은 프로그램들이 서로 통신하는 방식에 대한 규칙 집합입니다. 플랫폼은 당신을 대신하여 이러한 프로그램들을 실행하는 회사입니다. Twitter는 플랫폼입니다. 이메일은 프로토콜입니다. Nostr는 프로토콜입니다.

이 구별이 중요한 이유는 프로토콜과 플랫폼이 다른 장애 모드, 다른 비용 구조, 그리고 다른 미래를 가지기 때문입니다. 이 가이드는 Nostr를 특별히 프로토콜로 만드는 것, 실제로 무엇을 의미하는지, 그리고 왜 설계가 의도적으로 작게 유지되는지를 설명합니다.

TL;DR. Nostr는 암호화 서명이 있는 pub/sub 메시징 프로토콜입니다. 작은 event 형식과 클라이언트가 relay를 통해 이러한 event를 보내고 받는 간단한 방법을 정의합니다. 어떤 회사도 이를 소유하지 않습니다. 누구나 클라이언트를 작성하거나, relay를 실행하거나, 확장을 제안할 수 있습니다. 핵심 명세는 몇 페이지에 맞습니다.

준비되면, @nostr.blog 주소 받기 →

프로토콜이 실제로 무엇인지

이메일은 좋은 비교입니다. Gmail에서 Outlook으로 이메일을 보낼 때, Gmail은 Outlook의 허가가 필요하지 않습니다. 두 서비스 모두 SMTP(이메일 프로토콜)를 사용하며, SMTP는 한 메일 서버가 다른 서버에 메시지를 전달하는 데 필요한 모든 것을 정의합니다. 서버들은 다른 회사입니다. 프로토콜은 중립적인 합의입니다.

Nostr는 같은 방식으로 작동합니다. Nostr event(게시물, 좋아요, 팔로우)는 프로토콜에서 정의한 특정 형태의 JSON 객체입니다. Relay는 그 형태를 준수하는 event를 수락하고, 저장하고, 전달하기로 동의하는 모든 서버입니다. Nostr를 사용하는 두 클라이언트는 누가 세 가지 중 어느 것을 만들었는지와 관계없이, Nostr를 사용하는 모든 relay를 통해 상호 작용할 수 있습니다.

프로토콜은 중립적인 합의입니다. 구현은 어떤 것이든 자유롭습니다.

가장 적은 문장으로 설명하는 Nostr 명세

세 가지 규칙이 거의 모든 것을 다룹니다.

1. Event는 id, pubkey, created_at, kind, tags, content, sig를 가진 JSON 객체입니다. id는 다른 필드의 해시이고, sig는 pubkey의 개인 대응부를 사용하여 id에 대한 Schnorr 서명입니다.
2. Relay는 WebSocket을 통해 유효한 event를 수락하고, 저자, kind, 태그, 또는 시간으로 event를 필터링하는 구독을 제공합니다.
3. 클라이언트는 event에 서명하고 relay에 발행합니다. 필터가 있는 relay를 구독하여 event를 읽습니다.

이것이 핵심 프로토콜입니다. 모든 고급 기능(장문 기사, zap, DM, 커뮤니티, 목록)은 이 틀에 맞는 확장이며 이를 변경하지 않습니다.

프로토콜이 작게 유지되는 이유

대부분의 프로토콜은 축적으로 성장합니다. 모든 사용 사례가 명세에 추가되고, 매 10년마다 명세는 이전 10년보다 커집니다. HTTP는 이제 수백 페이지입니다. 이메일은 몇 개의 RFC에서 엉킨 덤불로 성장했습니다. Nostr는 의도적으로 이를 피했습니다.

메커니즘은 NIP(Nostr Implementation Possibilities)입니다. 새로운 기능들은 핵심 명세에 추가되지 않습니다. 선택적 NIP으로 제안됩니다. 클라이언트는 관심 있는 NIP를 구현합니다. 다른 클라이언트는 이를 무시합니다. 인기 있는 NIP은 충분한 구현이 이를 사용하기 때문에 실질적인 프로토콜의 일부가 됩니다. 인기 없는 NIP는 의식 없이 사라집니다.

이는 핵심이 영원히 작다는 의미입니다(중요한 불변성: 서명된 event, 공개 relay, 휴대 가능한 아이덴티티) 그리고 가장자리는 영원히 유연합니다(새로운 기능은 기존 클라이언트를 깨지 않고 진화합니다). 2022년의 Nostr 클라이언트는 2026년에도 작동합니다. 핵심이 변경되지 않았기 때문입니다. 단지 더 새로운 클라이언트보다 더 적은 것을 합니다.

프로토콜 대 플랫폼, 구체적으로

사용자로서 느낄 수 있는 다섯 가지 실질적인 차이입니다.

아이덴티티. 플랫폼에서 당신의 계정은 회사에 의해 소유됩니다. 프로토콜에서 당신의 계정은 당신이 소유하는 암호화 아이덴티티입니다. 아무도 이를 빼앗을 수 없습니다.

데이터. 플랫폼에서 당신의 게시물은 그들의 데이터베이스에 있습니다. 프로토콜에서 당신의 게시물은 여러 독립적인 relay에 있습니다. 하나가 사라져도 나머지는 여전히 이를 가지고 있습니다.

기능 속도. 플랫폼에서는 회사가 결정할 때 기능이 배포됩니다. 프로토콜에서는 모든 구현자가 기능을 작성할 때 배포됩니다. 이것은 어떤 면에서는 더 느립니다(중앙 로드맵 없음) 그리고 다른 면에서는 더 빠릅니다(많은 병렬 실험).

수익화. 플랫폼에서는 회사가 모든 수익화를 캡처합니다. 프로토콜에서는 수익화는 사용자와 구현자가 동의하는 것입니다. Nostr는 문화에 맞았기 때문에 zap(Lightning을 통한 peer-to-peer 팁)을 가지고 있습니다. 다른 프로토콜 커뮤니티는 다른 규범에 도달할 수 있습니다.

장애 모드. 플랫폼은 완전히 사라질 수 있습니다. 프로토콜은 할 수 없습니다. 한 구현자라도 활동 중이면 프로토콜은 살아있습니다. Nostr는 fiatjaf(원래 저자)이 내일 사라져도 네트워크가 변경 없이 계속 실행되도록 설계되었습니다.

프로토콜이 명시적으로 하지 않는 것

의도적으로 명세에서 제외된 다섯 가지입니다.

중재. 프로토콜은 어떤 콘텐츠가 수용 가능한지 결정하지 않습니다. 각 relay는 자신의 규칙을 가집니다. 각 클라이언트는 자신의 필터를 가집니다. 각 사용자는 자신의 음소거 목록을 가집니다. 중재는 가장자리에서 일어나며, 핵심이 아닙니다.

검색. 프로토콜 정의 검색이 없습니다. 어떤 relay는 텍스트를 인덱싱합니다. 다른 것들은 그렇지 않습니다. 검색을 원하는 클라이언트는 검색 가능한 relay에 의존하거나 자신의 인덱싱을 실행합니다. 이 부재는 의도적입니다. 이는 프로토콜을 발견되는 것에 대해 중립으로 유지합니다.

순위. "For You" 피드가 없습니다. 참여 가중치가 없습니다. 클라이언트는 기본적으로 타임스탬프별로 event를 표시합니다. 다른 모든 순서는 클라이언트 수준의 결정이며, 프로토콜 결정이 아닙니다.

발견. 추천 엔진이 없습니다. 새로운 계정을 찾아 팔로우하는 것은 클라이언트 기능이며, 프로토콜 기능이 아닙니다. 어떤 클라이언트는 이에 크게 투자합니다(Primal). 다른 것들은 사용자에게 맡깁니다(Damus).

복구. 계정 재설정이 없습니다. 개인 키를 잃으면, 계정을 잃습니다. 프로토콜은 키 회전을 포함할 수 있지만 그렇지 않습니다. 트레이드오프가 실제이고 커뮤니티가 특정 메커니즘에 동의하지 않았기 때문입니다. 이것은 진행 중인 영역입니다(NIP-26, NIP-41 초안).

각 생략은 선택입니다. 프로토콜은 프로토콜 수준에서 모든 문제를 해결하기를 거부함으로써 작게 유지됩니다.

Nostr가 누가 되는지 결정하는 사람

아무도 그리고 모두.

Nostr 재단은 없습니다. 기업 워킹 그룹은 없습니다. 운영 위원회는 없습니다. 생태계의 어디든 가장 집중된 권한은 NIP이 제안되는 fiatjaf의 GitHub 저장소이며, 그것도 단지 조정 지점일 뿐이며, 게이트키퍼가 아닙니다.

제안된 NIP은 클라이언트 개발자들에 의해 읽혀집니다. 인기 있는 것들이 구현됩니다. 세 개의 주요 클라이언트가 구현한 NIP은 실질적으로 프로토콜의 일부입니다. 한 명의 개발자가 작성했지만 다른 누구도 신경 쓰지 않는 NIP은 단지 GitHub의 문서일 뿐입니다.

이 프로세스는 복잡합니다. 조정 문제, 중복 제안, 그리고 때때로 정치가 있습니다. 그것은 또한 특정한 방식으로 탄력적입니다: 단일 당사자는 나쁜 결정을 내림으로써 이를 망칠 수 없습니다. 나쁜 결정은 단지 채택되지 않기 때문입니다. 프로토콜은 명령이 아닌 개발자 선택의 무게로 대략적인 방향으로 진화합니다.

프로토콜 모델이 승리하는 경우

프로토콜은 특정 조건에서 플랫폼을 능가합니다:

• 소유권이 다듬기보다 중요할 때. 프로토콜은 보통 플랫폼보다 덜 다듬어집니다. 당신이 다듬기가 줄 수 없는 것(영구적인 아이덴티티, 검열 저항성, 공개 상호 운용성)을 신경 쓸 때 승리합니다.
• 네트워크 효과가 기능일 때. 프로토콜의 가치는 사용자뿐만 아니라 구현자의 채택으로 성장합니다. 더 많은 클라이언트와 relay는 플랫폼이 복사할 수 없는 방식으로 네트워크를 더 강하게 만듭니다.
• 장기 지평이 중요할 때. 플랫폼은 구매, 판매, 종료, 또는 피벗됩니다. 프로토콜은 모든 단일 구현자를 능가합니다. 이메일은 대부분의 회사보다 오래됩니다. Nostr는 같은 동학에 베팅합니다.

당신의 사용 사례가 이들 중 어느 것과도 일치하지 않으면, 플랫폼은 보통 더 빠르고 쉽습니다. 이것은 정직합니다. Nostr는 모든 가능한 사용에 대해 Twitter보다 보편적으로 더 나은 것이 아닙니다. 프로토콜이 플랫폼을 능가하는 특정한 방식에서 더 나은 것입니다.

실제 명세 읽기

이 가이드가 당신이 프로토콜을 직접 읽고 싶게 했다면, NIP 저장소는 전체 목록을 가지고 있습니다. NIP-01은 핵심이고, 그 후의 번호 있는 NIP은 확장입니다. Nostr를 사용하기 위해 이것의 어느 것도 이해할 필요는 없지만, NIP-01을 읽는 데 약 10분이 걸리며 많은 것을 명확하게 합니다.