Nostr 프로토콜이란 무엇입니까? Jack Dorsey는 자금을 지원하지만 Elon Musk는 금지하는 이유는 무엇입니까?

Nostr이라는 이름의 새로운 소셜 프로토콜은 전 Twitter CEO Jack Dorsey와 현 CEO Elon Musk에 의해 매우 다르게 취급되었습니다.

12월 14일 전 Twitter CEO Jack Dorsey는 Twitter 사용자 Koty_Auditore로부터 Nostr에 자금을 지원하라는 추천을 받았습니다. Nostr에 대한 연구 후 Jack Dorsey는 12월 15일 Nostr 개발 자금을 지원하기 위해 14개의 비트코인(약 $245,000) 기부를 발표했습니다.

한편, 트위터는 지난 12월 18일 페이스북, 인스타그램, 트루스소셜, 마스토돈 등 다른 소셜미디어에 대한 링크가 포함된 프로파간다 사용자를 차단한다고 공식 발표했고 노스트가 상장됐다.

노스트르란?

nostr은 "릴레이에 의해 전송되는 메모 및 기타 항목"을 의미합니다.

Nostr의 github에 따르면 Nostr은 검열에 저항하는 글로벌 "소셜" 네트워크를 생성할 수 있는 가장 단순한 개방형 프로토콜입니다. 단번에 네트워크.

Nostr 소셜 네트워크는 트윗과 같은 게시물을 만들고, 누군가를 팔로우하거나 팔로우를 취소하고, 리트윗/재게시할 수 있는 트위터와 매우 유사하게 구축되었습니다. 일반적으로 '포스트'라는 용어는 또는 '참고' nostr 소셜 네트워크에 게시물을 작성하는 것을 지칭하는 데 사용됩니다.

그러나 신뢰할 수 있는 중앙 서버에 의존하지 않으므로 탄력적입니다. 암호화 키와 서명을 기반으로 하므로 조작이 불가능합니다. P2P 기술에 의존하지 않으므로 작동합니다.

Nostr는 어떻게 작동합니까?

• 두 가지 구성 요소가 있습니다.클라이언트 그리고계전기 . 각 사용자는 클라이언트를 실행합니다. 누구나 릴레이를 실행할 수 있습니다.
• 모든 사용자는 공개 키로 식별됩니다. 모든 게시물에 서명이 있습니다. 모든 클라이언트는 이러한 서명의 유효성을 검사합니다.
• 클라이언트는 선택한 릴레이에서 데이터를 가져오고 선택한 다른 릴레이에 데이터를 게시합니다. 릴레이는 다른 릴레이와 대화하지 않고 사용자에게만 직접 전달합니다.
• 예를 들어, "팔로우"하려면 누군가 사용자는 클라이언트에게 해당 공개 키의 게시물에 대해 알고 있는 릴레이를 쿼리하도록 지시합니다.
• 시작할 때 클라이언트는 따르는 모든 사용자에 대해 알고 있는 모든 릴레이의 데이터(예: 마지막 날의 모든 업데이트)를 쿼리한 다음 해당 데이터를 시간순으로 사용자에게 표시합니다.
• "게시물" 모든 종류의 구조화된 데이터를 포함할 수 있지만 가장 많이 사용되는 데이터는 모든 클라이언트와 릴레이가 원활하게 처리할 수 있도록 표준에 포함됩니다.

작동 방식에 대한 간략한 요약

모두가 클라이언트를 실행합니다. 네이티브 클라이언트, 웹 클라이언트 등이 될 수 있습니다. 무언가를 게시하려면 게시물을 작성하고 키로 서명한 다음 여러 릴레이(다른 사람 또는 자신이 호스팅하는 서버)로 보냅니다. 다른 사람들로부터 업데이트를 받으려면 여러 릴레이에 다른 사람들에 대해 아는 것이 있는지 물어봅니다. 누구나 릴레이를 실행할 수 있습니다. 릴레이는 매우 간단하고 멍청합니다. 일부 사람들의 게시물을 수락하고 다른 사람들에게 전달하는 것 외에는 아무 일도 하지 않습니다. 릴레이는 신뢰할 필요가 없습니다. 서명은 클라이언트 측에서 확인됩니다.

