BlueSky hoạt động như thế nào

 (steveklabnik.com)
2 điểm bởi GN⁺ 2024-02-26 | 1 bình luận | Chia sẻ qua WhatsApp
  • BlueSky là một ứng dụng microblogging tương tự Twitter và Mastodon, nhưng mục tiêu lớn hơn là kiểm chứng liệu có thể xây dựng các ứng dụng xã hội phân tán quy mô lớn trên AT Protocol(atproto) hay không
  • atproto không phải blockchain, DAO hay NFT; đây là một giao thức liên hợp sử dụng mật mã học và Merkle tree để PDS, Relay và App View cùng xử lý các bản ghi do người dùng ký
  • Khả năng mở rộng đến từ cấu trúc trong đó Personal Data Server(PDS) của người dùng không gửi trực tiếp bài đăng đến tất cả người theo dõi, mà Relay thu thập dữ liệu mạng và cung cấp dưới dạng firehose
  • Việc điều phối được chia theo mô hình “speech vs reach”; bằng cách tách riêng sao chép nội dung và kiểm soát phạm vi hiển thị, labeler, feed generator và App View áp dụng lọc và chặn
  • DID ổn định và handle dựa trên tên miền mang lại khả năng di chuyển tài khoản, nhưng dịch vụ phân giải did:plc do BlueSky vận hành vẫn là một điểm gây tranh luận về tính tập trung

Mối quan hệ giữa BlueSky và atproto

  • BlueSky hiện hoạt động như một ứng dụng microblogging, nhưng trong bức tranh tổng thể, nó là ứng dụng ban đầu nhằm chứng minh tiềm năng của Authenticated Transfer Protocol, tức atproto
  • Trang web BlueSky nói rằng “mạng xã hội quá quan trọng để chỉ do một vài công ty kiểm soát, và chúng tôi đang xây dựng nền tảng mở cho một internet xã hội nơi mọi người đều có thể kiến tạo tương lai”
  • Vì BlueSky là một công ty, có thể tồn tại góc nhìn hoài nghi rằng “một công ty đang tạo ra thứ không nên bị công ty kiểm soát”, nhưng trọng tâm thiết kế nằm ở atproto hơn là ứng dụng
  • atproto là một giao thức liên hợp dành cho các ứng dụng xã hội phân tán quy mô lớn

Giao thức phân tán, không phải tiền mã hóa

  • Do dùng các cụm từ như “mạng phân tán” và “giao thức”, atproto có thể trông giống tiền mã hóa, nhưng không phải tiền mã hóa
  • Nó không phải blockchain, DAO hay NFT; chỉ sử dụng một số kỹ thuật như mật mã học và Merkle tree

Cấu trúc cơ bản của atproto

  • atproto chọn cấu trúc liên hợp, trong đó nhiều chủ thể vận hành các phần khác nhau của hệ thống và giao tiếp với nhau
  • Với cơ sở người dùng quy mô lớn trong tâm trí, nó được thiết kế theo hướng giao nhiều vai trò hơn cho các chủ thể có thể chịu tải, đồng thời giảm gánh nặng cho các chủ thể không thể
  • Tính đến thời điểm bài viết, BlueSky đã vượt 5 triệu người dùng trong tuần đó và được đánh giá là ổn định hơn nhiều so với Twitter thời kỳ đầu
  • Hiện atproto dựa trên nền tảng 100% công khai, chưa có các tính năng như tin nhắn riêng tư
    • Vì trong một hệ thống liên hợp rất khó triển khai đúng các tính năng riêng tư, đây là lựa chọn triển khai cho đúng thay vì tung ra một tính năng có những lưu ý nghiêm trọng
    • Hiện tại, nó phù hợp để dùng cho những nội dung có thể công khai

