Giới thiệu

Giới thiệu

Hôm nay chúng ta sẽ thảo luận về một chủ đề thu hút nhiều sự chú ý: Vấn đề Spam (thư rác) của Nostr.Là một giao thức phi tập trung, giao thức Nostr đã hiện thực hóa các đặc tính phi tập trung, quyền tự chủ và chống kiểm duyệt của mạng xã hội trên phạm vi toàn cầu. Đồng thời, giao thức này cũng có một số thách thức, trong đó nổi bật nhất là vấn đề Thư rác.Cuộc thảo luận của chúng ta hôm nay sẽ không chỉ giới hạn ở vấn đề Thư rác mà còn tập trung vào tác động của nó đối với tương lai của truyền thông xã hội, tiến bộ của công nghệ phi tập trung và Vì lý do này, cộng đồng DAOrayaki vinh dự được mời ông Sherry, một nhà khoa học dữ liệu từ cộng đồng Nostr CN, bắt đầu chủ đề hôm nay với chúng tôi từ góc độ của một nhà nghiên cứu chuyên nghiệp: Con đường của Nostr đến “ chống thư rác”??

Khách mời: Sherry (Nhà khoa học dữ liệu)

chữ

chữ

Q: Trước khi bắt đầu chủ đề chính thức, mọi người nên tò mò về lý lịch của bạn, tại sao bạn lại quan tâm đến Nostr? Nó có liên quan đến lĩnh vực bạn đang nghiên cứu hoặc khám phá không?

Trên thực tế, mối tương quan không lớn, lúc đầu, khoảng ba hoặc bốn tháng trước, một người bạn đã giới thiệu Nostr với tôi, anh ấy là nhà phát triển Bitcoin Core (Bitcoin Core) với nhiều năm kinh nghiệm, sau đó dần dần chuyển sang phát triển của Nostr. . Khi tôi lần đầu tiên cố gắng tìm hiểu Nostr, tôi đã không nhận ra Nostr hấp dẫn như thế nào, tôi chỉ biết đó là “một thỏa thuận khác trên mạng xã hội”.

Trên thực tế, kể từ khi Twitter trở nên phổ biến, mọi người đã đề xuất rằng APP (chương trình ứng dụng) không nên là phương tiện truyền thông xã hội mà nên biến thành một giao thức. . Vì vậy, sau hai hoặc ba tháng, tôi quyết định Bắt tay bẩn (thực hành cá nhân) và thực sự tham gia vào việc phát triển một số hướng của Nostr.

Q: Sau vài tháng tiếp xúc, bạn nghĩ gì về sự phát triển của Nostr hiện nay? Chúng tôi biết rằng giai đoạn "bùng nổ" ban đầu.

Trên thực tế, từ góc độ của các nhà phát triển, nó không quá phổ biến, tôi nghĩ rằng các phương tiện truyền thông xã hội như Twitter và Instagram tuân theo một quy luật: người dùng tham gia hết đợt này đến đợt khác. Một số người dùng cảm thấy rằng thứ này có thể sử dụng được và giải quyết được vấn đề của họ, và họ sẽ ở lại, nhưng hầu hết trong số họ sẽ không ở lại cho đến khi làn sóng tiếp theo đến.

Những gì chúng ta phải làm là chuẩn bị giữa hai làn sóng, xây dựng cơ sở hạ tầng, tối ưu hóa trải nghiệm người dùng và chờ đợi làn sóng người dùng tiếp theo đến. Ngoài ra, tôi theo dõi số liệu thống kê trên Nostr hàng tuần, cá nhân tôi cảm thấy rằng mọi người vẫn tham gia, nhưng số lượng người có dao động. Cho đến nay, số lượng tài khoản trên Nostr là gần 1 triệu, mặc dù ở giai đoạn này có rất nhiều tài khoản Spam trong số đó.

Tôi nghĩ rằng số lượng nhóm người dùng này có nghĩa là bất kể bạn muốn thực hiện thử nghiệm nào, chúng tôi đều có một nhóm người dùng đủ lớn để đảm bảo tính hợp lệ của việc xác minh chương trình.

Hỏi: Tôi vừa nói là giữa mỗi “làn sóng” sẽ nảy sinh một số vấn đề cần giải quyết gấp. Ở giai đoạn này, trong hệ sinh thái Nostr, ngoài vấn đề Spam mà chúng ta sẽ nói sau, còn vấn đề nào khác cần được giải quyết gấp?

Chỉ có hai vai trò trong Nostr, một vai trò được gọi là Client (máy khách) và vai trò còn lại được gọi là Relay (tiếp sức). Rơle và máy chủ là những khái niệm rất giống nhau và Máy khách chịu trách nhiệm tìm nạp thông tin từ nhiều Rơle. Tương tự đơn giản, chúng ta có thể coi Twitter là một cấu trúc chỉ có một Rơle và khách hàng chỉ lấy thông tin từ Rơle này, tương đương với việc "giao phó" tất cả các hành vi người dùng của bạn cho Rơle duy nhất và duy nhất này, nếu nó cấm bạn thực hiện đăng tin nhắn hoặc thời gian chết, hành vi người dùng của bạn cũng sẽ bị gián đoạn và bạn không có lựa chọn thứ hai trong hệ sinh thái này.

Nhưng có rất nhiều Rơle trên Nostr, bất kỳ ai cũng có thể chạy Rơle của riêng mình và Khách hàng cũng có thể chọn chỉ lấy một phần thông tin của Rơle hoặc không lấy gì cả, nhưng bạn có thể gửi thông tin của riêng mình tới tất cả các Rơle thượng đẳng.

Đồng thời, trong hệ thống xác thực của Nostr, nó bỏ khái niệm truyền thống về tên người dùng và mật khẩu, mà sử dụng khái niệm về cặp khóa, bạn nắm giữ khóa riêng của mình trong tay và mỗi khi bạn xuất bản một tin nhắn, bạn sẽ đính kèm công khai key Đồng thời, sử dụng khóa riêng của bạn để ký vào toàn bộ tin nhắn, chứng minh rằng tin nhắn này được gửi bởi bạn một cách "cá nhân".

Khi nói đến các cặp khóa, có một vấn đề không thể tránh khỏi: quản lý khóa.

Có, khi mình dùng Damus thì nó tự động tạo cặp khóa, nhưng lần sau đăng nhập vào nó phải dùng chức năng như "sổ cái", nếu không thì mình không nhớ public key và private key đâu. phải là một hành động sao chép-dán.

Đúng vậy, quá trình sao chép và dán như vậy thực sự có nguy cơ bị rò rỉ rất lớn. Vì vậy tôi thấy ai bị mất mật khẩu sẽ rất nhạy cảm để biết cách quản lý một hoặc nhiều cặp khóa và cách bù đắp khi mất. Vì vậy, đối với người dùng mới, làm thế nào để giới thiệu khái niệm khóa chung và khóa riêng cho họ thông qua UI (giao diện người dùng) hoặc UX (trải nghiệm người dùng) hoàn hảo và hướng dẫn họ tạo tài khoản và quản lý tài khoản của riêng họ là điều bắt buộc. cần thiết.

Nhưng trên thực tế, tôi không đặc biệt lo lắng về điều này, bởi vì tôi cảm thấy rằng chính tính năng này đã khiến Nostr trở thành cầu nối với Bitcoin. Bởi vì trên Nostr, điều tồi tệ nhất là người dùng bị mất Bài đăng hoặc mất Người theo dõi, nhưng trên thực tế, bạn có thể lấy lại Người theo dõi thông qua một số phương tiện và sẽ không có thiệt hại về kinh tế.

Hỏi: Như vậy việc trông giữ và cất giữ chìa khóa đúng là có vấn đề, nhưng không nghiêm trọng và cấp bách như tưởng tượng. Và mặt khác, nó thực sự giúp Nostr phá vỡ vòng vây một cách nhanh chóng, vì ví Web 3 thực sự vẫn còn một "rào cản" cũng chặn nhiều người dùng Web 2.

Ngoài vấn đề này, còn những vấn đề cấp thiết hơn được đặt lên “bàn”?

Hơn nữa, với lượng người dùng tăng lên, lưu lượng của toàn bộ mạng sẽ trở nên rất lớn. Lúc này, hãy tưởng tượng một tình huống cực đoan: Nếu mọi người gửi tất cả thông tin đến từng Rơle để lưu tất cả các tin nhắn lịch sử của họ, khi tình huống này trở nên phổ biến, hầu hết các Rơle sẽ lưu trữ một lượng lớn thông tin trùng lặp và Máy khách sẽ bắt Khi lấy thông tin, Rơ le chứa thông tin lặp đi lặp lại cũng sẽ bị quét từ đầu đến cuối, giải pháp này tương đối kém hiệu quả.

Khi làn sóng người dùng đầu tiên tăng nhanh trước đó, nhiều nhà phát triển sẽ có tâm trạng rất "sụp đổ", họ sẽ cảm thấy nhiều giải pháp không hiệu quả. Tôi nên làm gì nếu quá nhiều người vào và mạng sẽ bị tê liệt? Vì vậy, tôi nghĩ rằng đây thực sự là những vấn đề cần được giải quyết càng nhiều càng tốt trước làn sóng tăng trưởng người dùng tiếp theo. Nếu nó không được giải quyết, nó sẽ mang lại cho người dùng nhiều trải nghiệm người dùng không tốt, chẳng hạn như không thể tải thông tin, hiển thị và tải ứng dụng khách chậm và sẽ khó giữ chân được nhiều người dùng hơn.

H: Vâng, cứ tưởng tượng nếu tôi là nhà sản xuất nội dung và xuất bản nội dung trên Nostr's Relay, nếu chi phí thời gian cho phép, nếu thao tác không phức tạp, tôi cũng có thể chọn gửi qua nhiều Relay, như vậy sẽ thực sự tồn tại Tình huống trùng lặp thông tin dẫn đến hiệu suất tổng thể và tải chậm hơn.

Hiện tại có hai giải pháp chính cho vấn đề này, một là thêm một Lớp trên Nostr, tương đương với việc thêm một lớp Lớp 2 vào toàn bộ giao thức Nostr, chỉ có một số nút hạn chế đang chạy trên đó và số lượng là nhỏ hơn số lượng của toàn bộ Rơle. Mỗi nút lưu trữ dữ liệu chuyển tiếp mà nó chọn và máy khách chỉ giao tiếp với nút bộ đệm, điều này sẽ cải thiện trải nghiệm người dùng. Hiện tại đã có client triển khai chức năng này, việc tải thông tin trên cũng rất mượt mà, tuy nhiên phương pháp này bị nhiều người phản đối, lý do là cuối cùng chúng ta đã tạo ra một giao thức phi tập trung, nhưng cuối cùng lại trả về cho client và chỉ được giao tiếp với một vài hoặc Giao tiếp một nút trở về tuyến tập trung.

Ngoài ra còn có mô hình Gossip, bởi vì khách hàng triển khai mô hình này ban đầu được gọi là Gossip. Chế độ hoạt động của nó là người dùng xuất bản một tin nhắn và tin nhắn sẽ nêu rõ chuyển tiếp nào mà người dùng đọc tin nhắn và chuyển tiếp nào mà người dùng viết tin nhắn. Theo cách này, khi client nắm bắt hết thông tin, nó sẽ chỉ đến node liên kết để nắm bắt thông tin đọc ghi của người dùng yêu cầu, điều này sẽ giảm tình trạng Post lặp lại.

H: Trước đó chúng ta đã nói về quyền riêng tư và bảo mật của khóa công khai, ưu và nhược điểm của cài đặt Chuyển tiếp và mối quan tâm về các vấn đề phái sinh.

Tiếp theo, hãy nói về vấn đề Spam, đây có thể là một chủ đề nóng hiện nay, bạn nghĩ tại sao vấn đề Spam lại nổi cộm ở Nostr?

