Các thiết kế mạng xã hội mới dưới Quyền thứ năm đã được khám phá trong nhiều năm mà không có dấu hiệu được áp dụng đại trà. Trong năm qua, với sự phát triển không ngừng của công nghệ mã hóa và những lo ngại về việc mua lại Twitter của Musk, mạng xã hội phi tập trung đã mở ra những cơ hội mới.

Các vấn đề mà các mạng xã hội này đang cố gắng giải quyết: có thể bao gồm tăng cường kiểm duyệt, kiểm duyệt nội dung linh hoạt hơn và giảm quyền hạn của các công ty truyền thông xã hội lớn trong việc định hình và theo dõi những gì mọi người nói về trực tuyến, trong số những thứ khác.

Khi các nền tảng mới xuất hiện và phát triển, việc lựa chọn các mạng xã hội thay thế thường đi kèm với những cân nhắc chính trị.

Các trang web như Getr, Parler, Gab và Truth Social đều phục vụ cho quyền bằng cách tự quảng cáo mình là lựa chọn thay thế tự do ngôn luận cho Twitter.

Những gì chúng ta sẽ thảo luận hôm nay là Nostr-Damus, một giao thức truyền thông xã hội mới đã nhận được rất nhiều sự chú ý gần đây và có phần đổi mới. Chúng bao gồm cơ sở kỹ thuật cho Nostr, các vấn đề quản lý chính cần được giải quyết và cách khuyến khích rơle tiếp tục hoạt động.

Bối cảnh: Nostr

Ra mắt vào năm 2020, Nostr là một giao thức phi tập trung cho phép người dùng sở hữu danh tính của họ và xác minh các bài đăng bằng chữ ký số bằng cách sử dụng mã hóa khóa công khai. Những bài đăng này sau đó được truyền đến một mạng máy chủ được kết nối với nhau. Giao thức không sử dụng chuỗi khối, vốn được phát hiện trong các thử nghiệm ban đầu là quá chậm đối với các mạng xã hội. Nhưng có những điểm tương đồng về cấu trúc và Nostr đã sớm tìm thấy một vị trí thích hợp trong đám đông tiền điện tử với các đặc tính nguồn mở và tự do của nó.

Mastodon VS Nostr 

Giao thức Nostr và máy chủ chuyển tiếp đầu tiên được tạo bởi nhà phát triển fiatjaf vào cuối năm 2020. Trước khi được chú ý rộng rãi, Nostr là một giao thức thích hợp yên tĩnh nhằm mục đích trở thành một giải pháp nhẹ cho các vấn đề của Twitter và Mastodon.

Mastodon, một mạng nguồn mở được thành lập vào năm 2016, cho phép mọi người thiết lập máy chủ. Thiết kế thường được mô tả là "liên kết" và có thể nằm trong hoặc không nằm trong dòng mờ của "Web3", tùy thuộc vào cách xác định điều đó. Mastodon cho phép người dùng tham gia các cộng đồng được quản lý với các quy tắc kiểm duyệt nội dung tùy chỉnh. Hiện tại, số người dùng đã đăng ký đã lên tới 200 w+ và nó đã trở thành nơi trú ẩn an toàn cho những người theo chủ nghĩa tự do, nhà báo và học giả.

Trong hệ thống Twitter và Mastodon, danh tính/tên người dùng được kiểm soát bởi người điều hành máy chủ.

Điểm khác biệt cốt lõi với Nostr là mỗi người dùng sử dụng một cặp khóa công khai/riêng tư để xử lý chức năng, thay vì sử dụng tên người dùng do nhà điều hành máy chủ sở hữu, giúp Nostr chống lại sự kiểm duyệt. Đây là một trong những khối xây dựng cốt lõi để xây dựng toàn bộ giao thức Nostr.