Record, repository, App View, Relay

  • Người dùng tạo record được ký bằng mật mã, và chữ ký này chứng minh tác giả
  • record tuân theo một schema gọi là Lexicon
  • record được lưu trong repository, và kho lưu trữ này hoạt động như một dịch vụ phơi bày HTTP và WebSocket
    • Dịch vụ như vậy thường được gọi là PDS(Personal Data Server)
    • Người dùng có thể tự vận hành PDS, hoặc dùng PDS do người khác lưu trữ
  • Ứng dụng đọc các record được lưu trên mạng và xây dựng chức năng bên trên chúng
    • Vì các dịch vụ như vậy phơi bày một góc nhìn thông tin cụ thể, chúng được gọi là App View
    • Tạo một ứng dụng nghĩa là định nghĩa Lexicon, đọc các record dùng Lexicon đó và bỏ qua phần còn lại
  • Cách các PDS gửi thông báo trực tiếp cho nhau gặp vấn đề lớn về khả năng mở rộng
    • Nếu mỗi lần đăng bài mới đều phải gửi trực tiếp đến repository của mọi người theo dõi thì sẽ kém hiệu quả, và chi phí vận hành các repository phổ biến sẽ tăng cao
  • Relay thu thập thông tin mạng và phơi bày dưới dạng firehose để giảm vấn đề này
    • App View thực tế xem Relay hơn là xem trực tiếp repository
    • Khi người đăng đưa bài lên, repository thông báo cho Relay, và người theo dõi thấy kết quả App View đã lọc từ đầu ra của Relay
    • Relay có thể lớn và tốn kém để vận hành, nhưng cũng có thể hình dung các Relay nhỏ hơn chỉ lan truyền một tập con người dùng cụ thể

Mô hình điều phối “speech vs reach”

  • Vì atproto là giao thức cho ứng dụng xã hội, nó không chỉ xem xét cách kết nối con người mà còn cả cách ngắt kết nối
  • Mô hình điều phối của BlueSky được chia thành speech vs reach
    • Tầng speech chịu trách nhiệm sao chép nội dung trên mạng mà không xét đến ý nghĩa nội dung
    • Tầng reach cung cấp công cụ để hạn chế phạm vi tiếp cận của những thứ người dùng không muốn thấy
  • Nói rằng BlueSky “không điều phối” hoặc “chỉ coi trọng tự do ngôn luận” là không chính xác
    • Công cụ điều phối nằm trong chính giao thức và có thể hoạt động cả với nội dung của các ứng dụng không phải BlueSky
    • Người dùng không bị phụ thuộc vào lựa chọn điều phối hoặc sự thiếu điều phối của người khác, mà có thể chọn người điều phối của riêng mình

Feed generator

  • Trong atproto, feed được tách thành một dịch vụ riêng gọi là feed generator
  • feed generator nhận firehose do Relay tạo, rồi lọc và sắp xếp nội dung theo tiêu chí mong muốn để hiển thị danh sách
  • Người dùng có thể chia sẻ feed do mình tạo với người dùng khác
  • Ví dụ về feed:
    • Quiet Posters: hiển thị bài đăng của những người không đăng thường xuyên
    • the ‘Gram: chỉ hiển thị bài đăng có đính kèm ảnh
    • My Bangers: hiển thị các bài đăng nổi bật của chính mình
  • Một trong những điểm mạnh của BlueSky là người dùng có thể tạo feed thuật toán của riêng mình và dễ dàng chia sẻ
  • feed là tính năng được thêm vào atproto tương đối gần đây nên có thể chưa hoàn chỉnh, và có thể thay đổi trong tương lai

Labeler và điều phối cấp mạng

  • Labeler là dịch vụ gắn label cho nội dung hoặc tài khoản
  • Người dùng đăng ký theo dõi một labeler cụ thể, và trải nghiệm có thể thay đổi tùy theo label của bài đăng
  • labeler có thể hoạt động theo cách nhà vận hành mong muốn
    • Có thể chạy thuật toán tự động trên bài đăng
    • Có thể để con người trực tiếp duyệt hoặc từ chối
    • Có thể dùng làm danh sách chặn hoặc bộ lọc NSFW
  • Tính năng label đã tồn tại, nhưng tại thời điểm viết bài chưa rõ người dùng có thể tự chạy labeler hay không
    • BlueSky vận hành labeler riêng
    • Chưa có bản phát hành bên ngoài nào được biết đến
  • Khi kết hợp feed, App View và labeler, người dùng có thể chọn trải nghiệm điều phối trong và ngoài ứng dụng
    • Ở một feed chỉ xem SFW, còn ở nơi khác có thể cho phép nội dung NSFW
    • Có thể tạo và chia sẻ danh sách chặn
  • Vì công cụ điều phối hoạt động ở cấp giao thức chứ không phải ở cấp ứng dụng, các ứng dụng khác trên atproto cũng có thể dùng cùng labeler
    • Ngay cả khi một bản sao Instagram được xây dựng trên atproto, vẫn có thể dùng cùng labeler danh sách chặn
    • Nếu muốn, người dùng bị chặn ở một nơi có thể bị chặn ở mọi nơi

Khác biệt với mô hình instance kiểu Mastodon

  • Mô hình atproto khác với cách Mastodon có “tài khoản” trên một “instance” cụ thể
  • Những câu hỏi như “nếu instance của tôi bị defederate thì sao” khó có thể áp dụng nguyên xi
  • Có thể đạt mục tiêu tương tự bằng cách bỏ qua các bài đăng đến từ một PDS cụ thể nếu không thích
  • Tuy nhiên, lựa chọn đó không phải do chủ sở hữu máy chủ quyết định thay cho tài khoản của người dùng, mà là lựa chọn của chính người dùng

DID, handle và khả năng di chuyển tài khoản

  • Trọng tâm định danh của atproto là DID(Decentralized Identifier)
    • DID ví dụ có dạng did:plc:3danwc67lo7obz2fmdg6jxcr
  • Định danh mà người dùng thực sự nhìn thấy còn dùng kèm handle, và handle là tên miền
    • Ví dụ: @steveklabnik.com
    • Người đăng ký BlueSky có thể nhận handle dạng @username.bsky.social
  • Vì DID ổn định, ngay cả khi đổi handle từ @steveklabnik.bsky.social sang @steveklabnik.com, người theo dõi không bị gián đoạn và chỉ handle trong UI thay đổi
  • Để dùng tên miền làm handle, lấy DID do PDS tạo và thêm TXT record vào DNS của tên miền đó
  • Ngay cả người dùng không biết DNS cũng có thể đăng ký tên miền và đặt làm handle mà không cần kiến thức kỹ thuật thông qua hợp tác giữa BlueSky và NameCheap
  • Khả năng di chuyển tài khoản dựa trên DID và chữ ký mật mã
    • Nội dung do người dùng của một DID cụ thể tạo ra được ký và sao chép trên mạng
    • Để “đóng” một tài khoản, cần buộc ngăn việc sử dụng khóa mà người dùng nắm giữ, nhưng theo thiết kế mạng, các chủ thể khác không truy cập khóa đó
    • Ngay cả khi PDS ngừng hoạt động, nội dung vẫn có thể được backfill từ mạng và có thể thông báo rằng người dùng đã chuyển sang PDS mới

Các điểm tranh luận về did:web và did:plc

  • BlueSky hỗ trợ hai phương thức DID
    • did:web: phương thức dựa trên tên miền
    • did:plc: phương thức riêng do BlueSky triển khai
  • plc trong did:plc nghĩa là “placeholder”, và BlueSky dự định tiếp tục hỗ trợ nó
  • Điểm yếu của did:plc là phải phân giải thông tin đúng thông qua dịch vụ do BlueSky vận hành
    • Có thể tra cứu ví dụ tại plc.directory
    • Vì cấu trúc này, có phê bình cho rằng BlueSky có thể ban người dùng mạnh hơn so với mức vốn có thể theo thiết kế mạng
  • Cũng có các lý do để không coi vấn đề này là chí tử
    • Nếu không muốn, có thể dùng did:web
    • Hệ thống được thiết kế để có thể di chuyển khi có hệ thống tốt hơn xuất hiện
    • Trong tương lai có thể chuyển quản trị did:plc sang mô hình đồng thuận
    • Chủ thể khác cũng có thể vận hành dịch vụ did:plc và dùng dịch vụ đó

Cách BlueSky chạy trên atproto

  • BlueSky là ứng dụng được xây dựng trên mạng atproto
  • BlueSky vận hành App View và ứng dụng web sử dụng nó
  • BlueSky cũng vận hành PDS cho người dùng đăng ký qua web app, và vận hành Relay để các PDS đó giao tiếp
  • BlueSky phát hành hai loại Lexicon
    • com.atproto.*: các thao tác cấp thấp cần thiết cho bất kỳ ứng dụng nào trên mạng
    • app.bsky.*: các thao tác dành riêng cho BlueSky
  • Mục tiêu sản phẩm của BlueSky là để người dùng có thể sử dụng mà không cần biết những chi tiết kỹ thuật này
    • Vì không có instance, không có luồng chọn instance để tạo tài khoản
    • Ngay cả khi host ngừng hoạt động, người dùng vẫn có thể di chuyển, và người theo dõi không cần nhận ra điều đó

