- Nostr là một giao thức truyền thông mở loại bỏ sự kiểm soát tập trung, với kiến trúc được thiết kế để thông tin có thể lưu thông tự do thông qua nhiều tổ hợp client·relay khác nhau
- Người dùng xác lập danh tính và tính xác thực của thông điệp dựa trên khóa·chữ ký cá nhân, còn client kết nối đồng thời tới nhiều relay để phân tán việc phát tán và truy vấn
- Giao thức không thuộc sở hữu của ai, nhưng mỗi nhà vận hành relay có thể đặt ra tiêu chí kiểm duyệt·chặn theo chính sách riêng, và người dùng tự chọn relay nào để đọc
- Vượt ra ngoài microblogging kiểu Twitter, hệ sinh thái đang mở rộng với các sub-protocol như nhóm kín (NIP-29), marketplace, wiki phân tán, cộng tác mã/torrent/livestreaming
- Hiện đây vẫn chưa hẳn là một sản phẩm hoàn thiện mà đang ở giai đoạn cần sự tham gia của developer·early adopter, đồng thời giải quyết các bài toán như spam, scaling và khả năng khám phá bằng chiến lược kết hợp client·relay
An open protocol with a chance of working
- Nostr hướng tới một không gian chung cho truyền thông không phụ thuộc khuynh hướng chính trị, đồng thời định nghĩa một kiến trúc client/server có khả năng mở rộng như một tiêu chuẩn đơn giản mà ai cũng có thể triển khai và sử dụng
- Không bị kiểm soát bởi công ty hay chính phủ cụ thể nào, và chấp nhận tinh thần internet thời kỳ đầu: cởi mở·hỗn độn, nơi nhiều client khác nhau cùng hiển thị một lớp thông tin chung từ các góc nhìn khác nhau
- Trang web đưa ra ảnh chụp màn hình của các client thực tế, nhấn mạnh tính đa dạng của hệ sinh thái và định hướng sử dụng thực tiễn
Many clients, many servers
- Khác với dịch vụ tập trung, client của Nostr kết nối đồng thời tới nhiều relay
- Mỗi relay là một máy chủ dựa trên WebSocket, đóng vai trò kho lưu bài viết phân tán để truy vấn và đăng ký theo dõi các event quan tâm
- Vì không lấy một relay cụ thể làm nguồn tin cậy duy nhất, nên có hiệu ứng phân tán rủi ro kiểm duyệt·shadowban
- Thông qua các liên kết tài liệu tham khảo, nội dung cũng hướng dẫn tài liệu học tập để hiểu sự khác biệt với các mô hình hiện có
A new paradigm for communication
- Danh tính người dùng được biểu diễn bằng private key bí mật, và mọi thông điệp đều chứa chữ ký số, cho phép xác minh đúng là tác giả đó mà không cần cơ quan có thẩm quyền
- Nền tảng niềm tin dựa trên mật mã này giúp tạo ra khả năng broadcasting chống kiểm duyệt
- Cung cấp liên kết video giải thích thân thiện để hạ thấp rào cản cho người mới bắt đầu
The protocol is ownerless, relays are not
- Giao thức là vô chủ thể, nhưng relay là tài sản sở hữu tư nhân, nên mỗi nhà vận hành có thể tự đặt ra tiêu chí chấp nhận·từ chối
- Vì người dùng được tự do chọn relay để đọc, nên sự đa dạng biểu đạt và quyền lựa chọn truy cập cùng tồn tại
- Thay vì chia đôi thành “ủng hộ/phản đối kiểm duyệt”, trọng tâm được đặt vào tính đa nguyên của quy tắc theo từng server và sự lựa chọn của người dùng
Freedom of association
- Vì hiệu ứng mạng không bị trói vào một tổ chức duy nhất, nên đây là một cấu trúc khiến một nhóm người dùng cụ thể khó có thể gây hại mang tính cấu trúc cho người khác
- Video liên quan nhấn mạnh tự do liên kết và tự do tách rời
Your own piece of Nostr
- Lập trình viên có thể dễ dàng chạy relay riêng và áp dụng quy tắc riêng của mình
- Nội dung dẫn tới repository triển khai relay để khuyến khích đóng góp và thử nghiệm
New Ideas — Exploring the commons
- Ngoài microblogging kiểu Twitter, Nostr còn hỗ trợ nhiều kiểu dữ liệu như video/bài viết dài/hình ảnh/voice note
- Các thử nghiệm sub-protocol như nhóm kín, Wikipedia phân tán, couchsurfing, marketplace, chú thích web đang diễn ra sôi nổi
- Những nỗ lực dùng Nostr làm lớp khám phá·điều phối cho cộng tác mã phân tán dựa trên git, lưu trữ tệp, chia sẻ torrent, video live cũng đang được triển khai
- Việc mở rộng tính năng và khả năng tương tác được thúc đẩy thông qua bộ đề xuất tiêu chuẩn NIP
Ecosystem — Still under construction
- Dù đã có phần mềm mã nguồn mở và lượng người dùng lớn, hệ sinh thái này vẫn chưa đạt tới mức sản phẩm hoàn thiện trau chuốt
- Sự tham gia của người dùng sớm·developer rất quan trọng để cải thiện luồng giao thức và UX
Microblogging — The outbox model
- Mô hình outbox được giới thiệu như cách triển khai client chống kiểm duyệt tiêu biểu, nhưng các tham số vẫn linh hoạt
- Hướng dẫn triển khai giải thích cách xem relay như một kho lưu trữ và chiến lược subscribe/publish
Relay-based groups — NIP-29
- NIP-29 đưa ra cách triển khai hiệu quả các nhóm kín kiểu forum/chat dựa trên relay
- Cấu trúc này giúp giảm phụ thuộc vào một relay duy nhất mà vẫn giữ được khả năng chống kiểm duyệt
How Nostr works
- Mục tiêu là mang lại tự do thực sự để duy trì kết nối giữa người dùng và khán giả ngay cả trong môi trường khắc nghiệt
- Thông qua nhiều relay, lập chỉ mục cục bộ và đọc có chọn lọc, hệ thống bảo đảm khả năng truy cập bền vững
FAQ — Câu hỏi và trả lời cốt lõi
-
“Giao thức” là gì
- Đây là ngôn ngữ chung để nhiều phần mềm giao tiếp với nhau, và cũng có nghĩa là khả năng tương tác không phụ thuộc vào một ứng dụng cụ thể, giống như e-mail/HTML/HTTP
- Nhiều ứng dụng dùng chung một ngôn ngữ có thể thay thế cho nhau, đồng thời mỗi ứng dụng có cách biểu đạt·UI riêng
-
Spam và nội dung không mong muốn được xử lý thế nào
- Feed cơ bản chỉ lấy thông tin từ những người tôi theo dõi, nên rất khó thực hiện push spam
- Các truy vấn mở như xem bình luận có thể bị lộ ra trước spam, nên người ta dùng các chiến lược giảm bề mặt tiếp xúc như giới hạn hàng xóm bậc 2, whitelist relay tin cậy, relay trả phí/xác minh
- Không có lời giải hoàn hảo, nhưng Nostr được thiết kế với giả định về khả năng phục hồi
-
Có thể scale khi được chấp nhận ở quy mô lớn không
- Về cơ bản đây là kiến trúc client-server, và do người dùng tự nhiên phân tán ra hàng trăm relay, nên cân bằng tải đã được tích hợp sẵn
- Việc kết nối tới quá nhiều relay có thể gây lo ngại, nhưng mọi người thường theo dõi các cụm tài khoản có mối quan tâm tương tự, từ đó relay tự nhiên hình thành mẫu số chung
- Ứng dụng native có thể xử lý hàng trăm WebSocket, đồng thời dùng cơ sở dữ liệu cục bộ và batch request để bảo đảm hiệu năng
-
Quấy rối trực tuyến được xử lý ra sao
- Tương tự spam, các bài đăng không mong muốn vẫn có thể xuất hiện, nên việc giảm tối đa mức độ phơi lộ được thực hiện bằng chặn, danh sách chặn dùng chung, relay giới hạn quyền đọc
- Các tính năng bảo vệ như chỉ bạn bè mới xem được có thể được mô phỏng thông qua chính sách relay
-
Vì sao không phải Mastodon/fediverse
- Do thiếu mật mã học, mô hình multi-master là không thể, dẫn đến vấn đề danh tính gắn với server sở hữu và sự chuyển giao niềm tin giữa các server
- Nó đòi hỏi mức độ tin cậy quá lớn vào nhà vận hành server, đồng thời sự phụ thuộc vào domain·DNS cũng bị chỉ ra là vấn đề
- Nostr cho phép hình thành cộng đồng thực sự ở cấp relay thông qua danh tính không ràng buộc với server và quyền chọn relay
-
Vì sao không phải Bluesky/ATProto
- Sự tập trung hóa danh tính dựa trên PLC cùng luồng chuẩn duy nhất Relay-AppView-Client làm tăng rủi ro kiểm duyệt·sắp xếp lại·shadowban
- Có thể cải thiện bằng cách đa nguồn, nhưng làm vậy thì trên thực tế sẽ hội tụ về cấu trúc tương tự Nostr
-
Động lực vận hành relay có được căn chỉnh hợp lý không
- Chi phí vận hành server thấp, nên nhiều chủ thể như cộng đồng/cá nhân/tổ chức/nhà cung cấp hosting đều có thể cung cấp relay với chi phí rẻ
- Vì người dùng có thể đi bất cứ đâu, nhiều chủ thể kinh tế khác nhau có thể được đồng bộ động lực
-
Có thể nhìn thấy toàn bộ nội dung bị phân tán trên nhiều relay không
- Cũng như không thể thấy mọi chuyện trên thế giới, ta chỉ có thể quan sát trong phạm vi trọng tâm và quyền truy cập được cho phép
- Đây là giới hạn tự nhiên gắn với sự tập trung chú ý và lựa chọn relay
-
Tìm kiếm hoạt động như thế nào
- Về bản chất, chỉ những gì đã thấy mới có thể tìm kiếm, nên nếu muốn tìm kiếm công khai thì crawler/indexer phải chọn lọc thu thập mạng lưới
- Client có thể nhanh chóng tìm lại nội dung tôi đã xem/đã tương tác bằng tìm kiếm cục bộ nhờ lưu trữ local
- Relay theo chủ đề có thể cung cấp tìm kiếm trong phạm vi hữu ích thông qua tự lập chỉ mục
-
Nếu không có thuật toán thì làm sao khám phá nội dung mới
- Cơ bản là khám phá thông qua đồ thị tương tác của danh sách theo dõi, và Nostr cũng có thể có các thuật toán cục bộ/relay/AI-based
- Có thể áp dụng nhiều cơ chế discoverability như làm nổi bật/gợi lại nội dung trên client local, hay curation ở phía relay
-
Mối quan hệ với Bitcoin là gì
- Nostr chia sẻ nguyên lý mật mã học và khởi phát từ cộng đồng Bitcoin, nhưng không có phụ thuộc
- Zaps là tiêu chuẩn tip bằng Bitcoin do một số client triển khai, và hoàn toàn là tùy chọn
1 bình luận
Ý kiến Hacker News
Cần biết rằng công nghệ mã hóa của Nostr có những lỗ hổng nghiêm trọng
Các điểm yếu chính được nêu trong bài báo này như sau
Giao thức sự kiện không xác thực khóa công khai, nên chữ ký khóa đối xứng chỉ mang tính hình thức
Hai client lớn là Damus và Iris thậm chí còn không kiểm tra chữ ký
DM trong hệ thống dùng kiểu mã hóa CBC không được xác thực, nên kẻ tấn công có thể thay đổi nội dung bằng bit-flipping trên tin nhắn
Ứng dụng tự động tạo xem trước liên kết khiến kiểu tấn công EFAIL cũ có thể tái diễn
Hệ thống không phân biệt khóa, nên có thể lừa người dùng dùng sai khóa phiên
Nhìn chung đây là những sai lầm sơ đẳng ở mức giữa những năm 2000
Nostr có thể có ưu điểm khác, nhưng nếu muốn bảo mật đầu cuối thì đây không phải nền tảng phù hợp
Tôi đã hoạt động lâu năm trong cộng đồng Nostr và cũng từng làm extension cho Safari
Tôi chưa đọc bài báo đó, nhưng tôi nghĩ có những điểm bị hiểu sai hoặc nhầm lẫn về chính giao thức Nostr
Trong Nostr, khóa công khai chính là danh tính
Về mặt mật mã học, danh tính dựa trên khóa công khai là không thể giả mạo được (không tính lỗi triển khai)
Về mặt UX, việc xác minh “danh tính thật của chủ khóa công khai” là khó, nhưng đó là vấn đề khác với an toàn mật mã
Nói rằng “giao thức sự kiện không xác thực khóa công khai” là hoàn toàn vô lý
Phần lớn client và relay thực tế đều kiểm tra chữ ký
Với tư cách tác giả của Damus, tôi xin nói rõ đây là chuyện của phiên bản cũ — vấn đề đó đã được sửa
Ban đầu chỉ kết nối tới các relay đáng tin cậy, và các relay này có xác thực chữ ký
Chúng tôi còn tạo cả DB nhúng tên là nostrdb để tối ưu việc xác thực chữ ký
Nhận định rằng DM dùng CBC không xác thực nên dễ bị tấn công cũng không đúng
Toàn bộ note đều được bao phủ bởi chữ ký secp256k1
Tự động xem trước liên kết, hình ảnh v.v. đều có thể bật tắt, và nếu lo ngại thì nên dùng VPN
Tôi đã cố tìm xem Nostr dùng thuật toán khóa nào, nhưng không thấy tài liệu nào ghi trực tiếp
Tìm kiếm thì toàn dẫn tới nội dung về Blech32 (mã hóa khóa Bitcoin)
Xem tài liệu giới thiệu hellonostr.dev thì thấy bản thân encoding đã hàm chứa thông tin phiên bản
Trong định dạng
npub1abcxyz...,npublà header,1là phiên bản, phần sau là khóaXin tham khảo tài liệu liên quan
Các vấn đề được nêu thực tế либо phụ thuộc vào triển khai (ứng dụng không kiểm tra chữ ký, điều này phá vỡ bản chất của giao thức),
hoặc xuất phát từ cơ chế mã hóa tạm thời thời kỳ đầu (đã được thay bằng NIP44 v.v. và qua kiểm toán độc lập)
Hiện tại không có vấn đề nào mang tính chí mạng hoặc thực tế cần phải ứng phó ngay
Không hiểu sao đến giờ tôi mới nghe lần đầu về những vấn đề này
Cần được thảo luận nhanh chóng
Xét từ góc độ giao thức, tôi tò mò nền tảng liên hợp nào an toàn hơn: bluesky (at protocol) hay fediverse
Nhiều người hiểu nhầm rằng các relay Nostr tạo thành một liên hợp và chia sẻ tin nhắn với nhau
Thực tế không phải vậy
Nếu làm một bản sao Twitter, ứng dụng client phải tự tìm kiếm và đăng bài lên nhiều relay
và nếu không dùng relay chung thì sẽ không thấy bài của nhau
Nếu chỉ dùng một relay thì sẽ thành tập trung hoàn toàn,
còn nếu dùng nhiều relay thì chậm và phiền, người dùng còn phải tự biết nên kết nối relay nào
Tài liệu NIP cũng khá lộn xộn nên từng gây khó khăn cho việc bảo trì
Relay cũng có thể liên hợp được
Giao thức Nostr không hề quy định gì về việc có liên hợp hay không
Tôi đang vận hành một indexer (relay), và indexer này liên kết với các relay khác
Giống relay của ActivityPub, bất kỳ client nào cũng có thể kết nối tới indexer để bootstrap và tra cứu metadata sự kiện
Ngay cả khi không kết nối cùng một relay, các client vẫn có nhiều cách để trao đổi thông tin với nhau
Tôi nghĩ đây là một bài toán rất thú vị
Nếu ghi rõ relay đọc và ghi trong metadata hồ sơ như NIP65,
thì client có thể dễ dàng tìm được toàn bộ nội dung phù hợp
Ngoài ra còn nhiều ý tưởng khác đang được thử nghiệm
Tôi cho rằng đây là vấn đề có thể giải quyết được
Relay không sở hữu nội dung do người dùng tạo ra nên không cần liên hợp
Client thường phụ thuộc vào một tập relay do chính người dùng chọn
Dù vậy, khá nhiều relay lớn vẫn lưu cả sự kiện từ relay khác (một dạng liên hợp)
Ví dụ: Primal, TheForrest, nostr.land
nostr.land là relay trả phí, chủ yếu để lọc spam và tổng hợp note từ nhiều relay công khai
Nếu không muốn thì có thể chọn relay khác
Hiện đa số người dùng có thể xem hơn 99% số note nhờ kiểu liên hợp relay hiện tại, nhưng không thể kiểm chứng con số thực tế
Một số client và signer lưu note ở chế độ riêng tư,
và nếu relay kiểm duyệt note thì có thể phản ứng bằng cách đăng lại sang relay khác bất cứ lúc nào
Trên thực tế, nếu dùng relay trả phí phổ biến thì khá nhanh sẽ gặp cảnh báo “đã được đăng ở relay khác” trong 3/4 số sự kiện ghi
Cuối cùng, relay cũng tự đóng vai trò client, và nhờ vậy nó hữu ích như bộ nhớ đệm khi dùng di động hoặc mạng chậm
Mô hình outbox có vấn đề riêng, nhưng vì nhà phát triển client có thể cung cấp tùy chọn,
nên nó có thể mở rộng linh hoạt từ liên hợp tới P2P
Phần lớn client hỗ trợ outbox nên không cần dùng cùng một relay
Mỗi người dùng có thể có relay inbox và outbox riêng
Tài liệu NIP từng có những chỗ kỳ quặc
nhưng phần lớn NIP đang được cải thiện tốt,
và nếu có bản phát hành định kỳ chính thức thì đây chỉ là vấn đề nhỏ có thể xử lý
Nhiều nhà phát triển đang phản hồi rất nhanh
Sẽ tốt hơn nếu các dự án như thế này giải thích rõ ràng và tách bạch use case, triết lý và cách triển khai
Khi mới nhìn vào rất khó phân biệt đây là mạng xã hội hay là giao thức
“Nó hướng tới chống kiểm duyệt à? Có cần phải đọc bài blog không?”
Scuttlebutt, Mastodon, ActivityPub, Diaspora cũng y hệt vậy
Rốt cuộc “nó khác email ở chỗ nào?”, “so với Twitter thì tốt hơn gì?”
Trước khi hiểu ra thì đã thấy rối vì không biết đây là công nghệ triển khai, sản phẩm, website hay app
Có lẽ cũng chẳng mấy ai giải thích chính xác được Urbit là gì
Nhưng tôi vẫn thấy nó còn rõ ràng hơn “Web3”
Bluesky và Gemini thì tương đối rõ ở điểm này
Nostr là một giải pháp thỏa hiệp giữa cấu trúc P2P và kiến trúc web
Nó tận dụng web server để đi theo dòng chảy của Internet,
trong khi giúp người dùng giảm phụ thuộc vào server và tăng cường xác thực danh tính cũng như dữ liệu bằng khóa công khai/chữ ký
Kết quả là người dùng có được khả năng trao quyền kiểu như “credible exit”
Vì vậy, thay vì một use case mới, nó được gọi là “Internet mới”
Ở đây có những đánh đổi lấy người dùng làm trung tâm thay vì lấy nền tảng làm trung tâm (bao gồm cả khác biệt về mẫu UX)
Vì nó mang lại các giá trị tương tự khả năng chống kiểm duyệt của mạng xã hội hiện có,
nên trông có vẻ như nó có nhiều ứng dụng xã hội
Bạn nên thử tự làm một website như vậy
Việc dùng từ “apolitical” ở ngay dòng đầu mô tả sản phẩm nghe rất kỳ
Đồng thời lại có cả từ “open”, mà ở đây nó mang nghĩa chính trị rất rõ
Tôi không nhớ Nostr có liên hệ với tiền mã hóa hay không, nhưng hình như từng thấy khá lẫn lộn
Nostr không có “nostr coin”, cũng không có hành động onchain nào
Đó là điểm tôi rất thích
Đặc biệt vì tôi từng cảm thấy Nostr và cộng đồng tiền mã hóa gần như chồng lên nhau hoàn toàn
Có nhiều người dùng chủ yếu dùng Bitcoin
Cánh hữu từ lâu đã có lịch sử tự gọi mình là “apolitical”
Các dịch vụ có cấu trúc liên hợp/phân tán như Nostr, Mastodon, Discord
chỉ thực sự trở thành SNS phân tán nếu bản thân ứng dụng client tích hợp relay riêng để mọi người dùng đều đóng vai trò server
Phần mềm P2P cổ điển vốn đã làm như vậy và thực tế hoạt động tốt
Tuy nhiên, nếu người dùng ngẫu nhiên host cả dữ liệu mà chính họ không trực tiếp nhận được
thì sẽ nảy sinh vấn đề bị xử phạt vì nội dung bất hợp pháp (tương tự kiểu bị phát hiện tàng trữ ma túy trái phép ở sân bay)
Vì rủi ro này, cấu trúc P2P thế hệ tiếp theo sẽ cần AI để “lọc nội dung bất hợp pháp” (ví dụ: CP, phim)
Hoặc phải biến nó thành cộng đồng hoàn toàn khép kín
để nếu có chuyện xảy ra thì trách nhiệm chỉ nằm trong nội bộ cộng đồng
Cuối cùng thì mô hình mà mọi client đều là server vẫn là mô hình social phân tán tốt nhất
Dự án iroh hoạt động theo cách này
“Relay” chỉ đóng vai trò trung chuyển kết nối giữa hai client
Xem liên kết giải thích khái niệm iroh
Nghe thì hay, nhưng cấu trúc P2P thực tế lại không vận hành tốt
Ngay cả iroh cũng phụ thuộc relay ở bên trong
Nostr trao hẳn quyền thực thi chính sách cho relay (và có sẵn điều này mà không cần hack thêm)
Thật vui khi thấy Nostr lên top HN
Vẫn còn ở giai đoạn đầu, nhưng Nostr còn hỗ trợ cả “zapps” (thanh toán vi mô tức thời dựa trên Bitcoin-Lightning)
Đây là mô hình SNS phi tập trung không quảng cáo, cho phép thưởng vi mô trực tiếp cho nhà sáng tạo
mà không vướng vấn đề quảng cáo hay thuật toán
Có thể thưởng cả cho công việc PR của client Nostr bằng zaps
Xem ví dụ bounty liên quan
Bitcoin vốn đã bị quản lý rất chặt
Đọc các bình luận kiểu này khiến tôi muốn đăng ký, nhưng khi vào trang khám phá thực tế thì thấy mọi người đang giao dịch hàng hóa thật (máy móc, Kakao, giáo dục thay thế v.v.), điều đó khá ấn tượng
Nó không chỉ là kiểu “công khai nhật ký rồi xin tiền”
Đây là nền tảng dành cho hàng hóa, dịch vụ và nhà sáng tạo thực sự
Nostr đã tồn tại ít nhất từ 5 năm trước
Thời kỳ đại dịch cũng đã có nhiều người chuyển từ Twitter sang Nostr
Tôi khó đồng ý với cách gọi nó là chỉ mới ở giai đoạn đầu
Giới thiệu nhiều ứng dụng Nostr khác nhau
openux.app - dịch vụ thay thế Mobbin
kinostr.com - chat phim theo thời gian thực
zap.stream - livestream kiểu Twitch
dtan.xyz - torrent
zapstore.dev - app store không cần cấp phép
nostrnests.com - chat phòng âm thanh
zapmeacoffee.com - tương tự Buy Me A Coffee
asknostr.site
Theo cách này, một giao thức social phân tán có thể mở ra nhiều use case đa dạng,
và lợi ích từ góc nhìn người dùng là
Nostr không chỉ dùng như một dịch vụ microblogging, mà còn có nhiều ứng dụng ở tầng thấp hơn
Ví dụ: Trystero
dùng Nostr để thiết lập kết nối P2P WebRTC mà không cần server trung tâm
(giấy phép MIT)
Tôi cũng từng nghĩ tới việc phát tán đa kênh có khả năng chống kiểm duyệt bằng Nostr, Bittorrent DHT, Mastodon v.v.
Mục tiêu là chỉ khi tất cả phương thức đều thất bại thì mạng mới thực sự bị ngắt
Tương tự vậy, tôi cũng từng tự hỏi liệu Nostr hay ATProto
có thể dùng làm “kho lưu tin nhắn ngoại tuyến” cho trình nhắn tin tức thời P2P hay không
Dùng nó để thiết lập kết nối cũng là một cách rất mới mẻ
Ý tưởng thật sự rất tuyệt
Tôi cũng từng muốn làm thứ tương tự, nhưng thật may là đã có người làm trước nên tiết kiệm được thời gian
Tôi không hiểu vì sao các mạng xã hội mang tính kỹ thuật như thế này lại không đi theo hướng
các homepage cá nhân kết nối với nhau như web truyền thống
mà lại chuyển thành nền tảng dựa trên tài khoản riêng biệt
Ngoài RSS, tôi tò mò không biết đã từng có nỗ lực nào xây mạng khuyến khích vận hành website cá nhân
rồi chồng thêm social media tập trung như chat, feed v.v. lên trên hay chưa
Ở đây “tài khoản” thực chất là một cặp khóa công khai/bí mật
Bạn cũng có thể tự vận hành relay của mình,
và với cùng một khóa công khai có thể dùng bất kỳ relay nào
Bài đăng cũng có thể broadcast tới mọi relay bạn muốn
Nếu thích thì mỗi bài đăng có thể tạo một khóa mới
Các hệ như Mastodon thì tài khoản gắn với server nên kém tính di động và tự do hơn
Tuy nhiên, cũng có vấn đề là hoàn toàn không có cách khôi phục tài khoản
Có lẽ nên tham khảo RSDS(Really Simple Decentralized Syndication)
Nói chung nostr chính là kiểu cấu trúc đó
Chỉ là thay website bằng kiểu dữ liệu “note”, và thay server bằng “relay”
Tôi muốn hỏi vì sao bạn lại cho rằng đây “rõ ràng là dịch vụ dành cho dân kỹ thuật”
Có phải đang tự suy diễn ý định trong đầu nhà sáng lập không
Về bản chất, hiện đã có thể kết hợp nhiều công nghệ để tự xây hệ thống homepage cá nhân/chat/feed
Nhưng vấn đề thực tế của mô hình lai như vậy là
Khi cố giải cả đống này cùng lúc thì tất yếu phải có những đánh đổi
Phi tập trung hoàn toàn là sự đánh đổi với khả năng khám phá và mức độ tiếp cận
Lập luận kiểu “không còn cần tài khoản nữa” cũng vướng vào vấn đề đa danh tính online/offline
Cuối cùng đây là câu chuyện chọn giá trị, và nhiều dịch vụ phân tán mang tính thử nghiệm được giới kỹ thuật ưa chuộng (ví dụ Mastodon, Nostr, Smolweb)
đều mang ảnh hưởng của tư duy Internet thời kỳ đầu: phản văn hóa, mở, tiêu chuẩn hóa, tính kết hợp
Không thể có giải pháp làm hài lòng tất cả mọi người,
nên tôi nghĩ giá trị cốt lõi của Internet là sự đa dạng, tiêu chuẩn hóa và tính mở
“apolitical communication commons”
Có người chỉ ra rằng chính cái nhãn “phi chính trị”
tự nó đã là một phát ngôn chính trị và là một lập trường quyền lực
Tôi thắc mắc vì sao nỗi sợ “chính trị” lại lớn đến vậy
Họ lấy nguyên tắc cơ bản của Hy Lạp cổ đại rằng tham gia chính trị là nghĩa vụ hiển nhiên của một công dân làm ví dụ
Thực tế, từ nguyên của từ
idiotlà để chỉ người phi chính trịKhái niệm “apolitical”
trên thực tế thường bị hiểu là im lặng dưới chế độ độc tài và ngầm ủng hộ trật tự hiện tại
Ở các chế độ độc tài như Nga, đó là con đường tắt dẫn tới đàn áp và bóp nghẹt tự do
Những dịch vụ như Nostr từng bị ngăn chặn theo kiểu chính phủ tuyên bố “vận hành relay là bất hợp pháp/tội phạm”
“Nếu mọi thứ đều là chính trị, thì chính trị chẳng còn là gì cả”
Có vẻ tác giả chỉ muốn tránh những tranh cãi phi kỹ thuật
Cũng có thể hiểu “apolitical” theo nghĩa ai cũng được chào đón
Rào cản duy nhất để tham gia chỉ là kết nối Internet
Có lẽ từ đó được dùng trong bối cảnh phản ứng lại xu hướng kiểm duyệt trên SNS suốt 10 năm gần đây
Một số người cũng cho rằng nên “dùng đặc quyền từ vị thế của mình để giúp đỡ người khác”
và điều đó cũng có thể áp dụng ở đây