Trước hết, vì Nostr còn rất mới nên có một số biện pháp chống thư rác, nhưng cốt lõi của hầu hết các biện pháp là lọc từ khóa, tôi nghĩ rằng đối với người dùng nói tiếng Anh, đây có thể là tình huống phức tạp nhất mà họ từng gặp phải , nhưng nó có thể không giống với chúng tôi, nếu tôi gửi một văn bản sao Hỏa, bộ lọc từ khóa sẽ không hoạt động.

Một điều nữa là hầu hết các Rơle hiện nay đều miễn phí. Trong giai đoạn đầu, bạn có thể nghĩ rằng điều đó không quan trọng. Bạn có thể sử dụng Rơle của tôi miễn phí mà không cần đặt ra bất kỳ quy tắc nào. Mọi người đều có thể đọc và viết, nhưng điều này cũng dẫn đến Thư rác. bất cứ giá nào. Việc tạo tài khoản cũng rất dễ dàng, tài khoản truyền thống có thể cần phải liên kết với địa chỉ email và số điện thoại di động, nhưng ở Nostr, chỉ cần bạn nhấp vào Tạo khóa (tạo khóa), bạn có thể nhận ngay danh tính mới, vì vậy nó hoàn toàn khả thi để tạo tài khoản Spam hàng loạt Có, và rất đơn giản, chi phí cũng xấp xỉ bằng 0.

H: Thực ra, điều tôi không hiểu là tại sao họ lại tạo ra một số lượng lớn tài khoản Spam? Bởi vì cũng không có khuyến khích mã thông báo hoặc khuyến khích kinh tế trong hệ thống này, mục đích của việc này là gì? Chỉ để gửi quảng cáo rác, quảng cáo lừa đảo?

Mục đích chính là để thu hút lượng truy cập, và không chỉ có Spam, sẽ có cả một số thông tin nhạy cảm.

Q: Mặc dù vấn đề Spam đã xuất hiện ở Nostr ở giai đoạn này, nhưng nó thực sự là một vấn đề cũ trong các lĩnh vực khác, vậy trong hệ sinh thái hoặc các lĩnh vực trưởng thành, có những phương pháp nào để giải quyết vấn đề Spam?

Một là sử dụng công nghệ học sâu thông qua nhận dạng văn bản hoặc hình ảnh. Hai là phân tích hành vi của người dùng, trong một hệ thống tập trung, hành vi của tài khoản Spam phải khác với hành vi của người dùng thông thường, chẳng hạn tần suất gửi có thể thay đổi đột ngột, tài khoản nào đó nửa năm không làm gì cả. . , nhưng nó đột nhiên trở nên rất tích cực. Thông qua việc phân tích các hành vi của người dùng như vậy, có thể đạt được chức năng ngăn chặn thư rác chính xác hơn.

H: Chúng ta vừa nói về việc tất cả các nút Chuyển tiếp hiện đều miễn phí, vậy liệu tính phí có phải là một phương pháp hiệu quả không?

Không phải tất cả các rơle đều miễn phí, nhưng hầu hết trong số chúng, hiện có các rơle trả phí và các rơle trả phí không có vấn đề về Thư rác. Bởi vì trước khi xuất hiện số lượng lớn Spam, tương đối ít người sử dụng chuyển tiếp trả phí, phải đến khi đột nhiên có rất nhiều IP từ Trung Quốc đại lục và Hồng Kông tràn vào (do nhiều máy chủ Spam được thiết lập ở Hồng Kông) thì mọi người mới biết. đã nghĩ đến việc tìm kiếm một rơle trả phí. , vì vậy trong khoảng thời gian đó, số lượng đăng ký người dùng trả phí cho rơle đã tăng lên đáng kể.

Q: Điều đó có nghĩa là, giải pháp hiện tại cho Spam, tính phí như một nỗ lực quy mô nhỏ, đã đóng một vai trò nhất định. Nói về giải pháp, bước tiếp theo là nói về NIP (Khả năng thực hiện Nostr, tính khả thi của chức năng Nostr), hiện tại vẫn còn rất nhiều NIP trên Nostr và chúng liên tục được cập nhật, bạn cũng là một trình biên dịch tiếng Trung có liên quan. Tôi có hai câu hỏi A: Đầu tiên, tình trạng hiện tại của đề xuất NIP tổng thể là gì và nó đang tiến triển như thế nào? Thứ hai, bạn có tìm thấy bất kỳ biện pháp thú vị nào có thể giải quyết vấn đề Thư rác không?

Khi mới bắt đầu, tiêu chuẩn của NIP tương đối thấp, chỉ cần 1 hoặc 2 Client thực hiện giao thức, chúng sẽ được hợp nhất (merge), bây giờ yêu cầu sẽ cao hơn, bởi vì người dùng không ngừng tăng lên và 3 đến 5 client có thể cần thiết Khách hàng hoặc hơn 5 triển khai của một NIP nhất định, nó sẽ được hợp nhất với nhánh chính.

Trước đây, có hai thỏa thuận có mối quan hệ nào đó với Spam, một thỏa thuận chủ động và thỏa thuận kia bị động. Đang hoạt động là có cảnh báo nội dung nhạy cảm (cảnh báo thông tin nhạy cảm), nếu người dùng đăng nội dung không phù hợp với trẻ vị thành niên thì Cảnh báo sẽ được đánh dấu, đây cũng là một dạng Spam tương đối lành tính. Cái còn lại là một giao thức có tên là Báo cáo, có nghĩa là người dùng có thể bị báo cáo. Tôi nhớ một sự cố đã xảy ra trên Nostr vào tháng trước, một cô gái đã đăng một bức ảnh tự sướng và có người đã xúc phạm cô ấy trong khu vực bình luận, và nhiều người đã nhấp vào để báo cáo bình luận đó.

Và chủ đề tiếp theo không thể không nhắc đến là liệu việc tước bỏ quyền phát biểu của người khác bằng phương tiện đưa tin có trái với cái gọi là quyền tự do của Nostr hay không? Kiểm toán chắc chắn sẽ tồn tại, nhưng ai sẽ kiểm toán nó, liệu chúng ta có thể phân biệt nó thông qua Rơle hay không, v.v., tất cả đều là vấn đề. Tất nhiên, nhiều người cho rằng có thể có Spam Relay đặc biệt, chẳng hạn như Relay chứa đầy thông tin chợ đen dark web, Relay chứa đầy thông tin khiêu dâm, v.v., bởi vì cốt lõi của Nostr là nó sẽ không ngăn cản bạn làm bất cứ điều gì.

NIP của Báo cáo thực sự rất thú vị, nó xuất hiện lần đầu tiên do người tạo ra Damus, dựa trên yêu cầu của Apple Store, tức là phải thêm chức năng Báo cáo trước khi lên kệ, cho đến khi nó cuối cùng phát triển thành một NIP.

Q: Đúng vậy, Damus khá gập ghềnh khi ra mắt trên Apple App Store, có thể là do mối quan hệ này nên cần phải thêm một số cơ chế cơ bản vào nó.

Vâng, tôi đã gặp phải rất nhiều phản đối vì nhiều thứ rất đơn giản để thực hiện trong Web 2 sẽ trở nên phức tạp hơn khi được chuyển sang kiến ​​trúc của Nostr.

Hỏi: Thực ra tôi thấy chủ đề kiểm duyệt và đưa tin khá thú vị, đó là phân quyền có nên có ranh giới hay không, có cái gọi là "điểm mấu chốt" không? Bạn nghĩ gì về vấn đề này?

Tôi nghĩ rằng đây có thể là câu hỏi ai sẽ thực hiện việc "sàng lọc", nghĩa là ai sẽ trao quyền xem xét, cho ai, cấp như thế nào và tại sao.

Hỏi: Nhưng tiền đề là phải có sự “sàng lọc”?

Vâng, tôi nghĩ rằng "sàng lọc" là cần thiết. Đặc biệt khi xem xét rằng những người có quyền truy cập Internet bao gồm cả trẻ vị thành niên, đây là lý do chính tại sao tôi ủng hộ việc sàng lọc.