Tạo ứng dụng mới trên atproto

  • Một ứng dụng atproto bắt đầu bằng việc tạo Lexicon
  • Sau đó vận hành App View xử lý dữ liệu liên quan đến Lexicon đó trong dữ liệu của mạng
  • Ứng dụng cần cho phép người dùng ghi dữ liệu vào PDS của mình bằng Lexicon đó

Sự tách biệt cốt lõi trong thiết kế

  • Việc tách vai trò giữa atproto và BlueSky là một yếu tố thiết kế quan trọng
  • Một “killer app” như BlueSky cung cấp lý do để sử dụng mạng
  • Bản thân BlueSky cũng đóng vai trò dogfooding, kiểm chứng liệu có thể xây dựng một ứng dụng thực tế trên atproto hay không

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-02-26
Các ý kiến trên Hacker News

  • Có vẻ được thiết kế rất tốt, và dường như giải quyết được một phần những vấn đề lớn của ActivityPub
    Trước đây tôi không quan tâm đến Bluesky, nhưng giờ thì bắt đầu nghĩ đến việc tạo tài khoản

    • Vấn đề chính của Bluesky và AT Protocol nằm ở thái độ NIH (Not invented here) mạnh mẽ hơn là ưu điểm kỹ thuật
      Thay vì dùng các giao thức sẵn có như user@host và WebFinger mà mọi người đều dùng, họ chọn “dùng tên miền làm danh tính”, và không tham khảo cách ACME đã xử lý trong chứng chỉ, nên đã xảy ra chuyện có người chiếm tên miền s3.amazon.com trên Bluesky https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
      Họ còn tạo giao thức gọi từ xa mới là XRPC, và dùng Lexicon, một schema dữ liệu dựa trên sinh mã mà ngoài việc mới hơn protobuf hay jsonld thì lợi thế không rõ ràng
      Thật khó tin tưởng một “mạng mở” liên tục thể hiện rằng họ không muốn tôn trọng hay đối thoại với các hệ sinh thái khác; cũng đáng nghi là khi từ chối tri thức chung như vậy, còn bao nhiêu lỗi thiết kế phổ biến nữa đã lọt vào
    • AT Protocol trông tốt hơn về mặt kỹ thuật, nhưng về mặt xã hội thì có vẻ là một cấu trúc dễ thất bại
      Không có động lực xã hội để ai đó cài đặt và duy trì các relay và dịch vụ điều phối tách rời khỏi cộng đồng thực sự; cuối cùng chỉ còn lại các động lực tiền bạc như dịch vụ trả phí, chèn quảng cáo, khai thác dữ liệu, thao túng thông tin
      Nếu việc phân phối dữ liệu và điều phối bị tập trung hóa, cả chi phí hosting lẫn chi phí nhân sự đều trở thành một mảng kinh doanh lớn, và trên thực tế sẽ đi theo hướng ngăn bất kỳ ai ngoài Bluesky vận hành relay hay dịch vụ điều phối riêng
      Bất chấp nhược điểm của ActivityPub, cách tiếp cận kiểu “cộng đồng có cổng” giúp người dùng cảm thấy thuộc về một máy chủ, còn người vận hành và điều phối viên có niềm tự hào rằng họ đang cung cấp dịch vụ cho người dùng
      AT Protocol về mặt kỹ thuật cho phép nhiều relay và dịch vụ điều phối, nhưng trong thực tế sẽ có bao nhiêu cái xuất hiện thì còn là dấu hỏi
      Tôi cho rằng đánh giá một giao thức mạng xã hội chỉ từ góc nhìn thuần kỹ thuật và đối kháng là sai lầm. Đổi lại việc không bị phụ thuộc vào máy chủ, nó cũng bị tách khỏi các cộng đồng gắn kết, và không còn thứ gì thực sự bị ràng buộc nữa
      Việc không có gì để mất về dữ liệu, danh tính và cộng đồng là con dao hai lưỡi

  • Theo tôi biết hiện tại chỉ có một relay
    Nếu có nhiều relay, mỗi relay sẽ nhìn thấy mạng theo cách khác nhau, và relay bao gồm nhiều bài đăng hơn sẽ là relay tốt hơn
    Việc bảo đảm sự đa dạng relay thay vì một relay thống trị duy nhất có thể khá khó, trông giống nỗ lực của các hệ thống DNS thay thế nhằm đạt được traction. Khi đó, nếu bài đăng của tôi không được relay thống trị bắt được thì dường như không còn cách nào
    Dù sao vẫn còn rất sớm nên có thể sẽ không thành như vậy; và ngay cả khi có một relay thống trị thì GitHub cũng không tệ đến thế, và vẫn có lựa chọn thay thế

    • Trước đây tôi thấy Bluesky khá khó hiểu, nhưng gần đây nhận ra chủ yếu là vì thuật ngữ
      Nếu gọi hệ thống là [microblog] -> [indexer] -> [client] thì sẽ dễ hiểu hơn
      Thực tế có nhiều thành phần hơn, nhưng cách hoạt động cơ bản của Bluesky đại khái là như vậy, chỉ là tên gọi được đặt khác với dự đoán
      Lý do cần indexer là ID người dùng không được giữ tĩnh trong hệ thống. DID:PLC ban đầu bắt đầu bằng một chuỗi con của hash, rồi do “xoay vòng khóa” mà theo thời gian xảy ra một sự tái sắp xếp mật mã học kỳ lạ, khiến ID người dùng thay đổi mà chính người dùng cũng không biết
      Hãy hình dung một hệ thống giống LiveJournal nhưng handle liên tục thay đổi, và cần một bên có thẩm quyền để theo dõi những thay đổi đó. Tất nhiên, chỉ có thể đăng thông điệp ngắn, không hỗ trợ tiêu đề hay Markdown
      Cá nhân tôi đang chờ một DID:PLC mới, nhận khóa công khai tĩnh và ký thông điệp bằng khóa riêng. Khi đó sẽ có ít thứ phải theo dõi hơn nhiều, và việc tự host cũng như phát triển local-first có vẻ sẽ dễ hơn nhiều
    • Tôi nghĩ nếu cần, App View, tức client, có thể dùng song song nhiều relay
      Nó giống một UI GitHub cục bộ lấy dữ liệu từ nhiều instance GitHub đang host các tập repository khác nhau nhưng có thể chồng lấn
      Cũng tương tự client Usenet gom và hiển thị newsgroup từ nhiều máy chủ NNTP
    • Tôi dự đoán tất cả relay sẽ có cấu trúc nắm toàn bộ dữ liệu, ngoại trừ khác biệt trong phán đoán về nội dung bất hợp pháp
      Tôi tò mò vì sao bạn nghĩ mỗi relay sẽ nhìn thấy mạng theo cách khác nhau

  • Điều tôi thắc mắc là BlueSky có thể cam kết một cách đáng tin cậy rằng họ sẽ chỉ dùng phần mở của giao thức như thế nào
    BlueSky trên thực tế trông khá tập trung, nên dường như không có lý do kỹ thuật nào bắt buộc client bên thứ nhất phải là client ATProto
    Trong ngắn hạn hoặc trung hạn, làm vậy sẽ là sự phản bội lớn đối với niềm tin của người dùng, nhưng cấu trúc phân tán trên thực tế của ActivityPub có vẻ là một cơ chế bảo vệ mạnh hơn trong trường hợp này

    • Tôi không rõ client BlueSky bên thứ nhất nghĩa là gì
      Nếu ý bạn là relay và PDS bên thứ nhất có thể giao tiếp bằng một giao thức khác, thì tôi không hiểu rõ bạn đang lo điều gì
      Hai client ActivityPub cũng có thể nói chuyện với nhau bằng một giao thức không phải ActivityPub
    • Có thể tin tưởng vì toàn bộ mã đều là mã nguồn mở
      Thực tế họ đang làm như vậy, và nếu họ bắt đầu đổi sang hướng không làm vậy, mọi người sẽ nhận ra rất nhanh

  • Việc đi đến chỗ phân biệt giữa “phát ngôn và phạm vi tiếp cận” là tốt, nhưng về dài hạn, vì sự đơn giản, Mastodon có vẻ là lựa chọn thông minh hơn
    Trong ngắn hạn, việc tuyển chọn feed của Mastodon chắc chắn khó hơn, nên có thể kém thú vị hoặc kém hữu ích hơn
    Câu hỏi cốt lõi là: nếu một tác nhân xấu giả định, có lẽ giàu có hoặc có quyền lực, muốn khuấy đảo cuộc chơi ở đây thì họ có thể làm thế nào
    Bài viết lướt qua phần này quá hời hợt theo kiểu “không rõ feed hoạt động thế nào”, nên rất đáng nghi. Có vẻ như họ biết rõ feed sẽ hoạt động ra sao, cũng biết rằng quyền lực và tiền nằm ở điểm đó, nên đang cố nắm lấy nó

    • Tóm tắt rằng “không rõ feed hoạt động thế nào” có vẻ không phù hợp
      Tác giả nói thế này: “Feed là một tính năng mới được thêm vào atproto gần đây, nên tuy đã tồn tại nhưng có thể chức năng vẫn chưa hoàn thiện, và cũng có thể thay đổi trong tương lai. Hãy chờ xem. Theo góc nhìn của tôi thì nó hoạt động tốt, nhưng tôi không theo sát đến tận các chi tiết kỹ thuật cấp thấp.”
      Ngay đoạn phía trên cũng có ngữ cảnh như sau: “Một trong những tính năng sát thủ của BlueSky so với các công cụ microblog khác là quyền lựa chọn hoàn toàn của người dùng. Nếu tôi muốn tự tạo thuật toán feed thì có thể tạo, và có thể dễ dàng chia sẻ với người khác.”
    • Không rõ phần nào hàm ý là không biết cách feed hoạt động
      Feed là mã nguồn mở, hiện đã tồn tại, và bạn cũng có thể tự chạy
      Cũng không rõ “khuấy đảo cuộc chơi” là nói đến cuộc chơi nào và theo nghĩa gì. Ở đây có nhiều bộ phận đang vận hành

  • Ý tưởng rằng nếu người dùng chọn một nhà cung cấp kiểm duyệt độc lập với nhà cung cấp hosting thì sẽ bớt phải lo về việc chọn instance trông khá hay
    Tuy vậy, có lẽ instance vẫn phải kiểm duyệt để không host nội dung bất hợp pháp tại địa phương
    Rốt cuộc đây sẽ là việc khá khó với những người vận hành instance, và có thể dẫn tới khá nhiều hỗn loạn. Cũng có thể tôi đã hiểu nhầm

    • Người host nội dung phải xử lý hệ quả pháp lý của nội dung mình host, và rốt cuộc không thể tránh được
      Nhưng dù dùng giao thức nào thì chuyện này cũng như nhau
    • Bạn không hiểu nhầm đâu. Tôi cho rằng tính phi tập trung của Bluesky gần như là giả
      PDS chỉ cần một máy Ubuntu vừa phải là đủ, nhưng ngay cả bài này cũng thừa nhận relay là một điểm kiểm soát tập trung đắt đỏ và khổng lồ
      Kế hoạch chống spam của Bluesky là gì? Có lẽ là chặn ở relay
      Máy chủ DID cũng là một điểm kiểm soát tập trung khác
      Dù vậy, bạn vẫn có thể chạy PDS tùy ý

  • Một mẩu trivia thú vị về Bluesky, nếu liên hệ với bài viết cách đây không lâu thì cái tên này cũng có thể xem là lấy từ tên người
    Tên của CEO trong tiếng Trung nghĩa đen là blue sky

    • Thú vị là Twitter đã đặt tên dự án là bluesky trước khi tôi tham gia
      Đó là ngẫu nhiên. Nhưng tên đệm của tôi trong tiếng Trung có nghĩa là bluesky

  • Truyện tranh ngắn này cũng hay: https://bsky.social/about/welcome-to-bluesky-comic

  • Nếu Bluesky ngừng hỗ trợ did:plc, có phải toàn bộ danh tính PLC hiện có sẽ hỏng không?
    Tôi thắc mắc vì PLC có cấu trúc ping tới dịch vụ bên đó

    • https://plc.directory có thể được mirror, và nếu chuyện đó xảy ra thì mirror mới có thể trở thành máy chủ có thẩm quyền

  • Tôi hoài nghi về labeler bên thứ ba
    Làm sao ngăn bị lạm dụng?

    • Người dùng chọn sẽ đăng ký labeler bên thứ ba nào
      Nếu dịch vụ labeler bắt đầu lạm dụng vị thế của mình thì người dùng chỉ cần ngắt đăng ký
      Có giải thích chi tiết về cách Bluesky muốn đưa labeler vào hệ sinh thái tại https://github.com/bluesky-social/proposals/tree/main/0002-l...
    • Câu trả lời sẽ khác nhau tùy bạn nói đến loại lạm dụng nào
      Tôi có thể nêu quan điểm, nhưng câu hỏi quá rộng nên không biết nên bắt đầu trả lời từ đâu
    • Sắp tới chúng tôi sẽ công bố nhiều hơn về kiểm duyệt, nhưng nền tảng cơ bản của labeler là như thế này
      Bất kỳ ai trong mạng cũng có thể gắn nhãn bất cứ thứ gì, bao gồm cả các labeler khác
      Ứng dụng có thể hiển thị các labeler để người dùng đăng ký, giống như feed tùy chỉnh của Bluesky hiện nay
      Ứng dụng cũng có thể tuyển chọn cách labeler được hiển thị và xếp hạng, giống như cách chúng hiển thị và xếp hạng feed tùy chỉnh theo mức độ phổ biến hiện được thể hiện bằng lượt thích và lưu

  • Cách tiếp cận rằng “công cụ kiểm duyệt thuộc tầng phạm vi tiếp cận. Nó lấy mọi phát ngôn, nhưng cung cấp cách hạn chế phạm vi tiếp cận của những thứ tôi không muốn thấy” rốt cuộc trông giống kiểu kiểm duyệt “không muốn thấy thì nhắm mắt lại”
    Tôi biết đây là triết lý được ưa chuộng ở Silicon Valley, nhưng về cơ bản tôi cho rằng nó có khiếm khuyết
    Có những tình huống chính đáng cần ngăn những người không liên quan khác nói về một vấn đề cụ thể hoặc lấy được nội dung cụ thể
    Ví dụ điển hình là quấy rối trên mạng, doxxing và revenge porn. Chẳng hạn hai người trở lên bàn cách làm hại một bên thứ ba, hoặc công khai thông tin riêng tư, mang tính xúc phạm hay sai sự thật
    Việc gỡ thông tin này khỏi feed của nạn nhân là hoàn toàn vô ích, và ngay từ đầu nó có thể cũng sẽ không xuất hiện trên feed của nạn nhân. Thiệt hại đến từ việc người khác nhìn thấy nội dung đó hoặc tham gia thảo luận, nhưng thiệt hại ấy là có thật
    Trong các hệ thống kiểm duyệt truyền thống, người kiểm duyệt có thể xóa bài viết khỏi tất cả mọi người hoặc chặn kẻ gây hại để dừng hành vi này. Trong hệ thống “chỉ ẩn nội dung” thì điều này là không thể
    Danh sách chặn dùng chung hay “nhãn” cũng không hiệu quả. Người tiêu thụ nội dung không có động cơ chặn nó, trái lại còn muốn xem revenge porn
    Người muốn chặn là nạn nhân, nhưng nạn nhân không có quyền buộc mọi người dùng một danh sách chặn cụ thể. Bởi cốt lõi của hệ thống này là không ai có thể ép người khác dùng danh sách chặn

    • Lĩnh vực này sẽ còn có thêm nhiều điều được đưa ra trong tương lai. Bài viết này tập trung vào các trường hợp bình thường và không đề cập đến các trường hợp xấu
      Đội ngũ đã xem xét những vấn đề này và “cũng đã tham vấn chuyên gia”, nhưng vì đây vẫn là công việc đang tiếp diễn nên tôi không cảm thấy mình đủ tư cách để nói
      Phần “nhãn không hiệu quả vì mọi người muốn xem nó hơn là ngăn nó” nằm trong không gian vấn đề mà đội ngũ đã thừa nhận rõ ràng
      Xem thêm ở đây: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei