Nostr

안나는 Nostr에서 팔로우하고 싶은 작성자를 찾습니다. 나중에는 쓰던 앱이 마음에 들지 않게 됩니다. 다른 앱에서 같은 개인키나 연결된 서명 장치를 안전하게 사용하면 기존 정체성을 유지할 수 있습니다. 공개키는 다른 사람이 안나를 알아보고 서명을 검증하게 하며, 개인키는 안나의 이름으로 서명하게 합니다. 그래서 npub와 nsec의 차이가 중요합니다. NIP-19에 따르면 각각 공개키와 개인키를 Bech32로 인코딩한 표현입니다. NIP는 Nostr의 규칙과 확장을 설명하는 번호가 붙은 문서입니다. 인코딩은 암호화가 아닙니다. nsec는 누구에게나 건네도 되는 평범한 프로필 링크가 아닙니다. 같은 정체성을 유지한다고 새 앱이 모든 예전 게시물을 찾거나 모든 설정을 가져온다고 보장되는 것도 아닙니다. [2] [7]

클라이언트라고 부르는 앱이 게시물에 서명한 뒤 선택한 릴레이로 보냅니다. 릴레이는 메시지를 받아 자체 규칙에 따라 저장하거나 전달하는 서버입니다. 페트르의 앱은 릴레이에 접속해 관심 있는 게시물을 요청합니다. 유일한 중앙 서버도 없고, 모든 서버가 모든 내용을 복제할 의무도 없습니다. 기술적으로는 연결을 계속 열어 두는 WebSocket을 사용합니다. EVENT는 메시지를 운반하고, REQ는 구독을 시작하며, OK는 수락이나 거부를 알립니다. 긍정적인 OK도 페트르에게 도착했다거나 영구 저장된다는 확인은 아닙니다. EOSE는 해당 요청의 저장된 결과를 모두 보냈다는 뜻이며, 이후에도 구독으로 새 메시지를 받을 수 있습니다. [1] [7]

페트르가 메시지를 받으면 앱은 서명이 명시된 공개키와 맞는지, 서명된 데이터가 바뀌지 않았는지 확인합니다. 이것이 메시지가 사실이라는 증거나 작성자의 실제 신원 확인은 아닙니다. 작성 시각도 작성자가 정하므로 독립적인 타임스탬프가 아닙니다. 기술을 더 알고 싶다면 event라는 기록을 보면 됩니다. pubkey, created_at, kind, tags, content는 각각 키, 시각, 종류, 태그, 내용을 담습니다. 엄밀하게 정해진 형식으로 나열한 데이터에서 SHA-256이 id라는 짧은 확인용 값을 만듭니다. 이를 통해 서명된 데이터의 변경을 알아낼 수 있습니다. sig 필드에는 BIP340에 따라 secp256k1 곡선을 사용하는 Schnorr Signature, 즉 슈노르 서명이 들어갑니다. 뜻은 “해당 키의 소유자가 이 데이터에 서명했다”이지 “이 주장을 믿어도 된다”가 아닙니다. [1]

긴 공개키는 외우기 어렵습니다. NIP-05는 이를 이메일 주소처럼 생긴 식별자와 연결할 수 있게 합니다. 앱은 해당 도메인에 이름과 연결된 키를 묻고 프로필의 키와 비교합니다. 검증하는 것은 그 도메인과의 구체적인 연결이며, 실제 이름이나 평판, 신뢰성을 자동으로 확인하는 것은 아닙니다. 도메인 운영자는 나중에 연결을 바꿀 수 있습니다. 안나가 이미 누군가를 팔로우한다면 원래 공개키가 기준으로 남아야 합니다. 같은 이름에 새 키를 연결했다고 팔로우하는 사람이 몰래 바뀌어서는 안 됩니다. 가명성은 실명 대신 지속적인 식별자를 쓰는 것이지 익명성의 보장은 아닙니다. [3]

페트르는 모든 메시지를 내려받을 필요가 없습니다. 특정 작성자의 특정 종류 게시물 같은 필터를 보낼 수 있습니다. 한 필터 안의 서로 다른 조건은 AND로 연결되어 모두 충족해야 합니다. 같은 조건에서 허용한 여러 값은 OR로 연결된 선택지이며, 하나의 REQ 안에 있는 여러 필터도 OR 관계입니다. 그중 하나의 필터만 충족해도 됩니다. limit는 처음 보내는 저장된 결과의 수를 제한할 뿐, 이후 구독 메시지까지 자동으로 제한하지 않습니다. NIP-01은 이벤트와 필터에서 사용자용 npub 대신 키의 십육진수 표현을 씁니다. 검색 결과가 비어 있다면 필터, 선택한 서버, 서버의 기록 때문일 수 있습니다. 게시물이 어디에도 없다는 증거는 아닙니다. [1]

안나는 프로필 설명을 바꾸고 사람들이 새 설명을 보기를 바랍니다. 그래서 Nostr는 릴레이가 무엇을 보관해야 하는지 구분합니다. 교체 가능한 이벤트에서는 같은 pubkey와 kind 쌍의 최신 기록을 고릅니다. 주소 지정 가능한 이벤트는 d 태그의 값도 사용해 같은 작성자의 서로 다른 문서 등을 구별합니다. 교체 가능한 기록의 시각이 같으면 사전식 순서로 더 작은 id, 즉 표기를 정렬했을 때 먼저 나오는 것을 남기도록 권장합니다. 임시 이벤트인 ephemeral은 애초에 저장을 전제로 하지 않습니다. 이는 관례이며 릴레이의 실제 동작은 다를 수 있습니다. 따라서 Nostr는 전체 네트워크가 하나의 불변 이력에 합의하는 장부가 아닙니다. [1]

안나는 비공개로 두려던 내용을 올렸다는 사실을 깨닫습니다. NIP-09를 통해 서명된 삭제 요청을 보낼 수 있습니다. 클라이언트는 실행 전에 요청과 원본 게시물이 같은 공개키에 속하는지 확인해야 합니다. 다른 사람이 안나의 게시물을 가리키기만 해도 삭제할 수 있어서는 안 되기 때문입니다. 협조하는 서버와 앱은 내용을 지우거나 표시를 중단할 수 있습니다. 그러나 요청으로 모든 사본, 화면 캡처, 독립적인 보관 기록을 없앨 수는 없습니다. 한 앱에서 숨겼다고 다른 서버도 더는 제공하지 않는다는 뜻은 아닙니다. 삭제 버튼이 있는지보다 무엇을 게시하는지가 중요합니다. [4]

공개 게시물은 얻은 사람 누구나 읽을 수 있으며, 서명만으로 내용이 숨겨지지는 않습니다. 개인 메시지는 추가 규칙을 사용합니다. NIP-44는 내용 암호화를, NIP-17은 보호 계층을 더해 메시지를 감싸고 전달하는 방식을 설명합니다. 그렇다고 자동으로 익명성이 확보되지는 않습니다. 네트워크 주소, 시각, 앱의 동작이 여전히 정보를 드러낼 수 있습니다. 이 암호화에는 forward secrecy, 즉 장기 키가 나중에 유출되어도 과거 대화를 보호하는 성질도 없습니다. 필요한 개인키와 이전에 기록된 암호문을 확보한 사람은 과거 메시지도 읽을 수 있습니다. 해당 앱이 실제로 어떤 확장을 지원하는지 확인해야 합니다. “Nostr”라는 이름만으로 개인정보 보호 수준을 알 수는 없습니다. [5] [6]