Nostr NIP 설명: 프로토콜의 사양 문서

Nostr의 진화는 NIP을 통해 이루어집니다. 누구나 제안할 수 있는 짧은 사양 문서입니다. 잡이나 암호화된 DM 같은 새로운 기능이 프로토콜에 어떻게 추가되는지 이해하고 싶다면 NIP이 답입니다.

이 가이드는 NIP이 무엇인지, 거버넌스 메커니즘으로 어떻게 작동하는지, 기술적으로 심화하고 싶을 때 어떤 것을 읽어야 하는지를 다룹니다.

NIP은 GitHub의 Nostr 기능을 구현하는 방법을 제안하는 짧은 마크다운 문서입니다. 클라이언트 개발자들은 어떤 것을 지원할지 선택합니다. 충분한 수의 구현자가 채택할 때 NIP은 "현실"이 됩니다. 널리 사용되는 NIP의 핵심 세트는 약 30개이고, 전체 목록은 약 100개에 가깝습니다.

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

NIP이 실제로 무엇인지

NIP은 github.com/nostr-protocol/nips 저장소의 마크다운 파일입니다. 각 파일은 특정 기능, 형식 또는 규칙을 설명합니다: 이벤트에 서명하는 방법, 프로필 메타데이터 이벤트가 어떤 모습인지, 직접 메시지를 보내는 방법, Lightning 잡 요청이 어떤 형식인지.

크기는 다양합니다. 가장 짧은 NIP은 1페이지 미만이고, 가장 긴 것은 수천 단어입니다. 대부분은 500~2000단어 정도입니다. 사양만으로 구현 가능하도록 작성되므로 메시지 형식, 필수 필드 및 예제 이벤트를 포함합니다.

명명 규칙은 NIP-XX이며, 여기서 XX는 숫자입니다. 번호는 NIP이 병합될 때 할당되며, 우선순위나 중요성을 반영하지 않습니다. NIP-05는 인증된 식별자에 관한 것이고, NIP-04는 이전 DM 표준이며, NIP-01은 핵심 프로토콜입니다. 번호는 제안 순서를 추적하며, 기능의 중요성이 아닙니다.

"Implementation Possibilities"인 이유

이름은 의도적인 선택입니다. 다른 사양 전통과 비교해보세요.

• RFC(인터넷 프로토콜의 의견 요청)는 상호 운용성을 위해 필수가 되는 경우가 많습니다.
• EIP(Ethereum 개선 제안)는 네트워크 업그레이드를 통해 필수가 되는 경우가 많습니다.
• NIP은 영구적으로 선택사항입니다. 40개의 NIP을 구현하는 클라이언트와 10개의 NIP을 구현하는 클라이언트는 모두 유효한 Nostr 클라이언트입니다. 단지 다양한 기능의 부분집합을 하고 있을 뿐입니다.

이는 NIP이 기존 구현을 절대 "깨뜨리지" 않음을 의미합니다. 어떤 기능에 대한 새로운 NIP이 더 오래된 클라이언트에 변경을 강요하지 않습니다. 프로토콜은 가장자리에서 성장하는 동안 핵심은 안정적으로 유지됩니다.

NIP의 생명주기

새로운 NIP이 어떻게 존재하게 되는지:

1. 누군가 격차 또는 필요를 알아봅니다. "우리는 X를 하는 표준적인 방법이 없습니다." 클라이언트 개발자, 릴레이 운영자 또는 특정 문제로 좌절한 사용자일 수 있습니다.
2. 그들이 초안을 작성합니다. 형식은 기존 NIP을 따릅니다: 제목, 목적, 사양, 예제.
3. 그들이 풀 요청을 제출합니다 NIP 저장소에.
4. 커뮤니티가 검토합니다. 개발자, 릴레이 운영자 및 관심 있는 사용자들이 댓글을 남깁니다. 초안은 피드백에 따라 수정됩니다.
5. 병합 또는 포기. 병합된 NIP은 번호를 받고 저장소의 일부가 됩니다. 포기된 초안은 풀 요청 기록에 남습니다.
6. 구현 따름 (또는 안 함). 일부 NIP은 몇 주 내에 구현됩니다. 일부는 몇 년을 기다립니다. 일부는 널리 구현되지 않습니다.