Q: Tương tự như vậy, vấn đề này trong Rơle cũng vậy, nếu một số Rơle hoạt động rất tốt thông qua các cơ chế hoặc phương pháp nhất định và cung cấp nhiều nội dung chất lượng cao, thì (một số) Rơle này sẽ trở nên lớn hơn, tập trung hơn , và các Rơle khác không được sử dụng? Nó sẽ như thế này?

Từ góc độ trải nghiệm người dùng, Rơle gần như là một sự tồn tại vô hình, tức là người dùng khó có thể nhận ra bằng trực giác rằng một Rơle nào đó rõ ràng là tốt hơn một Rơle khác. Ngoài ra, nhóm mục tiêu chính hiện đang sử dụng Nostr là những người quan tâm hơn đến nội dung họ sản xuất, họ muốn lấy lại quyền kiểm soát nội dung của chính họ. chắc chắn sẽ gửi tin nhắn Không thể gửi tới nhiều Rơle và không thể chỉ gửi tới một Rơle Gửi tới một Rơle sẽ thay đổi chế độ "quay lại" thành Twitter. Hiện tại có rất nhiều Rơle và hầu như không có sự khác biệt rõ ràng về ưu điểm và nhược điểm giữa chúng, điều này có thể khiến người dùng giữ lại một số trong số chúng.

Q: Thành thật mà nói, tôi không nghĩ rằng có bất kỳ sự khác biệt rõ ràng nào ở giai đoạn này bởi vì mọi người đều giống nhau và không có nội dung. Lúc đầu có thể chúng ta chưa có tiêu chuẩn phân biệt các rơle, có thể vào ngẫu nhiên 1 rơle nào đó và bị choáng ngợp bởi rất nhiều tin nhắn lộn xộn, nhưng nếu bây giờ biết rằng một số rơle có thể có rất nhiều Spam thì loại này của rơle có thể Không cần, có thể đây cũng là quá trình môi trường “giáo dục” người dùng. Mặc dù các Rơle ở giai đoạn này không đồng đều và không mang lại cho người dùng nhận thức mạnh mẽ để thúc đẩy mọi người chọn một số Rơle nhất định, nhưng lý do có thể là mọi người đều giống nhau và không tốt lắm, tôi nghĩ vậy.

Nhưng trong trường hợp này, điều bạn muốn làm là khách hàng? Có phải khách hàng này chỉ giao tiếp với một rơle?

Q: Nó chỉ là một phép ẩn dụ hoặc một phép loại suy.Chúng tôi chỉ hy vọng rằng thông qua một số phương pháp nhất định, dù ở tầng giao thức hay ở phía máy khách, chúng tôi có thể trình bày nội dung chất lượng cao hơn trong hệ sinh thái tổng thể của Nostr. Nhưng ít nhất là từ khi Jack bắt đầu call list cho đến khi được phổ biến rộng rãi, người ta chưa thấy nó có thể có ưu thế đặc biệt nổi bật trong một ca khúc hay một lĩnh vực nào đó. Tất nhiên, tôi nghĩ điều này cũng liên quan đến thời gian, và chúng ta phải dành thời gian để phát triển.

Về thiết kế Nostr mình nghĩ có thể đơn giản hóa là "Start Client câm Relay". Tức là Relay thực chất không có chức năng gì, chức năng duy nhất của nó là lưu trữ, ngoài ra khi Client yêu cầu thông tin thì nó sẽ tự thực hiện một bộ lọc. Ví dụ có một client thì thông tin Global (toàn cầu) của nó không hiển thị thông tin chuyển tiếp chưa lọc mà hiển thị thông tin do các liên hệ trong mạng xã hội ba tầng gửi đến nên thực tế rất ít spam.

Q: Từ góc độ này, tôi cảm thấy đây cũng là sự thông minh trong thiết kế tối giản của Nostr, đôi khi càng tối giản thì sẽ càng có nhiều không gian thiết kế. Nói về chủ đề này, chúng tôi biết rằng Nostr hỗ trợ Mạng Lightning (Lightning Network), và các ưu đãi và thanh toán trên Nostr cũng là chủ đề tất yếu cho sự phát triển trong tương lai.

