atproto không có instance

 (overreacted.io)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Câu hỏi tìm “instance của Bluesky” là việc áp nguyên mô hình instance của Mastodon sang atproto, trong khi atproto được thiết kế tách biệt giữa lưu trữ và tổng hợp ứng dụng
  • Giống như RSS và Google Reader, dữ liệu không bị nhốt trong ứng dụng mà nằm trong kho lưu trữ được host, và nhiều ứng dụng sẽ lấy dữ liệu đó để hiển thị
  • Instance của Mastodon là cấu trúc gói chung hosting, ứng dụng, danh tính và quan hệ liên hợp vào một hộp, nên quyết định của quản trị viên hay sự cố instance sẽ ảnh hưởng trực tiếp đến trải nghiệm người dùng
  • Trong atproto, người dùng có thể chuyển nơi lưu trữ hoặc tạo và dùng thử ứng dụng mới; các ứng dụng như Tangled, Semble, Sidetrail hoạt động tách biệt với Bluesky
  • Muốn nhìn thấy tính phân tán của atproto, thay vì hỏi có bao nhiêu instance Bluesky, cần xem liệu việc chuyển sang hosting thay thế và hệ sinh thái ứng dụng mới có thực sự vận hành hay không

Mô hình gần với RSS và Google Reader hơn

  • Trong thời kỳ RSS, người dùng đăng bài lên blog của riêng mình, còn các ứng dụng như Google Reader hay Feedly sẽ tổng hợp bài viết từ nhiều blog
  • Bài viết không “sống” bên trong Google Reader mà vẫn nằm trên blog hoặc nơi host của từng người
  • Điểm cốt lõi là tách biệt giữa hosting và tổng hợp
    • Hosting là nơi nội dung thực sự tồn tại
    • Ứng dụng tổng hợp gần giống một phép chiếu (projection) hiển thị nội dung từ nhiều nguồn

Mạng xã hội tập trung và cách Mastodon ứng phó

  • Mạng xã hội truyền thống vận hành theo cách gom mọi người dùng vào trong một ứng dụng và một không gian duy nhất
  • Cấu trúc này tạo ra sự tập trung hóa và hiệu ứng mạng mạnh, và thảo luận về mạng xã hội phân tán bắt đầu từ bài toán làm sao tách nhỏ vấn đề đó
  • Cách tiếp cận kiểu Mastodon là mỗi cộng đồng vận hành một “Facebook nhỏ” hoặc “Twitter nhỏ” của riêng mình, và chiếc hộp đó chính là instance

Những gì Mastodon gói vào instance

  • Người dùng thuộc “bên trong” một instance cụ thể
    • Lý do định dạng đăng nhập Mastodon là [email protected] cũng vì instance là một phần của danh tính
    • Người dùng không phải một “Alice” trừu tượng, mà là “Alice của instance #1”
  • Để người dùng ở các instance khác nhau giao tiếp, các instance phải gửi nhận thông điệp với nhau
    • Khi Alice ở instance #1 và Bree ở instance #2, nếu Alice theo dõi Bree thì bài viết của Bree sẽ được chuyển tới instance #1
    • Quan hệ chuyển tiếp đó chính là liên hợp (federation)
  • Vì hosting và ứng dụng bị buộc chung với nhau, người dùng trở nên phụ thuộc mạnh vào instance

Các ràng buộc do sự gắn chặt vào instance tạo ra

  • Khi phát sinh xung đột giữa các quản trị viên instance, họ có thể ngừng liên hợp với nhau
    • Khi đó người dùng có thể không còn nhìn thấy bài viết của bạn bè nữa
  • Nếu instance của người dùng ngừng hoạt động, danh tính gắn với instance đó cũng biến mất
    • Vì người theo dõi thực chất đang theo dõi “người dùng của instance đó”
  • Các mũi tên kết nối giữa các instance tăng theo O(n²)
    • Hiện tại có thể chưa phải vấn đề lớn, nhưng sẽ trở nên quan trọng nếu kiểu mạng xã hội này phổ biến hơn