프로세스는 가볍습니다. 위원회 투표, 정식 승인이 없습니다. 풀 요청이 광범위한 긍정적 피드백을 받고 명백한 필요를 해결하면 병합됩니다.

사용자로서 중요한 NIP

대부분의 NIP은 사용자에게 보이지 않습니다. 몇 가지는 일상 경험에 영향을 미칩니다:

• NIP-01: 핵심 프로토콜. 이벤트가 구성되고 서명되는 방법. 당신은 절대 이를 보지 않지만, 다른 모든 것은 이에 의존합니다.
• NIP-05: 인증된 식별자. you@domain.com 읽기 쉬운 이름을 제공합니다. NIP-05 가이드에서 다룹니다.
• NIP-07: 브라우저 확장 서명. 웹 클라이언트가 개인 키를 보지 않고 서명하도록 허용합니다.
• NIP-19: Bech32 인코딩. 당신의 공개 키가 원본 16진수 대신 npub1...처럼 보이는 이유.
• NIP-23: 장형 기사. Nostr에서 블로그 스타일의 게시물을 활성화합니다.
• NIP-44: 암호화된 DM. 최신 직접 메시징 표준 (이전 NIP-04보다 나음).
• NIP-57: 잡. 공개 영수증이 있는 Lightning 팁.
• NIP-98: HTTP 인증. Nostr 식별자가 일반 웹사이트에서 인증하도록 허용합니다.

사용자로서 당신은 이 모든 것의 이점을 프로토콜 세부 사항과 상호작용 없이 누립니다. 클라이언트가 프로토콜 세부사항을 처리합니다.

개발자인 경우 중요한 NIP

Nostr 클라이언트를 작성하거나 유지하고 있다면, 읽을 가치가 있는 NIP이 수십 개로 증가합니다:

• NIP-01부터 NIP-10 (핵심 메커니즘).
• NIP-11 (릴레이 정보 문서).
• NIP-13 (스팸 저항을 위한 작업 증명).
• NIP-17 (메타데이터 숨기기를 위한 선물로 싸인 DM).
• NIP-22 (이벤트 만료).
• NIP-27 (텍스트 노트 참조).
• NIP-30 (사용자 정의 이모지).
• NIP-31 (이벤트 종류).
• NIP-33 (매개변수화된 대체 가능 이벤트).
• NIP-42 (릴레이 연결 인증).
• NIP-47 (Nostr Wallet Connect).
• NIP-50 (검색 기능).
• NIP-65 (릴레이 목록 메타데이터).
• NIP-78 (임의의 사용자 정의 앱 데이터).

이것들은 대부분의 주류 클라이언트가 구현하는 것들입니다. 이 세트와 위의 사용자 대면 NIP을 지원하는 클라이언트는 일반적인 사용의 95%를 다룹니다.

NIP 읽기

직접 읽고 싶다면 저장소는 github.com/nostr-protocol/nips에 있습니다. 대부분의 NIP 구조:

• 제목과 설명. NIP이 제안하는 것.
• 동기. 기능이 필요한 이유.
• 사양. 정확한 메시지 형식, 필수 필드, 유효성 검사 규칙.
• 예제 이벤트. 순응하는 이벤트가 어떤 모습인지를 보여주는 구체적인 JSON.
• 클라이언트/릴레이 동작. 구현이 이벤트를 처리하는 방법.

NIP은 개발자가 구현할 수 있도록 읽기 쉽게 작성됩니다. 사양 섹션이 중요한 부분입니다. 실제 프로토콜이 살아있는 곳입니다.

부분 채택이 있는 NIP

일부 NIP은 존재하지만 클라이언트 간에 일관되지 않게 구현됩니다. 이는 경험이 클라이언트에 따라 다양한 엣지 케이스를 만듭니다.

NIP-44 (암호화된 DM). Damus, Primal, Amethyst 및 대부분의 주요 클라이언트가 2024-2025년에 채택했습니다. 일부 이전 클라이언트는 여전히 NIP-04만 지원합니다. NIP-04만 지원하는 클라이언트를 가진 누군가에게 DM을 보내면 NIP-44 메시지가 자동으로 실패합니다. 실질적인 답변: 최신 클라이언트를 사용하고 상대방도 그러기를 바랍니다.

