NIP-62는 vanish 요청을 정의한다. 사용자가 릴레이에 자신의 콘텐츠 삭제를 요청하는 메커니즘이다. 릴레이가 이 요청을 이행할 의무는 없지만, NIP-62를 지원하면 사용자에게 발행된 데이터에 대한 더 많은 통제권을 부여하고 네트워크 전반에 걸쳐 삭제 의사를 전달하는 표준화된 방법을 제공한다.

작동 방식

Vanish 요청은 콘텐츠 제거를 원하는 사용자가 서명한 kind 62 이벤트다. 요청은 e 태그에 이벤트 ID를 포함하여 특정 이벤트를 대상으로 하거나, e 태그를 완전히 생략하여 해당 공개키의 모든 콘텐츠 삭제를 요청할 수 있다.

{
  "id": "a1b2c3d4e5f6...",
  "pubkey": "abcd1234...",
  "created_at": 1736726400,
  "kind": 62,
  "tags": [
    ["e", "event1234...", "wss://relay.example.com"],
    ["e", "event5678...", "wss://relay.example.com"]
  ],
  "content": "Removing old posts",
  "sig": "sig1234..."
}

content 필드는 선택적으로 삭제 요청에 대한 사람이 읽을 수 있는 사유를 담는다. e 태그의 릴레이 힌트는 원본 이벤트가 발행된 위치를 릴레이에 알려주지만, 릴레이는 지정된 이벤트 보유 여부와 관계없이 요청을 이행할 수 있다.

릴레이 동작

NIP-62를 지원하는 릴레이는 지정된 이벤트를 스토리지에서 삭제하고 구독자에게 제공하는 것을 중단해야 한다. Vanish 요청 자체는 삭제가 요청되었다는 기록으로 보존될 수 있으며, 이는 삭제된 이벤트가 다른 릴레이에서 재수입되는 것을 방지하는 데 도움이 된다.

Vanish 요청이 모든 e 태그를 생략하면 릴레이는 이를 해당 공개키의 모든 이벤트 제거 요청으로 해석한다. 이는 더 급진적인 조치이며 릴레이마다 다르게 처리할 수 있다. 예를 들어 해당 공개키를 “vanished"로 표시하고 향후 해당 이벤트의 수락이나 제공을 거부할 수 있다.

릴레이가 NIP-62를 지원할 의무는 없다. Nostr 네트워크는 탈중앙화되어 있으며, 각 릴레이 운영자가 자체 데이터 보존 정책을 결정한다. 사용자는 vanish 요청을 발행했다고 해서 모든 곳에서 콘텐츠가 삭제될 것이라고 가정해서는 안 된다.

왜 중요한가

NIP-62는 클라이언트와 릴레이 운영자에게 임시 모더레이션 API나 릴레이별 대시보드를 넘어서는 공유 삭제 신호를 제공한다. 사용자가 하나의 서명된 요청을 발행하면 각 릴레이가 처리 방식을 결정할 수 있다.

실질적 한계는 범위다. Vanish 요청은 해당 요청을 수신하고, 지원하며, 이행하기로 선택한 릴레이에만 영향을 미친다. 스크린샷, 로컬 데이터베이스, 제3자 아카이브, 또는 릴레이 통제 범위 밖의 이미 리포스트된 사본은 철회하지 못한다.

프라이버시 고려사항

Vanish 요청은 최선 노력 삭제 메커니즘이지 프라이버시 보장이 아니다. Vanish 요청을 발행한 후에도 콘텐츠 사본이 네트워크의 다른 곳에 존재할 수 있다. NIP-62를 지원하지 않는 다른 릴레이, 클라이언트 기기의 로컬 캐시, 제3자 아카이브나 검색 엔진, 백업 등이 해당된다.

요청 자체도 서명된 Nostr 이벤트이므로 공개 기록의 일부가 된다. Vanish 요청을 본 사람은 무엇이 삭제되었는지는 알 수 없더라도 무언가를 삭제했다는 사실은 알 수 있다.

반드시 비공개로 유지해야 하는 콘텐츠의 경우, 사후 삭제에 의존하기보다 NIP-17과 같은 암호화 메시징 사용을 고려해야 한다.

상호운용성 참고사항

NIP-62는 NIP-09를 보완한다. NIP-09는 Nostr 전반에서 사용되는 일반 삭제 요청 이벤트이고, NIP-62는 릴레이에 특정 이벤트 또는 전체 공개키의 콘텐츠 세트를 대상으로 할 수 있는 더 강력한 vanish 지향 신호를 제공한다. 구현체는 두 가지 모두를 지원할 수 있으며, rust-nostr의 데이터베이스 백엔드는 해당 적용 경계에 대한 설정을 공개하고 있다.

주요 출처:

언급된 뉴스레터:

같이 보기: