Nostr

이벤트에는 pubkey, created_at, kind, tags, content, id, sig가 있습니다. NIP-01은 엄밀히 정한 직렬화 결과에 SHA-256을 적용해 id를 만들고 secp256k1의 BIP340 서명을 사용합니다. 클라이언트는 무결성과 키에 의한 승인을 확인합니다. created_at은 작성자가 적은 값이며 독립적인 시각 인증이나 내용의 진실성 증거가 아닙니다. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

클라이언트는 WebSocket으로 EVENT를 게시하고 REQ로 구독합니다. OK는 해당 릴레이의 수락 또는 거절을 알립니다. EOSE는 저장된 이벤트 목록의 끝이며 새 이벤트 구독의 종료와는 다릅니다. 이들 메시지는 수신자 도착, 전체 네트워크 복제, 영구 보관을 확인하지 않습니다. [Nostr — NIP-01: Basic protocol]

하나의 필터 안에서는 모든 조건을 충족해야 합니다. 작성자와 종류는 AND입니다. 한 REQ의 여러 필터는 OR이므로 하나만 맞아도 됩니다. limit는 초기 목록을 제한하며 미래 이벤트 수를 제한하지 않습니다. 결과가 없는 이유는 릴레이의 제한된 이력일 수 있으며 이벤트의 부재를 뜻하지는 않습니다. [Nostr — NIP-01: Basic protocol]

교체 가능한 이벤트는 pubkey와 kind로 비교하며, 주소 지정 가능한 이벤트는 d 태그도 사용합니다. 새 버전이 이전 것을 대체할 수 있고 시간이 같으면 사전순으로 작은 id가 우선합니다. 임시 이벤트는 보관을 기대하지 않습니다. 이는 릴레이 동작 규칙이지 불변의 전 세계 아카이브가 아니며 구현마다 다를 수 있습니다. [Nostr — NIP-01: Basic protocol]

NIP-19는 사용자 표시용 Bech32를 사용합니다. npub는 공개키, nsec는 비밀키입니다. 인코딩은 암호화가 아닙니다. nsec를 공유하면 단순한 프로필 링크가 아니라 비밀키를 넘깁니다. NIP-01 이벤트와 필터는 npub 표시 대신 16진수 공개키를 사용합니다. [Nostr — NIP-19: Encoded entities]

NIP-05는 도메인 응답을 바탕으로 이메일 같은 이름과 공개키를 연결합니다. 그 연결을 확인할 뿐 실제 신원이나 정직성을 검증하지 않습니다. 클라이언트는 원래 키를 따라야 합니다. 도메인이 이름을 다른 키로 바꿔도 기존에 팔로우한 프로필을 새 키로 자동 대체해서는 안 됩니다. [Nostr — NIP-05: Internet identifiers]

NIP-09는 작성자가 자신의 이벤트 삭제를 요청하는 방식을 정합니다. 숨기기 전에 클라이언트는 원본과 요청의 공개키가 같은지 확인해야 합니다. 릴레이와 클라이언트가 처리할 수 있지만, 프로토콜은 다운로드되거나 따로 보관된 모든 사본을 삭제하지 못합니다. 한 화면에서 삭제됐다고 전 세계에서 지워진 것은 아닙니다. [Nostr — NIP-09: Deletion requests]

NIP-44는 암호화된 payload를 정의하며 완전한 비공개 메시지 시스템은 아닙니다. NIP-17이 포장과 전달 규칙을 더합니다. NIP-44만으로는 나중의 키 유출에 대한 forward secrecy가 제공되지 않습니다. 암호화해도 네트워크 주소, 시간, 클라이언트 동작은 중요합니다. 각 NIP 지원은 앱별로 구분해야 합니다. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]