NIP-17 (선물로 싸인 DM). 메타데이터를 숨기는 DM. 2026년의 채택은 성장하고 있지만 보편적이지는 않습니다. 기능은 양쪽 당사자의 클라이언트가 이를 지원하는 곳에서 훌륭하지만, 그렇지 않으면 덜 개인적인 DM으로 자동 폴백됩니다.

NIP-46 (원격 서명자). 하드웨어 서명자 또는 벙커 앱이 클라이언트를 대신하여 이벤트에 서명하도록 허용합니다. Amethyst에서 지원되고, 다른 곳에서는 부분적입니다.

NIP-65 (사용자 릴레이 목록). 사용자가 선호하는 릴레이를 게시하므로 클라이언트가 올바른 장소로 자동 라우팅할 수 있습니다. 채택은 개선 중입니다. 이전 클라이언트는 이를 무시합니다.

NIP-50 (검색). 클라이언트가 텍스트 일치를 위해 릴레이를 쿼리하도록 허용합니다. 일부 릴레이는 이를 지원합니다. 많은 것은 그렇지 않습니다. 검색 품질이 일관되지 않습니다.

주어진 클라이언트가 어떤 NIP을 지원하는지 확인하는 것은 예상대로 작동하지 않을 때 유용한 진단입니다. 대부분의 클라이언트는 설명서에 NIP 지원 매트릭스를 게시합니다.

NIP 프로세스가 프로토콜의 일관성을 유지하는 방법

중앙 권한이 없으므로 일관성은 사회 역학에서 나옵니다. 몇 가지 관찰:

나쁜 NIP은 전파되지 않습니다. 기존 NIP을 중복하거나 잘못된 문제를 해결하는 제안은 최소 채택을 받고 조용히 죽습니다. 커뮤니티는 공식적이지 않지만 의견이 있습니다.

좋은 NIP은 독립적으로 구현됩니다. 여러 클라이언트 개발자가 제안을 읽고 독립적으로 결정합니다. 좋은 아이디어는 채택자를 축적합니다. 나쁜 아이디어는 그렇지 않습니다.

경쟁 NIP이 때때로 나타납니다. 같은 기능에 대한 두 가지 다른 제안이 한동안 공존할 수 있습니다. 보통 하나가 실제로 승리합니다. 더 많은 클라이언트가 이를 구현하기 때문입니다. 때로는 병합됩니다.

포크 호환 진화. NIP은 선택사항이므로, 클라이언트는 NIP-X-v1을 구현할 수 있고 나중에 v1만 지원하는 사람을 깨지 않고 NIP-X-v2로 업그레이드할 수 있습니다. 프로토콜은 분할되지 않습니다.

이는 엉망이지만 기능합니다. 프로토콜은 중앙 거버넌스 본체 없이 5년에 상당히 진화했습니다. "구현자들이 읽고, 구현자들이 결정하고, 구현자들이 코딩"의 사회 메커니즘이 프로토콜이 일관된 결과를 생산하기에 충분한 정렬이 있기 때문입니다.

자신의 NIP 제안하기

Nostr 기능에 대한 아이디어가 있다면:

1. 먼저 NIP 저장소를 확인하세요. 누군가는 이미 제안했을 수 있습니다.
2. 그렇지 않다면, 해결하려는 문제를 설명하는 GitHub 이슈를 열어보세요.
3. 피드백에 따라 기존 형식을 따르는 전체 NIP 초안을 작성합니다.
4. 풀 요청을 제출합니다.
5. 논의에 참여하세요. 수정하기를 기꺼이 수용하세요.
6. 병합되면 좋습니다. 그렇지 않으면 문제가 더 나은 해결책을 가질 수 있습니다. 그 이유를 고려하세요.

모든 좋은 아이디어가 NIP이 되는 것은 아닙니다. 모든 NIP이 기능이 되는 것은 아닙니다. 생태계는 단일 개발자가 추적할 수 있는 것보다 더 많은 제안을 가지고 있으며, 필터는 "충분한 수의 커뮤니티가 이를 구현하는가"입니다. 그 필터가 Nostr이 하향식이 아니면서 일관된 상태를 유지하는 핵심입니다.