Khác biệt cốt lõi của atproto

  • atproto không lấy khái niệm instance kiểu Mastodon làm tiền đề, mà quay về mô hình RSS và Google Reader
  • Ở cấp độ mạng lưới, nó tách riêng hosting và tổng hợp
    • Dữ liệu nằm ở hosting
    • Ứng dụng tổng hợp dữ liệu từ nơi lưu trữ của nhiều người
  • Vì vậy atproto không có instance
    • Có thể thay đổi nơi hosting
    • Ứng dụng tổng hợp dữ liệu từ nhiều nơi hosting khác nhau
  • Cấu trúc này cho thấy một mô hình phân tán phong phú hơn so với việc “vận hành nhiều bản sao của cùng một ứng dụng”

Phi tập trung hóa mà người dùng tự làm được

  • Người dùng có thể thay đổi nơi hosting
    • Tác giả cho biết đã chuyển dữ liệu atproto của mình sang Eurosky, và ngoài một vài vấn đề UX thì quá trình diễn ra tự động
    • Nếu muốn chủ động hơn, bạn còn có thể tự host miễn phí trên Cloudflare
  • Bạn cũng có thể thử ứng dụng mới hoặc tự xây dựng ứng dụng của riêng mình

Vì sao câu hỏi “có bao nhiêu instance Bluesky” là lệch hướng

  • Với Mastodon, đo mức độ phân tán bằng số lượng instance là điều tự nhiên
    • Vì cách phân tán chủ yếu mà Mastodon cho phép là vận hành thêm nhiều chiếc hộp gắn chặt hosting và ứng dụng rồi để chúng giao tiếp với nhau
  • Trong atproto, mọi ứng dụng đều gần giống một phép chiếu của toàn bộ Atmosphere
    • Cấu trúc này tương tự cách Feedly và Google Reader hiển thị toàn bộ Blogosphere
  • Có thể vận hành nhiều bản sao đầy đủ của máy chủ cơ sở dữ liệu Bluesky, nhưng điều đó nhìn chung không hữu ích hơn mấy so với việc vận hành nhiều bản sao của Google Reader
  • Một số bản sao tồn tại để phục vụ nhu cầu cụ thể
    • Blacksky là ví dụ cho một nhu cầu riêng như triết lý kiểm duyệt khác biệt
    • Ứng dụng khách reddwarf.app không dùng cơ sở dữ liệu riêng mà dùng constellation, một bộ nhớ đệm miễn phí do cộng đồng vận hành
  • Tác giả cho biết hạ tầng mạng dùng chung như Relay đã được vận hành với chi phí thấp trong suốt một năm

Tiêu chí nên nhìn ở atproto

  • Muốn đánh giá mức độ phân tán của atproto, thay vì hỏi “có bao nhiêu instance Bluesky”, nên nhìn vào những điều sau
    • Mọi người có đang chuyển sang hosting thay thế hay không
    • Mọi người có đang tạo và sử dụng ứng dụng mới hay không
  • Việc tách hosting khỏi ứng dụng có thể sửa các động lực khuyến khích bị lệch ở cả mạng xã hội đóng lẫn mạng xã hội liên hợp
  • Cốt lõi của atproto là dữ liệu của người dùng nằm ngoài ứng dụng, còn ứng dụng thì tổng hợp trên lớp dữ liệu đó

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Câu hỏi “instance của Bluesky ở đâu?” có vẻ như đang cố tình hiểu sai để tâng bốc ATProto và hạ thấp ActivityPub
    Làm vậy sẽ bỏ qua hoặc bóp méo những chi tiết kỹ thuật thú vị như relay của ATProto cùng ưu nhược điểm của nó, hay việc di chuyển tài khoản của ActivityPub cùng ưu nhược điểm tương tự, đồng thời tạo ra mâu thuẫn không cần thiết giữa hai nền tảng đang giải quyết những vấn đề khá giống nhau
    Cũng có người dùng “instance” theo nghĩa chung như máy chủ, phần mềm đang chạy, máy ảo hay container; không hiểu sao lại nhất thiết chỉ tiếp nhận theo khái niệm kiểu Mastodon
    Sơ đồ và phần giải thích thì tốt, nhưng những cú chọc ngoáy ngấm ngầm nhắm vào ActivityPub khiến bài viết mang cảm giác xuất phát từ sự đối kháng hơn là nhằm truyền đạt thông tin

    • Giọng điệu bài viết được cố ý viết hơi đùa cợt một chút, nhưng tôi thấy câu hỏi “instance của Bluesky ở đâu” thường xuất phát từ sự hiểu sai về kiến trúc, khi lấy số lượng app instance làm thước đo của tính phi tập trung
      So với câu “instance của Google Reader ở đâu?” thì sự gượng gạo của câu hỏi đó hiện ra khá rõ, và tôi nghĩ hai hình ở cuối bài đã giải thích khá tốt những điểm thường bị bỏ lỡ trong các thảo luận ban đầu về atproto/ActivityPub
      Lý do không đưa relay vào là tôi đã viết ở đây: https://news.ycombinator.com/item?id=48600963
      Relay gần với một tối ưu hiệu năng hơn là phần cốt lõi của mô hình, nên trong bài tôi muốn tập trung vào bản thân mô hình
    • Còn tùy ngữ cảnh, nhưng trong các thảo luận quanh ATProto, ActivityPub và Mastodon thì “instance” thường được hiểu là một node ActivityPub lưu trữ dữ liệu người dùng và URL hồ sơ, và có vẻ bài viết cũng nhắm đúng vào ngữ cảnh đó
      Khi một từ bắt đầu gắn với một khái niệm và cấu trúc cụ thể, nhiều người nhìn vào “mạng xã hội phi tập trung” sẽ nghĩ ngay đến mô hình liên hợp kiểu ActivityPub, rồi nhìn ATProto và hỏi “sao chỉ có một instance Bluesky để mọi người đăng ký vậy?”
      Dù không hẳn là góc nhìn hoàn toàn mới, đây vẫn có vẻ là một bài hữu ích để sau này dẫn lại cho những ai đã đóng khung các liên tưởng cũ đó trong đầu
    • Cuộc đối đầu ATProto với ActivityPub có lẽ trông giống như Đại ly giáo Đông–Tây của Fediverse
      Thay vì sắc lệnh “filioque”, hai bên trao đổi những bài blog nói qua nói lại về định nghĩa của “liên hợp”
    • Tôi nghĩ việc phân biệt và so sánh giữa Mastodon với ATProto là cần thiết
      Mô hình Fediverse thì dễ hiểu theo góc nhìn mạng xã hội hiện có, còn ATProto là một khái niệm mới nhằm trao cho người dùng chủ quyền dữ liệu mà vẫn đạt được khả năng mở rộng của mạng xã hội tập trung

  • Tôi thấy phép so sánh ở đây bị hỏng
    RSS hoàn toàn không phụ thuộc vào Google Reader, và ngay cả thời hoàng kim của nó mức độ phụ thuộc cũng còn thấp hơn email hiện nay phụ thuộc vào Gmail
    Trong ATProto, để AppView trở nên hữu ích thì nó phụ thuộc rất nhiều vào relay, mà chi phí vận hành relay cũng khá cao
    Ngoài ra, vòng tròn màu vàng trong sơ đồ RSS là blog, còn vòng tròn đại diện cho bài đăng Facebook lại là một thứ khác về bản chất. Blog tự nó đã là độc lập
    Không phải ATProto là xấu, nhưng bài này tạo thêm cảm giác rối rắm hơn là làm mọi thứ rõ ràng hơn

    • Relay giờ thực ra đã khá rẻ rồi
      Trước đây đắt hơn một chút vì phải lưu toàn bộ lưu lượng, nhưng phần đó đã bị loại khỏi sync 1.1, và hiện tại có thể chạy khá dễ ngay cả trên máy ảo 20 USD/tháng
    • Relay đúng là phần tương đối nặng trong hạ tầng của AT Protocol, nhưng chi phí vận hành hiện nay vào khoảng 30 USD/tháng, nên vẫn là mức mà đa số có thể gánh được
      Thứ thực sự đắt đỏ và khó khăn, dù là tập trung hay phi tập trung, vẫn luôn là kiểm duyệt nội dung
      Tác giả bài này đã từng nói về một hiểu lầm phổ biến liên quan đến relay từ 9 tháng trước: https://news.ycombinator.com/item?id=45077291#45078223

  • Theo tôi, relay là chất keo giúp ATProto vận hành với hiệu năng tốt
    Nó vận chuyển dữ liệu mà không quan tâm đến nội dung, đồng thời làm giảm số lượng dịch vụ mà mỗi AppView cần phải biết tới
    Như chính bài viết nói, điểm cải tiến lớn so với Mastodon là relay, AppView và PDS là các dịch vụ tách biệt với những nhu cầu mở rộng khác nhau, và đây là một lời giải khá đẹp cho bài toán thiết kế hệ thống
    [1] https://atproto.com/guides/glossary

    • Đúng vậy, relay là một cách để làm điều đó
      Chỉ là nó là một tối ưu hóa nằm khuất phía sau, và còn có những chiến lược khác nên trong bài tôi đã lược bỏ phần lớn
      Ví dụ, hiện nay nhiều ứng dụng nhỏ không tự xây chỉ mục cơ sở dữ liệu riêng mà dựa vào Constellation(https://constellation.microcosm.blue/), nên hoàn toàn không dùng relay
    • Nội dung cũng bị gỡ trực tiếp khỏi relay
      Họ nói rằng chỉ gỡ những nội dung mà việc lưu trữ là bất hợp pháp, nhưng điều đó đúng đến đâu thì tôi không rõ, và luôn có rủi ro chuyện này sẽ thay đổi về sau
      https://docs.bsky.app/blog/blueskys-moderation-architecture#...

  • Điểm hay là đã giải thích sự khác biệt giữa hai cách tiếp cận này
    Tuy vậy, bài đó không trả lời câu hỏi “ATProto giải quyết vấn đề mà instance giải quyết bằng cách nào”, nên vẫn thấy khá bí bách
    Ví dụ, nếu coi de-federation chỉ là một kiểu lý do mơ hồ khiến không nhìn thấy bài của bạn bè, thì sẽ không thể trả lời câu hỏi “vậy atproto giải quyết vấn đề mà de-federation xử lý bằng cách nào”
    Câu trả lời nền tảng bật ra một cách tự nhiên trong khung nhìn này là “không giải quyết”

    • Nếu đang hỏi về moderation, thì nó vận hành khá giống cách người ta kỳ vọng trong một thế giới mà mọi thứ đều là RSS
      Ở cấp độ hosting, nhà cung cấp hosting có thể khóa tài khoản vì nội dung rõ ràng là bất hợp pháp, giống như blogspot.com hay Cloudflare chặn trong một số vụ việc nhất định
      Ở cấp độ ứng dụng, quản trị viên ứng dụng và moderator điều phối như các dịch vụ web khác xử lý nội dung do người dùng tạo
      Đây là vấn đề do nhà phát triển ứng dụng lựa chọn; họ có thể cung cấp các thành phần moderation theo phạm vi người dùng như Reddit, hoặc cắm một dịch vụ moderation riêng như Bluesky
      Vì không có thứ tương ứng với “community instance” để các bên có thể đánh nhau, nên cũng không có de-federation. Chỉ có hosting, ứng dụng, và moderation ở cấp ứng dụng tùy theo lựa chọn của nhà phát triển ứng dụng
    • Theo tôi, câu hỏi hay hơn là “ActivityPub giải quyết các vấn đề do federation tạo ra bằng cách nào”
      Về bản chất, điều này khá giống những gì Microsoft làm với email. Ngoài các nhà cung cấp lớn nhất ra thì họ vứt bỏ thư, và trên thực tế biến federation thành thứ buộc người dùng phải dùng Microsoft hoặc một nhà cung cấp lớn sẵn có khác nếu muốn chuyển thư
      Khi đó các instance mới không thể chuyển thư và không thể thu hút người dùng. Các nhà cung cấp lớn sẵn có có động cơ méo mó để không liên kết với instance mới
      Kiểu lựa chọn kiến trúc này về dài hạn có tác dụng củng cố thế độc quyền nhóm
      Người ta nói điều đó là cần thiết để chống spam, nhưng cũng có những nhà cung cấp không làm vậy, và họ cũng không gặp vấn đề spam nhiều hơn, miễn là cấu hình đúng DKIM, reverse DNS v.v., thì thông thường vẫn gửi được vào Gmail
      Giải pháp thay thế hiển nhiên là lọc ở phía client. Nếu bộ lọc được cung cấp bởi những đơn vị phát hành danh sách lọc kiểu như uBlock thay vì bởi nhà vận hành như Microsoft, thì vì họ không vận hành một instance cụ thể nào nên cũng không có động cơ dồn tất cả mọi người về instance của mình
    • Nó không giải quyết được những vấn đề đó
      Trừ khi tồn tại một vũ trụ thay thế nơi có rất nhiều AppView có thể tiêu thụ toàn bộ firehose, có thể tự do lựa chọn giữa chúng, và có thể tự vận hành với chi phí rẻ
      ATProto gần với một thế giới RSS mà bạn chỉ có thể đọc RSS thông qua Google Reader hoặc một dịch vụ sao chép ở quy mô tương tự, chứ không có RSS reader desktop hay mobile

  • Nếu kêu quạc quạc như vịt thì nó là vịt
    Mỗi tài khoản có một PDS duy nhất, và DID trỏ tới PDS là nơi chứa feed dữ liệu chính thức của người dùng cũng như là đích ghi dữ liệu
    Dữ liệu có thể được sao chép, nhưng PDS được xem là bản gốc chuẩn
    Điều này gần với kiến trúc client/server hơn rất nhiều so với kiến trúc phân tán
    Không có cơ sở dữ liệu P2P, cũng không có chuyện ghi vào DHT hay peer. Bạn ghi vào PDS, rồi bản ghi đó được mirror một cách có chọn lọc
    Việc khám phá cũng diễn ra qua DNS, nên cũng không hỏi dữ liệu từ peer
    Bạn kết nối tới relay không phải như tới peer, mà như một client yêu cầu bản sao của dữ liệu được host chính thức trên PDS
    Tôi không thấy việc gọi PDS là instance và relay là mirror có gì gượng ép

    • Nói như vậy cũng được
      Chỉ là nó khác với nghĩa mà người nói về Mastodon thường dùng khi họ nói “instance”
      Trong Mastodon, instance là một gói gắn liền không thể tách rời giữa hosting dữ liệu, ứng dụng, cộng đồng và moderation

  • Tôi hiểu rằng ATproto hy sinh sự phi tập trung “thực sự” để đổi lấy tính nhất quán, còn Mastodon và ActivityPub hy sinh tính nhất quán “thực sự” để đổi lấy một mức phi tập trung dễ tiếp cận hơn
    Vì việc vận hành một node ActivityPub dễ tiếp cận hơn rất nhiều với người dùng tự host thông thường so với việc vận hành content relay của AT
    Thứ có thể “phi tập trung” trong AT rốt cuộc chỉ là dữ liệu của chính bạn, và nó gần với quyền sở hữu dữ liệu cá nhân hơn là cùng sở hữu một phần của mạng lưới
    Đây cũng là điều đã được nhắc đi nhắc lại nhiều lần trên HN

    • Đây là một góc nhìn thú vị, nhưng theo hiểu biết hiện tại của tôi thì AtProto có vẻ dễ tiếp cận hơn và phi tập trung hơn
      Trong ActivityPub, vận hành một instance đồng nghĩa với việc phải gánh cả dữ liệu, ứng dụng, lẫn bài toán mở rộng về sau, nên bạn либо phải tự gánh trách nhiệm vận hành, либо bị ràng buộc vào instance của người khác
      Ngay cả khi bạn không còn thích instance đã chọn và muốn chuyển đi, nếu điều đó vẫn chưa thay đổi thì gần như bạn phải bắt đầu lại từ đầu
      Với AtProto, việc chuyển sang một nền tảng ứng dụng khác mà vẫn giữ nguyên danh tính dễ hơn, và cũng có thể xuất dữ liệu khỏi nền tảng để tự host, dù trải nghiệm người dùng còn khó nhưng ít nhất là khả thi
      Ví dụ gần đây tôi thử Tangled lần đầu, và có thể đăng nhập bằng domain dựa trên bsky sẵn có (h14h.com). Không cần tạo tài khoản mới hay username mới, cảm giác như tôi đã ở đó sẵn rồi
      Việc thiết lập tự host một kho git trên VPS cùng lắm chỉ mất nửa buổi chiều, và nó chạy như một dịch vụ backend gần như không phải để ý
      Trường hợp xấu nhất là tangled.org hiện một banner kiểu “kho đã cũ và có thể không tương thích với Tangled mới nhất”, rồi chỉ cần build lại Docker image với phiên bản mới và triển khai là xong
      Về mặt kiến trúc thì AtProto chắc chắn khó nắm bắt hơn nhiều, nhưng để đưa nó đến chỗ người dùng thực sự chạm vào thì tôi nghĩ nó đơn giản hơn hẳn
    • Tôi không chắc có cái gọi là phi tập trung “thực sự” hay không
      Trong đầu tôi, nó không giống một thanh trượt duy nhất mà giống một buffet các đánh đổi hơn
      Nhân tiện, trong thế giới AP cũng có cá nhân và các nhóm nhỏ đang vận hành relay, mirror, cache, AppView, v.v. Chỉ là đúng rằng khi quy mô lớn lên thì chi phí có thể tăng mạnh hơn
    • Điều đó đúng một phần, nhưng không giải thích được toàn bộ
      AT không chỉ cung cấp tính nhất quán mà còn cung cấp mô hình dữ liệu dùng chung trên toàn bộ ứng dụng
      Vì thế các ứng dụng có thể tham chiếu và render nội dung của ứng dụng khác. Nó giống một web của JSON có kiểu dữ liệu, và các ứng dụng khác nhau là những lăng kính nhìn vào cùng một mạng lưới
      Bất kỳ ai cũng có thể tạo ra trải nghiệm mới trên lớp dữ liệu sẵn có, và trong AP gần như không có thứ tương đương
      AP gắn dữ liệu với ứng dụng, còn trong AT thì nó gần giống việc mọi ứng dụng cùng truy vấn một cơ sở dữ liệu toàn cục chứa dữ liệu của cả thế giới
      Tôi không hiểu vì sao thảo luận lúc nào cũng mắc kẹt ở relay. Hiện nay nếu muốn thì bạn có thể chạy relay với chi phí cỡ 30 USD/tháng, hoặc dùng relay của Bluesky hay relay cộng đồng miễn phí
      Nhiều ứng dụng hoàn toàn không dùng relay mà dựa vào các chỉ mục cộng đồng như Constellation(https://constellation.microcosm.blue/). Thậm chí có ứng dụng còn không chạy cả server hay cơ sở dữ liệu riêng
    • Mastodon cũng có content relay
      Nhưng ngược lại, tôi còn muốn nói rằng ATproto phi tập trung hơn, hoặc ít nhất là đang cố trở thành như vậy
      Trong thế giới ActivityPub, danh tính, ứng dụng và hosting về bản chất gắn liền với nhau
      Nếu muốn dùng Lemmy thì bạn либо phải tạo một tài khoản ActivityPub thứ hai, tách biệt vĩnh viễn trên instance Lemmy đó, либо chỉ có thể dùng Lemmy trong phạm vi instance Mastodon của bạn biết cách gửi những thông điệp mà Lemmy hiểu
      Mỗi ứng dụng ActivityPub mới lại tạo ra một vấn đề tương tác mới. Vì mỗi ứng dụng sở hữu danh tính và hosting riêng của nó
      Không có cách nào để instance Mastodon tôi tự host cung cấp danh tính cho một server Lemmy, rồi server Lemmy đó yêu cầu instance của tôi host nội dung thay tôi
      Để đạt đến mức mà ATProto nói tới thì ít nhất phải làm được như vậy. Dù tôi không chắc ATProto tồn tại ngoài đời thực hiện được đến đâu, và bản thân ActivityPub tồn tại ngoài đời cũng không tương tác được nhiều như những người ủng hộ thường nói

  • Blog này giải thích kiến trúc khá tốt
    Nhưng trên thực tế, tôi từng nghĩ “vấn đề” là công ty Bluesky đang vận hành ứng dụng chính và lưu trữ phần lớn dữ liệu người dùng
    Ở cấp giao thức thì nó là phi tập trung, nhưng xét từ góc độ chủ thể kiểm soát thì hệ thống thực tế vẫn rất tập trung
    Không hẳn là lỗi của Bluesky, nhưng có vẻ cho đến nay mọi thứ vẫn diễn ra như vậy

    • “Vấn đề” là mọi người cứ cố tìm cho ra vấn đề
      Đây không phải điều riêng của Bluesky hay ATProto; dù là tổ chức vì lợi nhuận, phi lợi nhuận hay một nhóm tình nguyện, lúc nào cũng sẽ có ai đó tìm ra thứ để phàn nàn
      Tôi không có xung đột lợi ích gì với Bluesky ngoài việc từng là người dùng sớm chứ không phải nhà đầu tư. Trong khả năng của mình, tôi cũng hiểu giao thức, công ty và website
      Site và app hoạt động tốt. Mọi người quá tập trung vào việc tìm lỗi thay vì xây ra một giải pháp lớn hơn và tốt hơn
      Đa số không muốn những giải pháp P2P chắp vá như Lemmy hay Mastodon. Họ muốn nội dung ở một chỗ và muốn có một chủ thể để quy trách nhiệm
      Vì thế tôi nghĩ mạng xã hội P2P sẽ không bao giờ trở thành xu hướng đại chúng. Xung quanh Lemmy và Mastodon còn nhiều drama hơn cả Twitter, Reddit và Facebook cộng lại
      Đó là 2 xu của tôi, và có vẻ vợ/chồng tôi cùng bạn bè tôi cũng nghĩ vậy
    • Có các ứng dụng khác, các nơi host dữ liệu người dùng khác, hosting cá nhân, và các dịch vụ backend khác
      Nó phi tập trung cả trong lý thuyết lẫn thực tế
      Chỉ là vì Bluesky đang vận hành phần lớn nhất nên có thể nói rằng ở cấp cộng đồng hay mindshare thì nó chưa phi tập trung, nhưng điều đó cũng đang thay đổi
    • Có thật là giải thích tốt không?
      Nó chỉ nói rằng “không có instance”, chứ không giải thích kiến trúc đó né tránh các vấn đề như xác thực, đồng bộ hóa và khám phá như thế nào

  • Việc chọn Google Reader làm phép so sánh tạo cảm giác khá điềm gở
    RSS vẫn sống sót sau khi Google Reader đóng cửa, nhưng không phải mọi cộng đồng từng dùng RSS đều sống sót, và nhiều cộng đồng trong số đó đến giờ vẫn không biết RSS là gì
    Trong khi tự nhận là thứ phi tập trung, việc cứ liên tục chỉ vào sự tập trung hóa xã hội khổng lồ của hệ sinh thái phi tập trung như một ví dụ tốt gần như mang màu sắc Freud
    Đặc biệt là vì chúng ta đã biết cái kết đó rồi
    Google Reader đã gom nhiều ngôi nhà RSS lại thành một, rồi cộng thêm giá trị như đồ thị xã hội và bình luận, nhưng cuối cùng sụp đổ vì sự thay đổi thất thường từ các lãnh đạo Google, gần như giết chết RSS và phá hủy một đồ thị xã hội ấn tượng
    Với kiểu so sánh như vậy thì khó mà có được nhiều niềm tin vào ATProto

    • Cốt lõi của atproto là ngay cả đồ thị xã hội cũng nằm ở phía “blog/RSS”
      Ứng dụng chỉ lập chỉ mục cho nó thôi
      Vì vậy trong phép so sánh này, bất kỳ ai cũng có thể hồi sinh Google Reader hoặc cạnh tranh với nó bằng cùng một đồ thị
      Nếu tò mò thì hiện tại http://leaflet.pub thực sự vận hành theo kiểu đó
    • Nghe điềm gở, nhưng lại chính xác
      Hãy tưởng tượng bạn không thể dùng trình đọc RSS trên desktop hay di động, mà chỉ có thể đọc RSS bằng Google Reader hoặc các dịch vụ sao chép có quy mô tương tự
    • Bù lại thì hiện giờ có rất nhiều trình đọc RSS rất tốt
      Gần đây cũng có người nhắc đến NetNewsWire

  • Khác biệt quan trọng là blog có website riêng, và không nhất thiết phải đưa toàn bộ bài viết vào feed RSS
    Bluesky thường không vận hành như vậy. Mọi thứ trên PDS đều được sao chép
    Họ còn khuyến khích đưa toàn bộ bài blog vào PDS để dễ sao chép hơn
    Khi đó bất kỳ ai muốn lập chỉ mục đều có thể mang bản sao đi, và bạn không thể kiểm soát họ làm gì với nó
    Không bắt buộc phải làm vậy. Bạn vẫn có thể đăng blog trên website riêng và chỉ đăng liên kết lên Bluesky

    • Điều đó khác gì so với scraper tự cào trực tiếp blog?
    • Thành thật mà nói, đó cũng là vì atproto là một giao thức dữ liệu thô
      Việc đặt một frontend HTTP lên trên tài khoản atproto là cách được khuyến nghị, và trên thực tế rất nhiều người làm vậy
      Tôi cũng làm như thế trên pfrazee.com, và các bài blog leaflet của tôi mà bản gốc nằm trên atproto cũng được render trên blog của tôi

  • So sánh với RSS dễ gây hiểu lầm
    Ứng dụng Atproto không giống trình đọc RSS chạy trên máy tính người dùng và kết nối trực tiếp đến nguồn nội dung
    Ứng dụng Atproto là máy chủ kiểm soát, lọc và định hình nội dung được đưa đến người đọc
    Ứng dụng Atproto có thể kiểm duyệt, shadowban, chèn quảng cáo, và biến feed thành feed thuật toán theo ý muốn
    Người dùng thì bất lực, còn người sáng tạo trở thành nạn nhân không thể làm gì ngoài kêu gào
    Việc ai cũng có thể lưu trữ dữ liệu ở đâu đó hoàn toàn vô nghĩa nếu không có cách nào để phân phối dữ liệu đó

    • Điều đó không đúng
      Trước hết, bạn có thể dùng AppView khác không làm những việc đó
      Feed có thể được thuật toán hóa theo cách người dùng muốn, và nếu có nhiều ứng dụng thì bạn sẽ không bị trói vào thuật toán mà một nhà cung cấp trung tâm muốn áp đặt