Bitsocial과 Nostr
Nostr는 연합 범주에도 블록체인 범주에도 깔끔하게 들어맞지 않습니다. 사용자는 인스턴스에서 계정을 발급받지 않으며, 체인도, 합의도, 가스도, 전역 순서도 없습니다. Nostr는 릴레이 기반 소셜 미디어라고 부르는 편이 더 정확합니다. 사용자는 키페어를 보유하고, 이벤트에 서명해 릴레이에 발행하며, 릴레이는 그 이벤트를 저장하고 제공하는 평범한 서버입니다(NIP-01). Nostr의 README도 Nostr가 P2P 기법에 의존하지 않는다고 밝힙니다.
그래서 Nostr는 한 가지 중요한 측면에서 연합 시스템이나 블록체인 시스템보다 Bitsocial에 가깝습니다. 신원이 암호학적이고 이동 가능하다는 점입니다. 차이는 데이터 계층, 그리고 누가 관문을 쥐고 있느냐에 있습니다.
Nostr의 동작 방식
- 이벤트와 릴레이. 모든 게시물, 프로필, 반응은 서명된 JSON 이벤트입니다. 클라이언트는 WebSocket으로 릴레이에 이벤트를 발행하고 필터를 걸어 구독하며, 릴레이는 이벤트를 저장했다가 돌려줍니다. 릴레이끼리는 서로 통신하지 않습니다.
- 복제. 사용자는 보통 여러 릴레이에 발행합니다. 2023년에 릴레이 712개를 조사한 연구에 따르면 평균적인 게시물은 그중 34.6개 릴레이에 있었습니다(Wei와 Tyson).
- 누군가의 게시물 찾기. 사용자는 자신이 쓰고 읽는 릴레이 목록을 발행하고(NIP-65), 클라이언트는 해당 사용자의 쓰기 릴레이에서 그 사용자의 게시물을 가져옵니다.
- 신원. 각 사용자는 하나의 secp256k1 키이며 Schnorr 서명으로 서명합니다. 명세에는 키 교체나
복구가 정의되어 있지 않으므로 키를 잃으면 계정도 잃습니다. 선택 사항인
name@domain식별자(NIP-05)는 해당 도메인의 웹 서버에 있는 파일과 대조해 확인합니다. - 그룹. 권장되는 커뮤니티 메커니즘은 릴레이 기반 그룹(NIP-29)입니다. 릴레이가 그룹을 호스팅하고, 게시물을 받아들이기 전에 그룹의 멤버십 규칙과 게시 규칙을 적용하며, 그룹 메타데이터에 서명합니다. 이전의 모더레이터 승인 커뮤니티(NIP-72)는 이제 NIP-29를 우선하여 비권장으로 표시되어 있습니다.
- 스팸 방지. 관문은 릴레이마다 직접 고릅니다. 작업 증명(NIP-13), 인증과 허용 목록(NIP-42), 결제, 속도 제한 등이 있습니다. 클라이언트는 여기에 뮤트 목록과 신뢰 점수를 더합니다.
- 미디어. 이미지와 동영상은 별도의 HTTP 파일 서버에 업로드됩니다.
차이점
누가 게시물을 저장하고 제공하는가
Nostr에서는 릴레이가 저장·전달 계층입니다. 서버가 각 게시물을 계속 온라인 상태로 유지해야 합니다. Bitsocial에서 HTTP 라우터는 클라이언트가 피어를 찾도록 돕기만 합니다. 라우터는 게시물, 프로필, 커뮤니티 메타데이터, 모더레이션 상태를 저장하지 않으며, 클라이언트는 커뮤니티의 노드와 그 커뮤니티를 시드하는 피어에서 콘텐츠를 가져옵니다. P2P 프로토콜을 참고하세요.
누가 관문을 쥐고 있는가
Nostr에서 쓰기 관문은 릴레이 운영자의 몫입니다. NIP-29 그룹이 아니라면, 한 릴레이에서 거부된 키도 받아 주는 다른 아무 릴레이에나 같은 이벤트를 발행할 수 있고, 독자에게 무엇이 보이는지는 그 독자의 클라이언트가 어떤 릴레이를 읽느냐에 달려 있습니다. NIP-29 그룹은 Bitsocial 커뮤니티에 더 가깝습니다. 그룹을 호스팅하는 릴레이가 게시물을 수락하거나 거부합니다. 그래도 그룹 역할이 무엇을 할 수 있는지는 여전히 릴레이가 정하며, 다른 릴레이가 넘겨받기로 동의하지 않는 한 그룹의 기록은 그 릴레이에 묶여 있습니다.
Bitsocial에서 커뮤니티는 자체 키페어를 가진 암호학적 객체입니다. 커뮤니티의 노드는 소유자가 고른 챌린지를 무엇이든 실행하고, 승인된 상태를 P2P 네트워크에 발행합니다. 맞춤형 스팸 방지 챌린지를 참고하세요.
인프라 운영
릴레이는 도메인과 WebSocket 엔드포인트를 갖춘 서버이며, 인기 있는 릴레이는 자신이 제공하는 데이터의 저장 비용과 대역폭 비용을 떠안습니다. 앞의 2023년 연구는 무료 릴레이의 약 95%가 기부금으로 비용을 감당하지 못한다고 추정했습니다. Bitsocial 커뮤니티 노드는 일반 소비자용 하드웨어에서 돌아가고, 커뮤니티를 읽는 피어가 그 공유를 도울 수 있습니다.
브라우저
Nostr 웹 클라이언트는 릴레이에 WebSocket 연결을 직접 열기 때문에 앱 서버가 필요 없습니다. Bitsocial 웹 앱은 탭 안에서 P2P 노드를 실행하고 피어에서 콘텐츠를 가져옵니다. 브라우저 피어 투 피어를 참고하세요.
오래된 콘텐츠
Nostr 게시물은 여러 릴레이에 널리 복제되므로 오래된 게시물이 살아남기 쉽습니다. Bitsocial은 커뮤니티의 최신 상태를 유지하며, 오래된 콘텐츠가 영구히 남는다고 보장하지 않습니다.
비교
| 질문 | Nostr | Bitsocial |
|---|---|---|
| 분류 | 릴레이 기반 프로토콜 | P2P 커뮤니티 네트워크 |
| 신원 | secp256k1 사용자 키, 명세상 키 교체 없음 | 사용자와 커뮤니티를 위한 Ed25519 키페어 |
| 게시물 저장 위치 | 작성자가 고른 릴레이, 흔히 여러 곳 | 커뮤니티 소유자의 노드와, 그 커뮤니티를 읽고 시드하는 피어 |
| 온라인 유지 주체 | 릴레이 운영자 | 커뮤니티 소유자 노드와 보조 시더 |
| 커뮤니티 | 릴레이가 호스팅하는 그룹(NIP-29) | 자체 노드가 게시물을 수락하거나 거부하는 일급 객체 |
| 스팸 방지 | 릴레이별 정책: 작업 증명, 인증, 결제, 허용 목록, 속도 제한 | 게시물이 받아들여지기 전에 거치는 커뮤니티별 챌린지 |
| 모더레이션 | 릴레이 정책, 클라이언트 뮤트 목록, 라벨과 신고 | 커뮤니티 소유자가 자기 커뮤니티를 모더레이션하고, 무엇을 보여줄지는 앱이 선택 |
| 이름 | HTTPS로 확인하는 선택적 name@domain 식별자 | 키로 해석되는 .bso 및 .eth 이름 |
| 브라우저 | 릴레이의 WebSocket 클라이언트 | 일반 브라우저 탭 안에서 동작하는 P2P 노드 |
| 주요 절충 | 이동 가능한 신원과 폭넓은 복제, 그러나 릴레이에 좌우되는 가용성과 정책 | 릴레이 의존은 적지만 오래된 콘텐츠가 영구히 보장되지는 않음 |