노스트가 필요한 이유

다른 솔루션이 손상되었기 때문입니다.

트위터의 문제

• 트위터에는 광고가 있습니다.
• 트위터는 기괴한 기술을 사용하여 중독을 유지합니다.
• Twitter는 귀하가 팔로우하는 사람들의 실제 과거 피드를 표시하지 않습니다.
• 트위터는 사람을 금지합니다.
• 트위터는 사람들을 그림자 금지합니다.
• 트위터에는 스팸이 많습니다.

Mastodon 및 유사 프로그램의 문제

• 사용자 ID는 제3자가 관리하는 도메인 이름에 연결됩니다.
• 서버 소유자는 트위터처럼 차단할 수 있습니다. 서버 소유자는 다른 서버를 차단할 수도 있습니다.
• 서버 간 마이그레이션은 사후 고려 사항이며 서버가 협력하는 경우에만 수행할 수 있습니다. 적대적인 환경에서는 작동하지 않습니다(모든 추종자가 손실됨).
• 서버 운영에 대한 명확한 인센티브가 없기 때문에 매니아와 멋진 도메인에 자신의 이름을 붙이고 싶어하는 사람들이 운영하는 경향이 있습니다. 그런 다음 사용자는 Twitter와 같은 대기업보다 더 나쁜 단일 개인의 전제주의에 종속되어 이주할 수 없습니다.
• 서버는 아마추어처럼 운영되는 경향이 있기 때문에 잠시 후 버려지는 경우가 많습니다. 사실상 모든 사람을 차단하는 것과 같습니다.
• 모든 서버의 업데이트를 수많은 다른 서버로 고통스럽게 푸시(및 저장!)해야 하는 경우 수많은 서버를 보유하는 것은 이치에 맞지 않습니다. 이 점은 서버가 엄청난 수로 존재하는 경향이 있기 때문에 더 많은 데이터를 더 많은 장소로 더 자주 전달해야 한다는 사실로 인해 악화됩니다.
• 비디오 공유의 특정 예에서 ActivityPub 애호가는 텍스트 메모가 있는 방식으로 서버에서 서버로 비디오를 전송하는 것이 완전히 불가능하다는 것을 깨달았기 때문에 비디오가 게시된 단일 인스턴스에서만 비디오를 호스팅하기로 결정했습니다. Nostr 접근 방식과 유사합니다.

SSB(Secure Scuttlebutt)의 문제점

• 많은 문제가 없습니다. 대단하다고 생각합니다. 사실 이것저것 베이스로 쓰려고 했으나
• 개방형 프로토콜에 대해 전혀 생각하지 않았기 때문에 프로토콜이 너무 복잡합니다. 그것은 특정 문제를 해결하기 위한 빠른 방법으로 JavaScript로 작성되었고 그로부터 성장했습니다.ECMA-262 6판 ;
• 그것은 나에게 불필요하다고 느끼는 단일 사용자의 업데이트 체인을 가지고 있다고 주장하고 부풀어 오르고 경직성을 더하는 것입니다. 각 서버 / 사용자는 새 게시물이 유효한지 확인하기 위해 모든 게시물 체인을 저장해야합니다. 왜요? (아마도 그럴 만한 이유가 있을 것입니다.)
• 그것은 주로 P2P 동기화를 위해 만들어졌기 때문에 Nostr만큼 간단하지 않습니다. 나중에 생각하는 것;
• 그럼에도 불구하고 이 사용자 정의 프로토콜 대신 SSB를 사용하고 이를 클라이언트-릴레이 서버 모델에 적용하는 것을 고려해 볼 가치가 있습니다. 표준을 재사용하는 것이 사람들을 새 프로토콜로 끌어들이는 것보다 항상 낫기 때문입니다.

모든 사람이 자신의 서버를 실행해야 하는 다른 솔루션의 문제

• 모든 사람이 자신의 서버를 실행해야 합니다.
• 때때로 도메인 이름이 검열될 수 있기 때문에 사람들은 여전히 검열될 수 있습니다.