Có, nó hiện chỉ hỗ trợ Lightning Network.

H: Đối với tôi, có vẻ như điều này sẽ hạn chế người dùng? Vì số lượng người sử dụng Bitcoin làm phương tiện thanh toán luôn bị hạn chế?

Điều này có thể liên quan đến lịch sử phát triển của Nostr Hầu hết các nhà phát triển ban đầu của Nostr đều là nhà phát triển của Lightning Network và nhiều người trong số họ đã làm việc trên giao thức Lightning Network, bao gồm cả phát triển liên quan đến ví. Ngoài ra, tôi không nghĩ rằng Nostr sẽ bị hạn chế bởi Lightning Network, Nostr là một cái gì đó rộng hơn Lightning Network, người dùng có thể chọn chỉ sử dụng các chức năng xã hội của nó và không sử dụng chức năng thanh toán. Trong phân tích cuối cùng, nhóm cốt lõi mà nó thu hút vẫn là nhóm muốn kiểm soát nội dung họ sản xuất.

Q: Bạn thấy sự phát triển của Nostr trong tương lai như thế nào?

Thực tế đã có nhiều người hỏi tôi câu hỏi: “Tôi nên đầu tư vào Nostr như thế nào?” Nói thật là tôi cũng không biết trả lời cụ thể câu hỏi này như thế nào, tôi nghĩ cứ xây dựng cái gì đó là tốt rồi, tôi không biết. nghĩ rằng Nostr thực sự Nó không thuộc danh mục Web 3, nó chỉ là một giao thức phi tập trung.

Ví dụ: có một giao thức gọi là Huy hiệu trên Nostr, nghĩa là người dùng có thể ký vào một hình ảnh và gửi cho những người dùng khác để huy hiệu sẽ được hiển thị dưới hình đại diện trên máy khách, nhưng nhiều người sử dụng nó như một NFT. Tất nhiên, tôi sẽ không ngạc nhiên nếu một ngày nào đó bạn phải nạp tiền để có được Huy hiệu, giữa chúng có thể có một số điểm tương đồng nhưng vẫn có những điểm khác biệt lớn. Ngoài ra, tôi nghĩ rằng bất kỳ công ty nào muốn kinh doanh trao đổi thông tin trong tương lai, nếu nó không tích hợp vào Nostr, kết quả của việc chờ đợi công ty này có thể sẽ dần biến mất.

Q: Trao đổi thông tin? Tôi nghĩ rằng đây là một hướng tốt để suy nghĩ về.

Tôi nghĩ bất cứ ai đã trải nghiệm các tính năng của Nostr sẽ đồng ý với quan điểm này. Một tài khoản người dùng và một cặp khóa có thể đi qua tất cả các ứng dụng, do đó không cần phải bị hạn chế bởi bất kỳ nền tảng nào. Người hâm mộ của bạn trên một nền tảng có thể chuyển sang nền tảng khác bất cứ lúc nào và khía cạnh cạnh tranh sẽ trở nên công bằng hơn. trên cùng một cấp độ. Và sẽ không có chuyện một nhà sản xuất nội dung cấp thấp lại thu được nhiều lượng truy cập chỉ vì nền tảng mà nó dựa vào rất mạnh.

Trong trường hợp này, nếu bạn là nhà sản xuất nội dung, thì tất cả khán giả người dùng của bạn nằm rải rác trên tất cả các nền tảng đều có thể xem nội dung bạn sản xuất. Theo tôi, đây là điểm quan trọng nhất và cũng là để đảm bảo rằng Nostr sẽ tiếp tục phát triển hơn một chút .

Ngoài ra, Nostr còn có thể làm những việc khác ngoài Social Media. Ví dụ, có một dự án tên là Nostrocket. Dự án này là một lớp đồng thuận dựa trên Nostr. Nói cách khác, chúng ta có thể sử dụng nó để tạo thành một DAO trên Nostr và nhận ra một số chức năng không hoàn toàn giống với hợp đồng thông minh. Nó sẽ cũng hiệu quả hơn hợp đồng thông minh.

Q: Được rồi, cảm ơn cô Sherry đã chia sẻ. Cô có điều gì khác để bổ sung vào chủ đề hôm nay không?

Chào mừng mọi người đến với Meetup ở Hồng Kông hahaha, chào mừng mọi người.

Q: Đúng vậy hahaha, chúng ta sẽ cùng nhau tổ chức một buổi Offline Meetup tại Hồng Kông vào ngày 14 tháng 4. Đây cũng có thể là buổi offline Nostr quy mô tương đối lớn đầu tiên trong cộng đồng Trung Quốc. Tất nhiên, bối cảnh chung là chúng tôi sẽ khởi động cuộc thi Nostr Hackathon toàn cầu trong thời gian tới, chúng tôi cũng hoan nghênh các Nhà xây dựng như Sherry tham gia cuộc thi dự án, tiền thưởng của cuộc thi vẫn rất hậu hĩnh. Những người đam mê, nhà phát triển, bên dự án, nhà nghiên cứu giao thức và những người có nhiều đề xuất khác nhau đều được hoan nghênh tham gia.

Ngoài ra, nhiều thứ ở Nostr giai đoạn này chưa hoàn hảo nên còn nhiều Ý tưởng tạm thời chưa có cơ hội hiện thực hóa, nếu có Nostr developer nghe podcast này thì có thể thử.

Đầu tiên, đối với những người sản xuất nội dung, cá nhân tôi cảm thấy một dự án nhất định phải có lãi thì mới có thể tiếp tục hoạt động, nếu những người tham gia không có bất kỳ khoản lợi nhuận nào thì kết quả cuối cùng có thể sẽ không tốt. Tôi đã từng có ý tưởng về các nhà sáng tạo âm nhạc, giả sử tôi muốn phát hành một bản nhạc trong ba ngày và nếu một số người dùng muốn nghe trước bản nhạc đó, thì chúng ta có thể sử dụng mô hình Trả tiền để nghe (trả tiền để nghe trước). , bởi vì chúng tôi đã có hỗ trợ các công cụ thanh toán (Lightning Network) và Nostr, trong trường hợp người dùng như vậy, vấn đề lớn nhất của nó là sau khi người dùng thanh toán, anh ta có thể rò rỉ nội dung, do đó lượng người trả tiền tiềm năng sẽ giảm đi. Sau đó, bạn có thể Mã hóa (mã hóa) thông tin liên quan của người trả tiền đã mua nhạc, tức là thêm một lớp tần số mà tai người khó nghe được vào bản nhạc, sau đó Giải mã (giải mã) khóa chung và khóa riêng của người dùng khóa ở cấp độ Khách hàng. Bằng cách này, một khi ai đó mua và rò rỉ nó, nó có thể được truy ngược lại người đó thông qua Giải mã, điều này có thể gây ra áp lực tâm lý tương tự như "cái chết xã hội".

Một điều nữa là không có chức năng tương tự như Zhihu hay Quora (một trang web hỏi đáp tương tự như Zhihu) ở cấp độ Nostr. Do Nostr thiếu cơ chế đề xuất nội dung tốt hơn nên người dùng khó tìm thấy nội dung thú vị và cơ chế truyền thống có những hạn chế nhất định, bởi vì trong kịch bản Nostr, việc tạo tài khoản không tốn bất kỳ chi phí nào, tương đương với Like không giới hạn .

Ngoài ra còn có cái gọi là trò chuyện nhóm được mã hóa, cũng đang có nhu cầu lớn. Phần mềm trò chuyện ngày nay, chẳng hạn như Telegram, được gọi là trò chuyện nhóm, nhưng sau khi tạo Kênh (tương tự như nhóm trò chuyện), mọi người có thể thấy những người trong đó nói về điều gì và mọi người có thể vào và ra tùy ý, tương đương với "Chạy khỏa thân ở quảng trường", tôi nghĩ cuộc trò chuyện nhóm thực sự tương tự như "chạy khỏa thân trong nhà tắm".

Hỏi: Đúng vậy, nó có sự phân biệt giữa môi trường lớn và môi trường nhỏ.