- Cũng như mã nguồn mở đã trở thành tiêu chuẩn của hạ tầng phần mềm, một mô hình "mạng xã hội mở" cho các ứng dụng xã hội cũng đang xuất hiện
- AT Protocol cho phép người dùng trực tiếp sở hữu và kiểm soát dữ liệu xã hội của mình, đưa ra một khái niệm khác biệt so với các nền tảng xã hội hiện có
- Dữ liệu xã hội không còn bị nhốt trong một dịch vụ cụ thể, mà được lưu trong kho lưu trữ cá nhân do chính người dùng quản lý
- Nhờ đó, dữ liệu có thể được tái sử dụng và remix giữa các ứng dụng, đồng thời vẫn tồn tại ngay cả khi dịch vụ ngừng hoạt động
- Khi mạng xã hội mở lan rộng, quyền sở hữu dữ liệu do người dùng làm chủ và khả năng mở rộng linh hoạt được kỳ vọng sẽ trở thành các giá trị cốt lõi
Mở đầu: thành công của mã nguồn mở và một làn sóng mới
- Mã nguồn mở từng vấp phải nhiều sự phản đối, nhưng ngày nay đã trở thành nền tảng của hạ tầng dùng chung
- Khác với trước đây, giờ đây chọn mã nguồn mở không còn là vấn đề, và trong các lĩnh vực phần mềm quan trọng, mã nguồn mở đã trở thành lựa chọn mặc định
- Hiện nay, chúng ta đang đối mặt với một bước ngoặt trong lĩnh vực ứng dụng xã hội tương tự như mã nguồn mở cách đây 35 năm
- Một làn sóng mới mang tên "mạng xã hội mở" đã xuất hiện, và AT Protocol của Bluesky được đánh giá là cách triển khai thuyết phục nhất
Cấu trúc cơ bản của web và quyền sở hữu dữ liệu cá nhân
- Trên web trước đây, mỗi người có những địa chỉ cá nhân như
alice.com, bob.com, và mỗi người dùng sở hữu không gian riêng của mình để tự do đăng nội dung lên đó
- Nếu không thích nhà cung cấp hosting, họ có thể chuyển sang nơi khác mà địa chỉ vẫn được giữ nguyên, các liên kết cũ cũng không bị đứt
- Nhờ vậy, người dùng không bị ràng buộc vào một nhà cung cấp hosting cụ thể, còn nhà cung cấp thì phải cạnh tranh
- Nói cách khác, nhờ thiết kế phi tập trung của web, người dùng nắm dữ liệu còn nhà cung cấp chỉ đóng vai trò đơn thuần là bên cung cấp dịch vụ
Mạng xã hội hiện đại: đánh mất quyền sở hữu dữ liệu
- Ngày nay, thay vì vận hành website riêng, mọi người thường nhận các ID như
@alice, @bob do công ty cấp và đăng bài lên các ứng dụng mạng xã hội
- Dữ liệu như bài viết, bình luận, lượt thích đều được lưu trong cơ sở dữ liệu của một công ty mạng xã hội cụ thể
- Nhờ cấu trúc này mà các chức năng tổng hợp xã hội như tìm kiếm, feed, gợi ý, thông báo đã ra đời
- Tuy nhiên, nó cũng kéo theo tác dụng phụ là dữ liệu cốt lõi không còn thuộc sở hữu của chúng ta
- Người dùng rơi vào tình trạng không thể tự do mang theo dữ liệu và các mối quan hệ do chính mình tạo ra
Vấn đề: người dùng bị nhốt trong nền tảng
- Khi rời đi, người dùng phải bỏ lại toàn bộ các kết nối mà mình đã tạo ra
- Không thể dễ dàng đổi nhà cung cấp hosting, và nếu rời nền tảng thì cả kết nối lẫn dữ liệu cũng mất theo
- Các nền tảng biết điều này nên người dùng thường phải chịu đựng những thay đổi bất lợi (quá nhiều quảng cáo, thuật toán bị bóp méo, xóa tính năng, v.v.)
- Ngay cả khi sao lưu hoặc xuất dữ liệu ra ngoài, đó cũng chỉ là "dữ liệu chết" đã mất bối cảnh xã hội, rất khó làm cho nó sống lại ở nơi khác
Mạng xã hội mở: khôi phục quyền sở hữu dữ liệu và mạng lưới
- Trong mạng xã hội mở, thông qua các handle dựa trên domain như @alice.com, quyền sở hữu thực chất đối với dữ liệu xã hội được trao lại cho người dùng
- Tên được gắn với domain mà tôi sở hữu như
@alice.com
- Người dùng trực tiếp quản lý toàn bộ dữ liệu xã hội mình tạo ra thông qua kho lưu trữ cá nhân (repository)
- Các hoạt động như bài viết, bình luận, theo dõi được ghi lại trong kho cá nhân (repo)
- Kho lưu trữ chỉ là một web server đơn giản, lưu các bản ghi ở định dạng JSON
- Địa chỉ có dạng
at://alice.com/... nên có thể liên kết với nhau
- Kho lưu trữ dựa trên AT Protocol hoạt động trên DNS, HTTP và JSON, và mỗi dữ liệu được lưu dưới dạng JSON có siêu liên kết
- Ngay cả người không rành kỹ thuật cũng sẽ được tạo kho lưu trữ tự động khi đăng ký ứng dụng, nên dữ liệu vẫn thuộc sở hữu của người dùng bất kể ứng dụng nào
- Dữ liệu thuộc về kho lưu trữ của người dùng, nên dù nhà cung cấp dịch vụ thay đổi, quyền sở hữu dữ liệu và tính liên kết vẫn được giữ nguyên
Cấu trúc và ứng dụng của các app mạng xã hội mở
- Mỗi ứng dụng mạng xã hội mở, giống như CMS, quản lý một phần kho dữ liệu xã hội của người dùng; giờ đây app chỉ còn là công cụ đọc và ghi vào kho lưu trữ của người dùng
- Ví dụ, dữ liệu từ nhiều ứng dụng khác nhau như Bluesky, Tangled, Leaflet có thể cùng tồn tại trong kho lưu trữ của một người dùng
- Nếu tôi đăng bài lên Bluesky, một bản ghi sẽ được lưu vào kho của tôi; nếu tôi gắn sao cho một dự án trên Tangled, dữ liệu đó cũng vào kho của tôi
- Định dạng dữ liệu được phân biệt bằng namespace để tránh xung đột, ví dụ
app.bsky.post, sh.tangled.star
- Theo thời gian, kho lưu trữ của tôi sẽ trở thành tập hợp dữ liệu đến từ nhiều ứng dụng khác nhau
Những thay đổi hệ sinh thái do dữ liệu mở mang lại
- Vì dữ liệu được lưu theo cách mở, việc tích hợp giữa các ứng dụng, phát triển dịch vụ mới, tự do tham chiếu, tái sử dụng và remix dữ liệu của nhau trở nên dễ dàng hơn
- Ngay cả khi ứng dụng ngừng hoạt động, dữ liệu vẫn nằm trong kho của người dùng và có thể được tái sử dụng ở dịch vụ khác
- Các ứng dụng mới có thể tận dụng quan hệ và dữ liệu từ mạng lưới sẵn có để vượt qua bài toán "cold start" (xây dựng mạng lưới ban đầu)
- Vì dữ liệu này ai cũng có thể đọc, ứng dụng khác có thể lấy về để tải ảnh đại diện hoặc tận dụng nguyên vẹn các quan hệ theo dõi hiện có
- Dù app đóng cửa, dữ liệu vẫn nằm trong kho của người dùng để app khác có thể lấy ra dùng lại
Tổng hợp (aggregation) và các thách thức kỹ thuật
- Dữ liệu của người dùng được phân tán trong các kho riêng, nhưng có thể nhận luồng sự kiện thay đổi dữ liệu qua đăng ký WebSocket rồi phản ánh vào cơ sở dữ liệu cục bộ
- Thông qua các relay lớn (máy chủ trung chuyển), hệ thống nhận sự kiện của toàn mạng và chỉ lọc ra những sự kiện cần thiết
- Các bản ghi dữ liệu được ký mã hóa để bảo đảm độ tin cậy và tính nhất quán
- Ví dụ, hạ tầng như Graze, Slices hỗ trợ việc tổng hợp trong mạng xã hội mở
Chức năng tổng hợp hoạt động như thế nào?
- Dù kho dữ liệu của mỗi người dùng tồn tại riêng biệt, ứng dụng vẫn nhận luồng sự kiện thời gian thực từ các kho đó và ghi vào cơ sở dữ liệu của mình
- Các máy chủ trung chuyển như của Bluesky tập hợp rồi phân phối toàn bộ luồng dữ liệu, còn ứng dụng chỉ chọn lưu những sự kiện mà mình quan tâm
- Cơ sở dữ liệu được tích lũy theo cách này có thể cung cấp nhanh các chức năng như tìm kiếm, feed và gợi ý
- Các bản ghi dữ liệu được ký mã hóa để bảo đảm độ tin cậy và tính nhất quán: không cần phải tin relay vẫn có thể xác minh tính xác thực của dữ liệu
- Hạ tầng như Graze, Slices hỗ trợ việc tổng hợp trong mạng xã hội mở
Bức tranh lớn
- Web trước đây: người dùng nắm nội dung và địa chỉ của chính mình
- Ứng dụng xã hội ngày nay: có chức năng tổng hợp, nhưng dữ liệu bị trói trong cơ sở dữ liệu do công ty sở hữu
- Mạng xã hội mở: vẫn giữ được chức năng tổng hợp nhưng dữ liệu vẫn nằm trong tay người dùng
- Ứng dụng chỉ trở thành cửa sổ dùng để gom và hiển thị dữ liệu của người dùng
- Dù dịch vụ biến mất, dữ liệu vẫn còn để ứng dụng khác có thể hiển thị lại trong bối cảnh mới
Kết luận
- Cốt lõi của mạng xã hội mở là kết hợp ưu điểm của web cá nhân (sở hữu dữ liệu, tự do chọn hosting, giữ liên kết) với điểm mạnh của mạng xã hội đóng (tổng hợp, khả năng mở rộng)
- Mạng xã hội mở bảo đảm quyền sở hữu dữ liệu do người dùng làm chủ, khả năng di chuyển dữ liệu tự do giữa các ứng dụng và tính liên tục của dịch vụ
- Cũng như mã nguồn mở từng nói rằng "mã phải thuộc về người dùng", thì "dữ liệu cũng phải thuộc về người dùng"
- Nó giải quyết vấn đề người dùng đánh mất dữ liệu và tính liên kết trong các nền tảng đóng
- Khi có thêm nhiều sản phẩm mạng xã hội mở xuất hiện, ranh giới giữa các ứng dụng sẽ mờ dần và hệ sinh thái nơi dữ liệu lưu chuyển tự nhiên sẽ hình thành
- Cuối cùng, có khả năng sẽ xuất hiện một tương lai nơi người dùng thực sự kiểm soát dữ liệu và mạng lưới của mình
- Giai đoạn đầu có thể sẽ do một nhóm nhỏ các nhà phát triển và người dùng nhiệt huyết dẫn dắt, nhưng khi nền tảng dùng chung dần tích lũy, mô hình mở có khả năng sẽ chiến thắng vào một thời điểm nào đó
- Ngay cả khi không hiểu các khái niệm kỹ thuật như phi tập trung hay liên bang hóa, người dùng vẫn có thể cảm nhận được lợi ích thực tế (liên thông dữ liệu, di chuyển dễ dàng, tính bền vững)
- Mạng xã hội mở sẽ dần mở rộng nhờ nỗ lực dài hạn dựa trên cộng đồng nhiệt huyết và hiệu ứng tích lũy
3 bình luận
Instagram đúng là cũng là nơi lưu giữ ký ức, nhưng có vẻ không dễ để rời đi theo ý mình.
Tôi cũng nghĩ rằng ở khía cạnh chia sẻ và sử dụng dữ liệu, có những phần nào đó mình phải chấp nhận nhượng bộ ở mức nhất định.
KakaoTalk... đm
Ý kiến trên Hacker News
Ban đầu tôi nghĩ AT Protocol là hệ thống của Bluesky nên có vẻ như một phiên bản doanh nghiệp của ActivityPub, nhưng đọc bài này xong thì tôi khá thích cách dữ liệu được lưu trong "repository" do tôi chọn. Nó cũng phù hợp với nguyên tắc chung của tôi: tôi tin rằng việc lọc v.v. nên được thực hiện ở phía đọc thì tốt hơn là lúc viết bài. Vì vậy, việc tôi có thể đưa mọi thứ mình muốn vào repository của mình, rồi người khác có thể đọc và sử dụng nó, là một cấu trúc rất hay. Mũi tên trông như thể bình luận đi vào repository của tôi, nhưng có vẻ đó chỉ là một chút không chính xác khi diễn đạt ý tưởng. Nhìn chung, đây là một kiến trúc rất hay và rất phi tập trung. Tuy vậy, khi thực sự thử tự vận hành một PDS riêng trong AT, tôi nhận ra rằng dù khá mượt và được đóng gói tốt, vẫn có một số điều kiện tiên quyết:
Có lẽ tôi đã gây nhầm lẫn vì dùng hai loại mũi tên. Mũi tên liền (@alice.com đi xuống) biểu thị quyền sở hữu. Nó giống với cách nhóm theo màu. Màu xanh nghĩa là tất cả đều thuộc về Alice. Mũi tên nét đứt là liên kết giữa các record. Nó giống hệt
<a href>, tức là bất kỳ record nào cũng có thể tự do liên kết tới record khác dù chúng nằm ở repository nào. Nếu ai đó bình luận vào bài viết của tôi, thì bình luận đó sẽ nằm trong repository của người bình luận và tạo một liên kết tới bài gốc. Lý do mô hình dữ liệu được thiết kế như vậy là để người lập chỉ mục có thể dễ dàng khôi phục quan hệ nếu họ có cả hai record. Ví dụ, nếu Bob bình luận vào bài của Alice, thì bình luận của Bob nằm trong repository của Bob, còn bài của Alice nằm trong repository của Alice. Nếu ai đó viết bình luận vào bài của tôi, thì bình luận đó luôn ở lại trong repository của họ. Tiền đề cốt lõi là bạn không thể tạo record trong repository của người khác.Gói PDS mặc định có hỗ trợ tự động xử lý SSL, nhưng đó không phải yêu cầu bắt buộc mà chỉ là để nhà phát triển dễ áp dụng hơn. URI
at://có dạngat://DID/..., và handle dễ đọc với con người được ánh xạ tới DID thông qua bản ghi DNS TXT (_atproto.roshangeorge.dev). DID liên kết đến một tài liệu chỉ rõ vị trí máy chủ, nên các route HTTPS/WSS cũng có thể đặt ở bất kỳ đâu. Ngoài ra, các lượt thích, trả lời v.v. cho bài viết của tôi sẽ đi vào repository của người thực hiện hành động đó, chứ không vào repository của tôi. Trực giác của bạn ở điểm này là đúng.Tôi từng nghĩ ActivityPub là giao thức tốt hơn còn AT chỉ là bản nhái rẻ tiền, nhưng đọc bài này xong tôi nhận ra AT tốt hơn nhiều. Điểm cốt lõi là nhiều chương trình có thể chia sẻ cùng một danh tính. Đây là một tính năng thực sự tuyệt vời và đúng là một trải nghiệm mở mang tầm nhìn.
Phần lớn giải thích về ATProto tập trung vào quyền sở hữu dữ liệu, nhưng thực ra ở khía cạnh xử lý dữ liệu thì ActivityPub mạnh hơn. ATProto được xây dựng theo hướng nhìn ra toàn thế giới một cách công khai, nên mọi sự kiện đều xuất hiện trước một AppServer toàn cục đáng tin cậy và phải tự đánh giá; vì vậy việc tạo feed, quyền truy cập v.v. đều phải dựa vào các trung gian đáng tin. Ngược lại, ActivityPub giống RSS hay email hơn: máy chủ của tôi chỉ quản lý các feed mà tôi đăng ký, và inbox được tạo trực tiếp từ các bài viết mà tôi có thể truy cập. Đây cũng là lý do Bluesky không thể có "like riêng tư" kiểu Twitter. Mỗi AppView đều phải tự theo dõi số lượt thích của mọi bài viết trong mạng, nên cực kỳ phiền. Về dài hạn, tôi nghĩ cấu trúc của ActivityPub có lợi thế hơn. Và phần “nhiều chương trình chia sẻ cùng một danh tính” thực ra đã có trong thiết kế ActivityPub thời kỳ đầu. Chỉ là các triển khai đầu tiên phổ biến nhất đã loại bỏ tính năng đó để phù hợp với cấu trúc sẵn có.
Tranh luận AT với AP vốn rất phức tạp. Cộng đồng của chúng tôi cũng đã bàn nhiều lần, nên tôi để lại một thread đáng tham khảo: https://github.com/bevyengine/bevy/discussions/18302
Tôi rất vui vì phần đó khiến bạn đồng cảm. Lúc nào cũng bị đem ra so với AP thật khá mệt, vì phạm vi của chúng thực sự khác nhau.
Một bài viết nói về góc nhìn tương tự nhưng từ quan điểm của kỹ sư hệ thống phân tán cũng sẽ rất thú vị: https://atproto.com/articles/atproto-for-distsys-engineers
Vậy thì tôi tò mò là có phải đang tồn tại một dịch vụ danh tính tập trung hay không.
Tôi không quan tâm giao thức phân tán nào sẽ thắng, nhưng dù ATProtocol trông có vẻ hay về mặt lý thuyết, thì trong thực tế tôi càng lúc càng thấy ActivityPub hấp dẫn hơn. Tôi hoạt động khá nhiều trên Lemmy, và nó khá sôi động, vui vẻ.
Khác với Mastodon, ở AT khái niệm instance tự nó đã khác. Ngay trong hạ tầng Bluesky cũng có nhiều PDS và chúng hoạt động khác về mặt cấu trúc, theo kiểu phân tầng (xem bài liên quan). Gọi đó là một instance thống trị duy nhất thì không chính xác. Dĩ nhiên, lo ngại doanh nghiệp lèo lái giao thức theo ý mình là một mối bận tâm thực tế. Nhưng cho tới giờ họ vẫn được đánh giá là quản lý tốt. Tôi nghĩ đây là vấn đề sẽ dần được giải quyết khi hệ sinh thái phát triển. Và cũng có lo ngại rằng nếu Bluesky đóng dịch vụ thì sẽ không thể di chuyển, nhưng bản thân protocol đã tích hợp sẵn sao lưu và chuyển đi. Chỉ cần có file CAR là có thể chuyển sang host khác bất cứ lúc nào. Với Mastodon, di chuyển tài khoản mất mát khá nhiều, còn atproto cho phép chuyển đi minh bạch 100%.
Cuối cùng thì dù là Bluesky hay Mastodon, vào đó rồi cũng chỉ toàn nói chuyện chính trị Mỹ. Tôi không thích lắm kiểu kịch chính trị hàng tuần đó, nên có lẽ Tumblr, Pinterest hay TikTok với nội dung đa dạng hơn sẽ hợp với tôi hơn.
Mastodon không hoàn toàn đồng nhất với ActivityPub, nhưng việc các câu trả lời đột nhiên biến mất khiến tôi không tin tưởng. Có bài thì còn, rồi lại biến mất, và đó là một trong hai lý do tôi rời Mastodon.
Hơi tiếc một chút là mỗi ứng dụng dùng kiểu collection riêng của mình, và dù họ có thể chia sẻ collection với nhau, thì vẫn chưa rõ cuối cùng các ứng dụng có tương thích với nhau hay không. Một trong những điểm đẹp của ActivityPub là người dùng Mastodon có thể theo dõi người dùng Pixelfed mà không cần bận tâm gì đặc biệt. Cảm giác như Twitter, Instagram, Reddit, YouTube và Substack đều tự động kết nối với nhau mà không cần cấu hình gì thêm.
Về cơ bản AP liên kết khá tốt giữa nhiều dịch vụ ở các type Status và Question. Mastodon, Pixelfed, Misskey, Pleroma v.v. đều xoay quanh hệ thống này. Nhưng hỗ trợ cho các type khác lại rất hạn chế, nên những loại nội dung khác không được hỗ trợ tử tế. Vấn đề là cộng đồng thiếu một tổ chức để điều phối các mở rộng ngoài chuẩn. ATproto thì bắt buộc phải tuân theo định nghĩa lexicon/schema của data collection, và các triển khai tham chiếu lẫn bên thứ ba đều cung cấp kiểm tra tính hợp lệ của schema. Vì vậy tính tương thích cơ bản được cấu trúc rõ ràng hơn, nhưng tôi cũng nghĩ nó cần linh hoạt hơn một chút để cho phép hỗ trợ tùy chọn với một số trường bổ sung. Bridgy Fed là một ví dụ khi dữ liệu từ APub được gắn thêm metadata như URL gốc, văn bản v.v. (https://fed.brid.gy/docs#bluesky-fields tham khảo)
Đang có nỗ lực cải thiện lexicon chung: https://github.com/lexicon-community
Tôi bắt đầu cảm thấy các dự án hô hào “Twitter thế hệ tiếp theo” đều hơi lệch hướng trong cách giải quyết vấn đề. Sau khi tái hiện hoàn hảo chức năng của Twitter, họ lại mắc kẹt ở bài toán thiếu người dùng và thiếu nội dung — bài toán con gà quả trứng. Rốt cuộc người ta tụ về nơi có đông người, và nơi đó vẫn là Twitter. Ngược lại, hướng đi như timeline mà OpenAI mới ra mắt gần đây — tức là ưu tiên thu thập dữ liệu ở hậu trường rồi chuyển đến người dùng — lại có vẻ tốt hơn. Cách triển khai cụ thể có thể khác nhau, nhưng tôi thấy định hướng đó là đúng. Phần lớn người dùng không thực sự đánh giá cao chức năng viết tweet, mà giá trị thật nằm ở việc tiêu thụ dữ liệu (tìm nguồn nội dung). Theo góc nhìn này, một trình đọc RSS đa mạng xã hội + tùy chọn P2P có vẻ là hướng tốt hơn. Chỉ là ý kiến cá nhân.
Như bài viết mô tả, cách đóng khung ban đầu dùng microblogging, nhưng trên thực tế không chỉ có kiểu Twitter mà còn có thể có nhiều dạng khác. Ví dụ, Tangled là “Github on atproto”, còn Leaflet là “Medium on atproto”. Hạn chế của mô hình P2P phía client là khó bảo đảm aggregation ở quy mô lớn và tính nhất quán, trong khi đó lại là điều cơ bản mà hầu hết người dùng phổ thông mong đợi ở một ứng dụng mạng xã hội. Ví dụ OpenAI cũng là điểm mà atproto tỏ ra mạnh. Dữ liệu đã tồn tại sẵn trên mạng, nên rất dễ gắn thêm crawler, indexer và công cụ tự động hóa. Có thể xem một ví dụ ban đầu ở https://github.com/graze-social/iftta.
Mạng xã hội không phát triển bằng kiểu “giống hệt nhưng thêm tí nữa!”, mà phát triển khi xuất hiện một cách làm mới vốn không thể có trên nền tảng trước đó.
Vì vậy Nostr mới khác biệt! Có thể làm blog, kiểu Twitter, dịch vụ streaming, messenger hay bất cứ thứ gì. Bộ sưu tập ví dụ: https://nostrapps.com
Tôi tò mò liệu có thể có TLD miễn phí hay không. Chi phí thực tế của việc đăng ký domain là gì? Nghĩ đến việc Let's Encrypt đã phổ cập chứng chỉ miễn phí, tôi tự hỏi tại sao một tổ chức phi lợi nhuận lại không thể cung cấp domain miễn phí. Chúng không cần phải đẹp. Dùng chồng nhiều UUID v7 cũng được, miễn là duy nhất trên toàn cầu và miễn phí. Trình duyệt sẽ nhớ sau khi truy cập, nên địa chỉ dài cũng không thành vấn đề. Đây có phải là một ý tưởng thật sự tệ không?
Trong atproto, việc này do
did:plcđảm nhận. Có thể cấp ID miễn phí tại https://web.plc.directory/. Ví dụ ID của tôi là https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. Bạn có thể liên kết nó với domain bằng bản ghi TXT của domain đó để trỏ tớidid:plctương ứng.TLD miễn phí về mặt thực tế rất khó triển khai. TLD và public suffix list đi kèm nhiều quy tắc, chi phí và đặc thù vận hành; xem https://github.com/publicsuffix/list. Tuy nhiên, domain thông thường không phải TLD thì có thể dùng khá tự do, và cũng có thể phát miễn phí subdomain. Nhưng nếu thực sự vận hành một dịch vụ như vậy, bạn sẽ nhanh chóng bị spam/phishing và những đợt tấn công của dark internet vây lấy, đến mức hối hận vì đã vận hành. Cũng như bất kỳ ai cũng có thể làm một URL redirector, nhưng vận hành nó trong thực tế lại là câu chuyện khác; nếu làm nghiêm túc thì sớm muộn cũng đụng vấn đề. Đó là thực tế đáng tiếc.
Về bản chất, khái niệm này khá giống việc phân phối địa chỉ IPv6. Hiện nay phần lớn Internet gia đình được cấp IPv6 public theo block /64, nhưng đa số ISP chặn cổng bằng firewall nên gần như không tận dụng được. Hơn nữa, nếu đổi ISP thì cũng rất dễ mất địa chỉ. Để biến nó thành địa chỉ IPv6 thực sự vĩnh viễn và có thể mang theo, bạn sẽ phải phát miễn phí không gian địa chỉ provider-independent cho từng cá nhân, rồi còn phải nối nó vào global routing bằng BGP. Về lý thuyết là có thể, nhưng đến nay vẫn chưa từng được triển khai (giống với trạng thái trước khi Let's Encrypt ra đời). Tôi không rõ vì sao lại cần đặt tên dựa trên DNS, nhưng nếu mục tiêu không phải là ngắn và dễ nhớ thì DNS không quá phù hợp. Dù vậy, cách như ngrok — cấp domain qua gTLD riêng — thì vẫn đáng thử. Trên thực tế, ccTLD .me từng phát domain miễn phí kiểu này, đổi lại là chèn quảng cáo vào toàn bộ lưu lượng thông qua proxy trung gian.
.tk từng miễn phí và là ccTLD lớn nhất thế giới tính theo số lượng đăng ký. Nó chủ yếu bị lạm dụng. Facebook đã kiện đơn vị vận hành (công ty Hà Lan Freenom) vì liên quan đến phishing, nên giờ không còn miễn phí nữa.
Trước đây từng có sáng kiến TLD .FREE, nhưng do trục trặc triển khai và không đáp ứng thời hạn nên giờ gần như chìm xuồng https://icannwiki.org/.free
Hễ thấy bài của Dan là tôi bấm vào. Tôi hơi lo rằng web mở thành công chỉ nhờ lợi thế người đi đầu. Ngược lại, khi thấy mã nguồn mở thành công thì tôi lại có hy vọng. Tôi muốn được sống trong một thế giới nơi những thứ như atproto thành công. Thật đáng tiếc khi hiệu ứng mạng khiến ứng dụng tốt hơn lại không thể thắng.
HTML thành công vì nó “miễn phí”. Hồi đó có nhiều chuẩn hypermedia trả phí, nhưng khác với các đối thủ như vậy, nó có tính tiếp cận rất cao. Bất kỳ ai cũng có thể dễ dàng tạo trình duyệt hay máy chủ.
Việc ATProto được thiết kế để phá vỡ giới hạn của hiệu ứng mạng cũng là một ưu điểm lớn. Nếu mọi người cùng chuyển sang nền tảng dựa trên atproto, thì từ đó về sau mạng xã hội sẽ trở thành thứ mà ta chỉ cần “chuyển lần cuối cùng”. Xét đến đích cuối cùng, nó tạo ra một môi trường phi tập trung và cạnh tranh tự do.
Thực tế mà nói, tôi khó tưởng tượng những hệ thống như vậy có thể phổ biến rộng rãi. Tệp người dùng mục tiêu của mạng xã hội truyền thống và tệp người dùng thiên về phi tập trung vốn đã khác hẳn nhau. Phần lớn mọi người chỉ quan tâm nền tảng như một phương tiện, chứ không để ý đến hệ thống. Nếu rốt cuộc ai cũng chỉ tạo tài khoản bluesky, thì nó lại trở nên vô nghĩa vì vẫn tập trung vào vài dịch vụ lớn như trước.
Dù tất cả cùng tập trung ở bsky.social thì so với trước đây vẫn là một bước tiến cực lớn. Cũng như không ai nói web bị tập trung hóa chỉ vì có nhiều máy chủ dồn về AWS; quan trọng là bạn luôn có thể chuyển đi khi cần.
Trên thực tế, bluesky vẫn chưa triển khai federation hoàn chỉnh. Toàn bộ lưu lượng vẫn phụ thuộc vào một máy chủ router "BGS" duy nhất.
Đáng buồn thay, cuối cùng nguồn gốc của vấn đề vẫn là 'con người'.
Tôi có cảm xúc khá lẫn lộn về việc này. Một mặt, ý tưởng này đúng gu tôi hoàn toàn. Nó rất hợp với tinh thần của phong trào Indie web, nơi mọi người sở hữu nội dung của chính mình, và chất lượng của trang này cùng các bài viết thực sự rất ấn tượng. Mặt khác, hầu như không có mấy nhà phát triển thực sự áp dụng các chuẩn như thế này vào blog cá nhân hay dự án mã nguồn mở, và ngay cả trong giới làm vlog/blog hay người dùng phổ thông, mức độ chấp nhận cũng thấp. Việc có quá nhiều người thờ ơ với quyền sở hữu dữ liệu, tính mở và khả năng tương tác khiến tôi lo ngại. Có vẻ mọi người chỉ muốn feed kiểu TikTok, Instagram Reels. Tôi tôn trọng tầm nhìn và nỗ lực này, nhưng vẫn băn khoăn liệu nó có thể trở thành xu hướng chính thay vì chỉ là một sở thích ngách hay không.
Vẫn còn việc phải làm để cải thiện trải nghiệm nhà phát triển cho dễ hơn. Tuy vậy, tốc độ phát triển trong lĩnh vực này đang cực nhanh, nên tôi rất háo hức với 6–12 tháng tới. Phần lớn mọi người vẫn chưa hiểu rằng ATProto không chỉ áp dụng cho Bluesky, mà còn có thể dùng cho nhiều lĩnh vực đa dạng hơn rất nhiều; và sẽ cần thời gian để điều này được thị trường nhận ra rõ ràng hơn.
Tôi tò mò tại sao khái niệm 'quyền sở hữu dữ liệu' lại quan trọng đến vậy, và vì sao việc công chúng không quan tâm đến nó lại thực sự đáng lo. Trước đây con người vẫn tiêu thụ nội dung mà không có quyền sở hữu, như TV, sách, radio. Bây giờ chỉ là họ có thêm cơ hội đăng thứ gì đó để những người xung quanh nhìn thấy, nên tôi cũng tự hỏi việc thực sự 'sở hữu' một bài đăng Instagram có quan trọng đến thế không.
Tôi đồng ý với bạn. Rốt cuộc nếu chúng ta không chủ động lan truyền công nghệ này và thúc đẩy nó trở nên phổ biến hơn, thì nó sẽ không thể thành công. Biết đâu một ngày nào đó sẽ có một nhà sáng lập/CTO bị cuốn hút bởi open social tạo ra một ứng dụng thành công đại chúng; còn nếu không làm gì thì chắc chắn nó sẽ không bao giờ thành công.