"Sự kiện": Đây là đối tượng/kiểu dữ liệu cơ bản được sử dụng bởi máy khách và máy chủ chuyển tiếp mà máy khách kết nối để gửi và truy xuất tin nhắn. Ý tưởng chung của giao thức là các máy khách gửi các sự kiện đến một máy chủ chuyển tiếp, sau đó máy chủ này sẽ lưu trữ và lập chỉ mục cho chúng và các máy khách khác có thể giao tiếp với máy chủ chuyển tiếp để yêu cầu các sự kiện mà chúng đã nhận và lưu trữ. Trong NIP 01 ban đầu, ba loại sự kiện khác nhau đã được xác định:

0 : Gửi siêu dữ liệu về người dùng, chẳng hạn như tên người dùng, ảnh, tiểu sử, v.v.

1: Gửi SMS và nội dung cơ bản

2: Đề xuất máy chủ chuyển tiếp để những người theo dõi người tạo sự kiện kết nối

Tất cả các sự kiện được cấu trúc theo một cách xác định cụ thể. Bao gồm khóa chung của người tạo, dấu thời gian tạo, loại (hoặc loại trong thông số kỹ thuật), tải trọng nội dung và chữ ký của người tạo sự kiện. Ngoài ra, có thể có các thẻ đề cập đến các sự kiện hoặc người dùng khác và có giá trị ID là hàm băm của mọi thứ ngoại trừ chữ ký của người tạo (tương tự như TXID của giao dịch Bitcoin).

Điều này cho phép người dùng xác minh chữ ký (và ai sở hữu khóa, nếu nó chưa bị xâm phạm) để đảm bảo rằng thư thực sự được tạo bởi chủ sở hữu khóa công khai trong đó và thư không bị thay đổi kể từ khi họ Ký nó.

Giống như giao dịch Bitcoin không thể thay đổi sau khi được ký mà không làm mất hiệu lực giao dịch, người dùng không thể thay đổi sự kiện Nostr sau khi nó đã được ký bởi người tạo ra nó mà không coi đó là hành vi gian lận rõ ràng.

Hệ thống loại sự kiện đã được mở rộng đáng kể so với NIP ban đầu. Có một loại sự kiện dành cho tin nhắn trực tiếp được mã hóa tạo bí mật chung bằng cách kết hợp khóa riêng của người gửi với khóa chung của người nhận, kết quả của sự kiện này giống với những gì bạn nhận được bằng cách kết hợp khóa chung của người gửi với khóa riêng của người nhận. giống nhau (đây là cách hoạt động của BIP 47 và thanh toán ngầm). Ngoài ra còn có các loại sự kiện có thể thay thế và sự kiện phù du. Trong trường hợp các sự kiện có thể thay thế (rõ ràng), chúng được thiết kế sao cho người tạo ban đầu của sự kiện có thể ký một sự kiện mới để thay thế sự kiện cũ. Các máy chủ chuyển tiếp tuân theo thông số kỹ thuật này sẽ tự động xóa các sự kiện cũ khỏi bộ lưu trữ của chúng và bắt đầu cung cấp các phiên bản mới hơn cho khách hàng khi nhận được. Các sự kiện tạm thời được thiết kế theo cách mà khi được gửi đến một rơle, chúng sẽ được phát cho bất kỳ ai đăng ký với người tạo ra chúng, nhưng máy chủ chuyển tiếp sẽ không lưu trữ chúng. Điều này tạo ra khả năng chỉ những người đang trực tuyến mới nhìn thấy tin nhắn trong quá trình phát sóng. Thậm chí còn có một loại sự kiện để thể hiện phản ứng đối với các sự kiện của người khác (chẳng hạn như lượt thích hoặc biểu tượng cảm xúc).

Nói về câu hỏi cuối cùng, các sự kiện cũng có thể chứa các thẻ. Hiện tại có các loại thẻ cho Sự kiện (để chỉ một sự kiện Nostr chính xác), Khóa công khai (để gắn thẻ hoặc đề cập đến người dùng khác) và Chủ đề (để bắt chước chức năng, chẳng hạn như chủ đề email). Tất cả những thứ này có thể bao gồm các con trỏ tới máy chủ chuyển tiếp cụ thể mà từ đó dữ liệu có thể được tìm nạp để người dùng thực sự có thể tương tác trên các máy chủ khác nhau, tức là người dùng đăng nội dung của họ trên máy chủ chuyển tiếp Nội dung mà người dùng khác có thể tương tác và tham chiếu trên một máy chủ khác máy chủ chuyển tiếp, để bất kỳ người dùng nào cũng có thể nhận được toàn bộ chuỗi tương tác một cách mạch lạc theo đúng thứ tự mà không cần phải tìm xem dữ liệu liên quan ở đâu. Một số lượng lớn các hoạt động phức tạp.

Trong NIP ban đầu, một thông số kỹ thuật đã được đưa ra về cách máy khách tương tác với máy chủ chuyển tiếp bằng cách đăng ký cấu trúc thông báo/dữ liệu bao gồm các bộ lọc cho những sự kiện mà máy khách muốn nhận. Các bộ lọc này có thể chỉ định khóa chung của người dùng, sự kiện chính xác, loại sự kiện hoặc thậm chí là khung thời gian cụ thể mà họ muốn dựa trên các tiêu chí trước đó. Người dùng thậm chí có thể gửi khóa công khai hoặc tiền tố của ID sự kiện, chẳng hạn như "1 xjisj...". và nhận bất kỳ một hoặc nhiều sự kiện nào từ khóa chung bắt đầu bằng chuỗi ngắn đó (điều này hữu ích để ẩn khỏi máy chủ chuyển tiếp những gì bạn thực sự muốn xem).

Nhìn chung, giao thức là một sơ đồ chung rất đơn giản để truyền tin nhắn giữa những người dùng, bao gồm những điều quan trọng như đảm bảo tính toàn vẹn của tin nhắn và sử dụng danh tính khóa chung để gửi tin nhắn, đồng thời tạo điều kiện cho các máy chủ chuyển tiếp cơ sở hạ tầng cuối có thể được tập trung cao độ hoặc cho phép người dùng chạy các máy chủ chuyển tiếp cá nhân của riêng họ trong khi tương tác liền mạch với nhau và không gây ra sự hỗn loạn lớn trong trường hợp người dùng bị cấm sử dụng một máy chủ chuyển tiếp. Họ có thể chuyển sang máy chủ khác hoặc chạy máy chủ của riêng mình và họ sẽ không mất danh tính kỹ thuật số hoặc người theo dõi bằng cách ngắt nền tảng khỏi máy chủ trước đó, vì họ vẫn duy trì quyền kiểm soát khóa riêng tư của mình và người dùng có thể sử dụng nó ở nơi khác Xác thực họ khi bạn tìm thấy chúng.

Các máy chủ chuyển tiếp cũng có thể chạy bất cứ thứ gì họ muốn: vận hành miễn phí, tính một khoản phí nhỏ để xuất bản hoặc tải xuống tin nhắn và thậm chí còn có một NIP yêu cầu bằng chứng công việc kiểu hashcash để gửi tin nhắn. Chúng có thể là một máy chủ chuyển tiếp duy nhất lưu trữ các bài đăng và chỉ cung cấp chúng cho những người dùng khác hoặc một máy chủ hoạt động trên quy mô lớn, chẳng hạn như Twitter hoặc Reddit (máy khách có thể hiển thị và sắp xếp thông tin theo ý muốn, cho phép mô phỏng bất kỳ phương tiện truyền thông xã hội nào). Tất cả những thứ này tương tác liền mạch mà không khóa người dùng.

Các vấn đề quản lý chính cần được giải quyết bởi Nostr

Khóa công khai/riêng tư của người dùng là một phần không thể thiếu trong cách Nostr hoạt động như một giao thức. Điều này hoạt động như một mối ràng buộc chặt chẽ giữa người dùng thực tế và cách những người khác nhận dạng họ, ngăn không cho bất kỳ máy chủ chuyển tiếp nào gỡ bỏ hai điều đó, tức là cung cấp số nhận dạng của ai đó cho người dùng khác. Nó cũng giải quyết một trong những vấn đề lớn nhất với nền tảng: thiếu kiểm soát danh tính của chính người dùng.

Nhưng điều này cũng đưa ra các vấn đề mới: chìa khóa có thể bị mất, chìa khóa có thể bị xâm phạm và nếu sự kiện như vậy xảy ra, người dùng sẽ không thể gọi trợ giúp.

Điều này chắc chắn sẽ yêu cầu một sơ đồ để người dùng chuyển từ cặp khóa này sang cặp khóa khác theo cách có thể xác minh và khám phá, đồng thời để họ tương tác với những người dùng khác thông qua giao thức. Toàn bộ giao thức dựa trên việc chứng minh rằng một sự kiện đến từ một người dùng cụ thể (khóa nhận dạng), do đó, khi khóa của ai đó bị xâm phạm, tất cả những đảm bảo đó sẽ bị ném vào không khí.

Nostr yêu cầu một sơ đồ mật mã thực tế liên kết vòng quay của khóa này với khóa khác. Nhà phát triển fiatjaf đã đề xuất một giải pháp cơ bản có thể giải quyết vấn đề này. Ý tưởng cơ bản là lấy một danh sách dài các địa chỉ bắt nguồn từ một hạt chính duy nhất và tạo một bộ khóa "được điều chỉnh", tương tự như cách cây Taproot được cam kết với khóa Bitcoin. Taproot lấy gốc Merkle của cây Taproot và "thêm" nó vào khóa chung để tạo khóa chung mới. Điều này có thể được sao chép bằng cách thêm gốc Merkle đó vào khóa riêng để lấy khóa riêng khớp với khóa chung mới. Ý tưởng của Fiatjaf là xâu chuỗi các cam kết từ đầu đến cuối, sao cho mỗi khóa được điều chỉnh thực sự chứa bằng chứng rằng khóa được điều chỉnh tiếp theo đã được sử dụng để tạo ra nó.

Vì vậy, hãy tưởng tượng bắt đầu với khóa Z, khóa cuối cùng trong chuỗi. Bạn có thể điều chỉnh nó bằng thứ gì đó, sau đó quay lại và tạo phiên bản đã điều chỉnh của khóa Y bằng cách sử dụng khóa đã điều chỉnh Z (Z' + Y = Y'). Từ đây bạn có thể lấy Y' và sử dụng nó để điều chỉnh X (Y' + X = X'). Bạn sẽ làm điều này cho đến khi quay lại phím A, lấy A' và sử dụng phím đó từ đó. Khi nó bị hỏng, người dùng có thể phát một sự kiện chứa khóa A chưa được điều chỉnh và khóa B' đã điều chỉnh. Điều này sẽ chứa tất cả dữ liệu cần thiết để cho thấy rằng B' đã được sử dụng để tạo A' và người dùng có thể ngừng theo dõi A' ngay lập tức và thay vào đó theo dõi B'. Họ sẽ biết rõ ràng rằng B' là khóa tiếp theo cho người dùng đó và thay vào đó hãy theo dõi khóa đó.

Tuy nhiên, vẫn còn một số vấn đề với đề xuất này. Đầu tiên, tất cả các khóa sẽ được sử dụng phải được tạo trước và không có cách nào để chuyển sang một bộ khóa hoàn toàn mới. Điều này có thể được giải quyết bằng cách cam kết một khóa chính trong sơ đồ này có thể xác nhận vòng quay này hoặc chỉ bằng cách tạo một bộ khóa rất lớn ngay từ đầu. Một trong hai cách đều khả thi, nhưng cuối cùng yêu cầu giữ an toàn cho khóa gốc hoặc tài liệu khóa và chỉ hiển thị các phím nóng riêng lẻ (Phím nóng) cho các máy khách Nostr.

Tuy nhiên, sơ đồ này không bảo vệ người dùng hoặc cung cấp cơ chế khôi phục danh tính trong trường hợp tài liệu khóa gốc bị mất hoặc bản thân nó bị xâm phạm.

Đối với một số cuộc thảo luận về các giải pháp tiềm năng ở đây, hãy nghĩ về nó theo cách khác, điều chỉnh một phím thành phím lạnh chính cũng phải được sử dụng để ký các sự kiện từ một phím này sang một vòng quay khác. Bạn có khóa A' được lấy bằng cách thêm A và M (khóa chính), sự kiện xoay vòng sẽ là A, M và B' (được tạo bằng cách thêm B và M) và chữ ký của M. M có thể là khóa ngưỡng đa chữ ký - hai phần ba, ba phần năm, v.v. Điều này có thể thêm dự phòng chống mất mát và cung cấp một cơ chế an toàn để xoay khóa. Điều này cũng mở ra cơ hội sử dụng các dịch vụ để trợ giúp khôi phục hoặc chia sẻ một số khóa này cho những người bạn đáng tin cậy. Nó cung cấp tính linh hoạt giống như multisig trong chính Bitcoin.

NIP 26 cũng là một đề xuất có thể rất hữu ích trong việc giải quyết vấn đề này. Điều này chỉ định một phần mở rộng giao thức cho các sự kiện cho phép chữ ký từ một khóa ủy quyền cho một khóa khác xuất bản các sự kiện thay mặt nó. Sau đó, "mã thông báo" hoặc bằng chứng chữ ký được ủy quyền sẽ được đưa vào tất cả các sự kiện được xuất bản bởi khóa công khai thứ hai thay mặt cho khóa đầu tiên. Nó thậm chí có thể bị giới hạn thời gian, do đó, mã thông báo ủy quyền sẽ tự động hết hạn và phải được gia hạn.

Câu hỏi về quản lý và bảo mật khóa là một vấn đề rất lớn với không gian thiết kế rất rộng, đầy những điểm đánh đổi và khó khăn. Tuy nhiên, nếu Nostr không thể bảo vệ và duy trì tính toàn vẹn của các danh tính này cho người dùng, thì một giao thức hoàn toàn dựa trên các cặp khóa công khai/riêng tư được sử dụng làm danh tính sẽ không thể được áp dụng trên quy mô lớn.

Mở rộng đối mặt với Nostr

Toàn bộ giao thức Nostr dựa vào ai đó ở đâu đó đang chạy máy chủ chuyển tiếp. KHÔNG"mạng lưới", chỉ có rơle và các máy khách được kết nối với rơle. Mọi người cần được khuyến khích để chạy tiếp sức, và điều này cuối cùng sẽ là một phần quan trọng trong việc những người tiếp sức có thể mở rộng bao xa trong thời gian dài. Trừ khi một rơle Nostr có thể sinh lãi hoặc ít nhất là mang lại đủ tiền để trang trải chi phí vận hành của chính nó, sẽ không bao giờ có một rơle nào có cùng kích thước với máy chủ Twitter.

Quảng cáo

Với cách Nostr hoạt động như một giao thức, việc chặn hoàn toàn quảng cáo sẽ khá tầm thường, khiến nó trở thành một giải pháp không khả thi. Các máy chủ chuyển tiếp có thể cố gắng sử dụng quảng cáo làm mô hình doanh thu, đây rõ ràng là mô hình doanh thu chính cho hầu hết mọi dịch vụ trực tuyến miễn phí, nhưng vấn đề là người dùng về cơ bản phải chọn tham gia. Rơle có thể dễ dàng đưa quảng cáo vào các sự kiện mà chúng gửi cho khách hàng, nhưng khách hàng cũng có thể dễ dàng lọc các sự kiện quảng cáo khỏi giao diện người dùng của họ nếu chúng không được tạo bởi khóa công khai mà họ dự định đăng ký.

thanh toán vi mô

Thanh toán vi mô là một giải pháp rõ ràng khác, đặc biệt là với những nỗ lực liên tục để tích hợp Lightning Network chặt chẽ hơn vào ứng dụng Nostr. Mô hình này cung cấp rất nhiều tính linh hoạt trong cách bạn tính phí. Rơle chỉ có thể tính phí khi đăng các sự kiện ở đó hoặc để tải xuống phần đọc sự kiện hoặc kết hợp cả hai, điều chỉnh giá của mỗi loại dựa trên lượng tài nguyên mà chúng tiêu thụ. Tuy nhiên, người ta nghi ngờ rằng mô hình này có thể được nhân rộng đến quy mô của Twitter.

Thanh toán vi mô nội dung đã cho thấy khả năng tồn tại của chúng trong nhiều sản phẩm thích hợp dựa trên Lightning Network, nhưng có hai vấn đề cơ bản với việc thực sự mở rộng quy mô toàn cầu.

Đầu tiên, vẫn chưa có đủ sự chấp nhận Bitcoin. Ngay cả khi mọi người chấp nhận trả tiền cho mọi tương tác dịch vụ nhỏ trên Nostr, thì sẽ không có đủ người nắm giữ bitcoin để hỗ trợ một thứ khổng lồ như Twitter. Chuyển tiếp có thể tính phí đăng ký bằng tiền pháp định, nhưng các phương thức thanh toán này sẽ không hỗ trợ trả một khoản phí nhỏ cho mỗi sự kiện được xuất bản hoặc tải xuống. Thứ hai, mọi người đã thực sự quen với loại dịch vụ miễn phí này. Đây chính xác là những gì người ta mong đợi. Tôi không nghĩ rằng các khoản thanh toán vi mô thực sự có thể hỗ trợ chuyển tiếp quy mô lớn.

Có một cách để thực hiện thanh toán vi mô"dính hơn"Hoặc bền vững hơn mà không bắt buộc chúng đối với mọi tầng lớp người dùng sử dụng rơle. Đã có rất nhiều cuộc thảo luận về việc xây dựng các ứng dụng khác nhau trên Nostr, ngoài một bản sao Twitter. GitHub, Wikipedia, thậm chí cả Uber.

Điều cuối cùng là chìa khóa: kỳ vọng kinh tế. Mọi người đã quen với việc trả phí khi một công việc được quảng cáo ở đâu đó hoặc trả phí cho nhà điều hành thị trường khi họ đặt hàng trực tuyến, nhưng không phục vụ những thứ mà họ cho là miễn phí - Google, Twitter. Điều này có thể cung cấp một cách để những người chuyển tiếp tạo ra một cột thu nhập vững chắc từ người dùng của họ mà không tạo ra nhiều trở ngại hoặc phá vỡ kỳ vọng của người dùng tiềm năng trung bình.

Tóm lại là

Tóm lại là

Các dự án xã hội Web3, ngoài Nostr và Mastodon đã nói ở trên, còn bao gồm các dự án như Farcaster và Lens, những dự án này sẽ không nhanh chóng thay thế các nền tảng truyền thông xã hội hiện có. Theo thống kê, Twitter có hàng trăm triệu người dùng đang hoạt động, Facebook có hàng tỷ, nhưng Mastodon chỉ có 2,5 triệu người dùng và Nostr chỉ có khoảng 22 w danh tính người dùng duy nhất. Nhiều dự án xã hội Web3 phải đối mặt với các rào cản về khả năng sử dụng làm chậm quá trình áp dụng hàng loạt.

Truyền thông và chính trị không thể tách rời. Khi các dự án xã hội Web3 phát triển và cuộc trò chuyện công khai bị phân mảnh giữa các ứng dụng và giao thức khác nhau, có thể có kết quả chính trị. Ngay cả Messina, người từ lâu đã ủng hộ phương tiện truyền thông xã hội phi tập trung, lo ngại rằng việc phi tập trung hóa sẽ tiếp tục thúc đẩy một cuộc thảo luận công khai vốn được đánh dấu bằng sự thù địch và hiểu lầm lẫn nhau trong những năm gần đây.