NIP-65는 사용자가 읽기와 쓰기에 선호하는 릴레이를 광고하는 kind 10002 이벤트를 정의합니다. 이 메타데이터는 다른 사용자와 클라이언트가 분산 릴레이 네트워크 전체에서 당신의 콘텐츠를 찾는 데 도움을 주며, 부하를 분산하고 검열 저항성을 높이는 “outbox 모델"을 가능하게 합니다.

구조

릴레이 목록은 사용자가 광고하고 싶은 각 릴레이에 대한 r 태그를 담은 replaceable 이벤트(kind 10002)입니다. 이 이벤트는 같은 pubkey의 이전 릴레이 목록을 대체합니다.

{
  "id": "a1b2c3d4e5f6...",
  "pubkey": "abcd1234...",
  "created_at": 1736726400,
  "kind": 10002,
  "tags": [
    ["r", "wss://relay.damus.io", "read"],
    ["r", "wss://nos.lol"],
    ["r", "wss://relay.nostr.band", "write"]
  ],
  "content": "",
  "sig": "sig1234..."
}

각 r 태그는 relay WebSocket URL과, 사용자가 그 릴레이와 어떻게 상호작용하는지를 뜻하는 선택적 마커를 담습니다. read 마커는 사용자가 이 릴레이에서 이벤트를 읽는다는 뜻이므로, 다른 사람은 사용자에게 도달하려면 이곳에 게시해야 합니다. write 마커는 사용자가 이 릴레이에 게시한다는 뜻이므로, 다른 사람은 사용자의 콘텐츠를 보려면 이곳을 구독해야 합니다. 마커를 생략하면 읽기와 쓰기 둘 다를 뜻합니다.

릴레이 목록 이벤트에서 content 필드는 비어 있습니다.

Outbox 모델

NIP-65는 “outbox 모델"이라 불리는 분산 콘텐츠 배포 패턴을 가능하게 합니다. 모두가 같은 중앙 릴레이에서 읽고 쓰는 대신, 사용자는 자신이 선호하는 릴레이에 게시하고, 클라이언트는 각 사용자의 콘텐츠가 어디에 있는지 동적으로 발견합니다.

Alice가 Bob의 게시물을 찾고 싶을 때, 그녀의 클라이언트는 먼저 Bob의 kind 10002 이벤트를 그 이벤트를 가진 아무 릴레이에서나 가져옵니다. 그런 다음 Bob이 write로 표시한 릴레이를 추출합니다. Bob이 실제로 게시하는 곳이기 때문입니다. Alice의 클라이언트는 Bob의 이벤트를 찾기 위해 그 릴레이들을 구독합니다. Alice가 Bob에게 DM을 보내고 싶을 때는 반대로 Bob의 read 릴레이를 찾고 그곳에 메시지를 게시합니다.

outbox 모델을 따르는 클라이언트는 팔로우하는 사용자의 NIP-65 이벤트에 나온 릴레이들과의 연결을 유지합니다. 새 계정을 발견할수록 새 릴레이에도 동적으로 연결합니다. 여러 팔로우 사용자의 목록에 공통으로 들어 있는 릴레이는 더 우선시되는데, 그 릴레이 하나에 연결하는 것만으로도 사용자의 소셜 그래프 더 많은 부분을 처리할 수 있기 때문입니다.

이 아키텍처는 어떤 단일 릴레이도 모든 사람의 콘텐츠를 저장하거나 제공할 필요가 없게 하므로 검열 저항성을 높입니다. 릴레이 하나가 오프라인이 되거나 특정 사용자를 차단하더라도, 그 사용자의 콘텐츠는 목록에 있는 다른 릴레이에서 계속 제공될 수 있습니다.

왜 중요한가

NIP-65는 릴레이 선택을 하드코딩된 클라이언트 기본값에서, 사용자가 게시한 라우팅 메타데이터로 바꿉니다. 덕분에 클라이언트는 모두가 같은 릴레이 집합을 쓴다고 가정하는 대신, 각 계정의 실제 게시 및 읽기 습관에 맞춰 적응할 수 있습니다.

대신 복잡성은 클라이언트 쪽으로 이동합니다. outbox 모델을 잘 사용하려면 클라이언트에 relay caching, retry 로직, 그리고 relay 목록이 없거나 오래되었을 때의 fallback 동작이 필요합니다. 이 명세는 discoverability를 개선하지만, 좋은 relay 선택 휴리스틱의 필요를 없애지는 않습니다.

릴레이 힌트와의 관계

NIP-65는 다른 NIP 전반에 흩어져 있는 relay hint를 보완합니다. 누군가를 [["p", "pubkey", "wss://hint.relay"]]로 태그할 때, 그 hint는 클라이언트에게 해당 특정 참조를 어디서 찾을지 알려 줍니다. NIP-65는 사용자가 통제하는 권위 있는 선호 relay 목록을 제공하고, hint는 더 빠른 발견을 위해 개별 이벤트 안에 박힌 지름길 역할을 합니다.

비공개 메시징에서는 NIP-65만으로 충분하지 않습니다. 공개 콘텐츠 라우팅은 kind 10002를 쓰지만, 현대의 비공개 메시징 스택은 종종 NIP-17 relay 목록 같은 별도의 inbox 메타데이터에 의존해 DM 라우팅을 공개 게시용 relay와 분리합니다.

모범 사례

relay 목록을 최신 상태로 유지해야 합니다. 더 이상 동작하지 않는 relay를 가리키는 오래된 항목은 다른 사람이 당신을 찾기 어렵게 만듭니다. 중복성을 위해 최소 두세 개 relay를 포함해, 하나가 오프라인이 되어도 다른 relay를 통해 콘텐츠를 계속 볼 수 있도록 해야 합니다.

너무 많은 relay를 나열하는 것은 피하는 편이 좋습니다. 열 개, 열다섯 개 relay를 나열하면, 당신의 콘텐츠를 가져오려는 모든 클라이언트가 그 모두에 연결해야 하므로 경험이 느려지고 네트워크 전반의 부하도 커집니다. 잘 고른 세 개에서 다섯 개 정도 relay가, 모두에게 부담을 주는 과한 목록보다 낫습니다.

범용 relay와 특화 relay를 섞어 쓰는 것이 좋습니다. 예를 들어 wss://relay.damus.io 같은 인기 범용 relay, 당신의 지역에 특화된 relay, 그리고 당신이 참여하는 특정 커뮤니티용 relay를 함께 적을 수 있습니다.

주요 출처:

언급된 뉴스레터:

같이 보기: