- Mở rộng khái niệm điện toán cá nhân lấy tệp làm trung tâm sang điện toán xã hội, mô tả một cấu trúc trong đó mọi nội dung do người dùng tạo ra đều thuộc sở hữu của chính họ thay vì của ứng dụng
- Dựa trên giao thức AT, đề xuất khái niệm hệ thống tệp xã hội phi tập trung cho phép khả năng tương tác dữ liệu giữa các ứng dụng
- Mỗi người dùng có một ‘everything folder’ hoặc kho lưu trữ (repository) của riêng mình, nơi bài viết, lượt thích, theo dõi, v.v. được lưu dưới dạng tệp (record) dựa trên JSON
- Thông qua DID (Decentralized Identifier) và hệ URI
at://, có thể duy trì liên kết định danh vĩnh viễn ngay cả khi thay đổi nơi lưu trữ hoặc đổi handle
- Cấu trúc này hình thành một hệ sinh thái xã hội lấy dữ liệu làm trung tâm thay vì lấy ứng dụng làm trung tâm, cho phép bất kỳ ai cũng có thể tạo ứng dụng mới hoạt động trên dữ liệu hiện có
Mô hình tệp và sự mở rộng sang xã hội
- Tệp vốn dĩ tồn tại trong không gian do người dùng kiểm soát thay vì nằm bên trong ứng dụng, và ứng dụng chỉ đóng vai trò là công cụ đọc và ghi tệp
- Các định dạng tệp mở như
.svg cho phép nhiều ứng dụng chia sẻ cùng một dữ liệu
- Theo nguyên tắc “định dạng tệp chính là API”, khả năng tương tác giữa các ứng dụng trở nên khả thi
- Khi áp dụng khái niệm này cho các ứng dụng xã hội, các hành vi như bài viết, theo dõi, lượt thích cũng có thể được xử lý như tệp
- Tồn tại một ‘everything folder’ chứa toàn bộ hoạt động trực tuyến của người dùng
- Ứng dụng phản ánh dữ liệu trong thư mục này, còn thư mục đóng vai trò là nguồn chân lý duy nhất (source of truth)
Giao thức AT và hệ thống tệp xã hội
- Giao thức AT là công nghệ hiện thực hóa cấu trúc này, và Bluesky, Leaflet, Tangled, Semble, Wisp đều hoạt động dựa trên nó
- Ứng dụng không sở hữu dữ liệu người dùng; nhờ lưu trữ dữ liệu tách biệt theo đơn vị tệp, các ứng dụng mới có thể tái sử dụng dữ liệu hiện có
- Các thư mục của mọi người dùng hợp lại thành một hệ thống tệp xã hội phi tập trung
Cấu trúc record và collection
- Mỗi bài viết được biểu diễn dưới dạng tệp JSON (record), không bao gồm thông tin tác giả hay dữ liệu phát sinh như số lượt thích
- Ví dụ:
{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
- Tên tệp được tạo bằng khóa record dựa trên dấu thời gian (timestamp) để tránh xung đột
- Cấu trúc tệp được định nghĩa bằng schema gọi là lexicon, và mỗi ứng dụng có thể tự thiết kế lexicon riêng
- Ví dụ:
com.twitter.post, fm.last.scrobble, io.letterboxd.review
- Ngay cả với cùng một khái niệm, mỗi ứng dụng vẫn có thể có lexicon khác nhau, và namespace dựa trên domain giúp tránh xung đột
Xác thực và độ tin cậy
- Không tồn tại Lexicon Police — không ứng dụng nào có thể ép buộc dữ liệu của ứng dụng khác
- Ứng dụng sẽ xác thực dữ liệu khi đọc (validate on read) và bỏ qua nếu dữ liệu không hợp lệ
- Khi thay đổi lexicon, việc duy trì tương thích ngược là bắt buộc; các thay đổi phá vỡ tương thích phải được tách sang lexicon mới
- Lexicon có thể được công bố công khai, đồng thời việc chứng minh quyền sở hữu domain được thực hiện thông qua DNS
Liên kết và danh tính (Identity)
- Các ‘lượt thích’ hoặc ‘trả lời’ do người dùng tạo ra cần tham chiếu tới record khác, vì vậy cần một hệ thống liên kết vĩnh viễn
- Sau nhiều lần thử nghiệm, DID (Decentralized Identifier) được sử dụng để thiết lập danh tính
- Một định danh như
did:plc:6wpkkitfdkgthatfvspcfmjo là không thể thay đổi
- Mỗi DID được diễn giải thành một tài liệu chứa thông tin hiện tại về nơi lưu trữ, handle, khóa công khai
- URI
at:// kết hợp DID, collection và khóa record để cung cấp liên kết không bị hỏng ngay cả khi thay đổi nơi lưu trữ
- Ví dụ:
at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5
Siêu liên kết JSON và biểu diễn quan hệ
- Mỗi ‘lượt thích’, ‘repost’, ‘trả lời’ đều có cấu trúc JSON kiểu siêu liên kết tham chiếu đến record khác
- Ví dụ: trường
parent tham chiếu tới URI at:// của một bài viết khác
- Mọi thông tin trên UI (tác giả, văn bản, số lượt thích, v.v.) đều có thể được tính toán từ các liên kết giữa những tệp này
Repository và luồng dữ liệu
- ‘Everything folder’ của người dùng được gọi là repository, được định danh bằng DID
- Bên trong có nhiều collection và record
- Repository có thể được lưu trữ ở bất kỳ đâu và liên kết vẫn được giữ nguyên khi di chuyển
- Ứng dụng có thể đọc repository như một hệ thống tệp hoặc đăng ký bằng stream (WebSocket) để đồng bộ thời gian thực
- Mỗi commit được xác thực bằng cây băm có chữ ký (Merkle tree) để ngăn chặn giả mạo dữ liệu
- Máy chủ relay chỉ đơn thuần chuyển tiếp lại các sự kiện, nhưng vẫn tạo được độ tin cậy nhờ cấu trúc có thể xác minh
Khám phá Atmosphere và các ví dụ thực tế
- pdsls.dev hoạt động như một trình khám phá hệ thống tệp xã hội, cho phép nhập DID hoặc handle
- Có thể trực tiếp xem từng collection và record
- Ứng dụng ví dụ Sidetrail phản ánh thay đổi record của người dùng theo thời gian thực, cho thấy dữ liệu tồn tại trong repository chứ không phải trong ứng dụng
- Bản demo teal.fm Relay trực quan hóa lịch sử phát nhạc (scrobble) bằng cách lập chỉ mục các record
fm.teal.alpha.feed.play mà không cần API thực tế
- Có thể thực thi truy vấn GraphQL dựa trên Lexicon bằng công cụ
lex-gql
- Trên Bluesky, người dùng có thể tự phân phối thuật toán feed tùy chỉnh do chính họ tạo ra
- Ví dụ: feed “For You” của
@spacecowboy17.bsky.social hoạt động độc lập, cho phép bên thứ ba cải thiện chức năng trên dữ liệu dùng chung
Kết luận
- Hệ thống tệp xã hội đưa ra một cấu trúc Internet lấy dữ liệu làm trung tâm thay vì lấy ứng dụng làm trung tâm
- Người dùng sở hữu kho dữ liệu của riêng mình, còn ứng dụng phản ứng và hoạt động trên đó
- Mục tiêu là chuyển từ “ứng dụng làm mọi thứ” sang “hệ sinh thái nơi mọi thứ đều có thể”
1 bình luận
Ý kiến trên Hacker News
Ứng dụng có thể biến mất nhưng tệp vẫn còn
Bài viết của swyx nhấn mạnh rằng những công việc tồn tại lâu dài cuối cùng đều hiện diện dưới dạng tệp/dữ liệu
Dữ liệu có thể được phân tích mà không cần quyền hạn, và ngay cả khi bị hỏng một phần thì vẫn hữu ích, nhưng các động lực kinh tế vẫn xoay quanh code
Khi các tiêu chuẩn xuất hiện để code có thể tiếp nhận và xuất dữ liệu, điều đó sẽ tạo ra giá trị rất lớn cho toàn bộ nền văn minh
Tôi nghĩ một trong những đòn bẩy mạnh nhất mà chúng ta có là khiến hệ sinh thái nhà phát triển thúc đẩy các công ty như Google, Microsoft, OpenAI, Anthropic tự nguyện tham gia chuẩn hóa dữ liệu
Nhưng các ứng dụng hiện nay tồn tại dưới dạng website phụ thuộc vào doanh thu quảng cáo, nên không hề có động lực để vận hành theo cấu trúc như vậy
Nhìn Apple cũng thấy nhiều trường hợp tiêu chuẩn không thể thay đổi thế giới
Nếu trường createdAt là giá trị tùy ý, vậy chẳng phải tôi cũng có thể chỉnh sửa hồi tố bản ghi theo ý mình sao?
Tôi muốn biết có cách nào để xác minh thời điểm tạo và việc có bị chỉnh sửa sau đó hay không thông qua chữ ký số (signing) không
Có thể hiểu POSSE và AT Protocol là những chợ tương thích lẫn nhau
Giống như Reddit hay Instagram, nơi nội dung do người dùng tạo ra là hàng hóa, sự chú ý là tiền tệ, còn nền tảng kiếm tiền từ quảng cáo hoặc dữ liệu hành vi
Nhưng cấu trúc đó không phải là điều tất yếu.
Nếu người dùng có quyền sở hữu dữ liệu xã hội của chính mình, thì ứng dụng sẽ chuyển thành giao diện đọc dữ liệu
Tôi cũng đang áp dụng mô hình tương tự cho thương mại — người bán tự host logic đơn hàng/thanh toán của mình, còn marketplace tích hợp trực tiếp với API của người bán
Làm như vậy có thể giảm phí nền tảng và trả lại quyền sở hữu cho chủ thể tạo ra giá trị
Bài viết quá chi tiết nên có cảm giác hơi dài so với việc truyền tải ý chính
Dù vậy, phép so sánh rất xuất sắc. Nếu có trình duyệt tệp cho PDS thì có lẽ sẽ giúp người ta tự trải nghiệm trực tiếp
PDS của Bluesky về cơ bản là một hệ thống tệp công khai, và giống Git ở chỗ replication đã được đưa vào thiết kế
Việc sao chép thì không thể kiểm soát, nhưng cũng có lợi thế là sao lưu tự động
Rốt cuộc, những gì đã đưa lên PDS sẽ tồn tại như hồ sơ vĩnh viễn nên cần phải cẩn thận
Nếu nó hữu ích nhưng dài, thì người khác có thể chỉ lấy phần họ cần
Ở phần demo cuối bài có thể xem ví dụ thực tế về file manager
Cụm “một thế giới nơi ai cũng là scraper” chính là bản chất của vấn đề
Tôi cho rằng khái niệm “tệp” đã lỗi thời
Nếu coi mọi thứ là dữ liệu blob dựa trên hash thì nhiều vấn đề sẽ biến mất
Thứ người dùng muốn không phải là ứng dụng mà là khả năng (capability)
Ví dụ như “khả năng xem video yoga” hay “khả năng chia sẻ tình hình gần đây với người quen”, chứ không phải bản thân YouTube hay Bluesky
Ứng dụng chỉ là cách gom những khả năng đó lại với nhau
Cần những workflow tùy biến kiểu như tìm kiếm một từ trong ứng dụng nhắn tin rồi chia sẻ ngay kết quả đó trong khung chat
Tôi lấy cảm hứng từ PerKeep
Nó được dùng như một phép ẩn dụ để giải thích “mối quan hệ nhiều-nhiều giữa ứng dụng và định dạng tệp”
Nếu xem mô tả cấu trúc repository của ATProto, nó được xây dựng theo cấu trúc định địa chỉ nội dung dựa trên Merkle-tree
Lexicon không phải quan hệ 1:1 với ứng dụng, nên AT thực ra đã hướng tới thời kỳ hậu-ứng dụng (post-app) rồi
Tôi nghĩ nền tảng khép kín (walled garden) là kết quả của sở thích người tiêu dùng
Khi Internet mở tung mọi thứ ra, mọi người lại muốn những không gian nhỏ xoay quanh một nền văn hóa hay ý tưởng cụ thể
IG hay Snap giống như những nhóm chat được phân mảnh như thế
Việc bài đăng IG của tôi không tự động được chia sẻ sang HN hay Truth Social lại là điều tốt hơn
Tôi không thật sự cảm nhận được giá trị của tính di động dữ liệu. Việc giao cắt giữa các nền tảng có ngữ cảnh khác nhau có vẻ không có nhiều ý nghĩa
Anisota mà tôi làm được thiết kế để hỗ trợ cả tệp của Bluesky lẫn Leaflet
Ví dụ có thể xem cùng một bài đăng trên Bluesky và Anisota
Ngoài ra còn có dự án Aturi để cung cấp liên kết phổ dụng cho nội dung dựa trên ATProto
Trong ATProto, nếu là các ứng dụng dùng cùng một Lexicon thì hoàn toàn có thể di chuyển trọn vẹn danh tính và dữ liệu
Ảnh gốc nằm ở máy cục bộ của tôi, còn mỗi nền tảng chỉ là một cách thể hiện khác nhau mà thôi
Tôi không muốn có sự tích hợp vô nghĩa giữa các nền tảng
AT chỉ đơn giản là cho phép khả năng tương tác, chứ không gộp mọi thứ lại
Ví dụ Leaflet sẽ lấy các bài đăng Bluesky về để hiển thị nhằm theo dõi trích dẫn
Nhờ cấu trúc này, ngay cả khi fork sản phẩm thì vẫn hoàn toàn tương thích với mạng, từ đó thúc đẩy cạnh tranh mạnh mẽ hơn
Trên thực tế, Blacksky là một ví dụ fork Bluesky để áp dụng chính sách kiểm duyệt khác
Những bài Dan viết lúc nào cũng thú vị. Đọc một lúc rồi cuối cùng cũng nhận ra đúng là anh ấy là tác giả
Tôi hoài nghi về mô hình dữ liệu tự mô tả (self-describing data model)
Tuyên bố của ATProto rằng “chỉ cần thêm Lexicon là sẽ có client” nghe có vẻ hơi phóng đại
Trên thực tế, để tạo UI thì phải hiểu ý nghĩa của dữ liệu, mà chỉ Lexicon thôi thì không đủ
Cuối cùng cũng chẳng khác nhiều so với việc đọc tài liệu rồi tự triển khai
Chuẩn hóa thì tốt, nhưng chưa đến mức là một vấn đề tầm cơ sở dữ liệu được sao chép trên quy mô toàn cầu
Dù vậy, tôi vẫn đánh giá cao nỗ lực giảm lock-in
Chỉ là vấn đề thật sự mà Twitter từng gặp phải lại là những yếu tố xã hội như nội dung chính trị hay spam
Nhưng nếu một dịch vụ từng được yêu thích như Bento biến mất, sẽ có ai đó muốn khôi phục dữ liệu đó
Chẳng hạn Blento là dịch vụ thay thế Bento dựa trên ATProto, mã nguồn mở nên ai cũng có thể dựng lại
Cấu trúc như vậy là một bước tiến có ý nghĩa để đảm bảo tính bền vững của nội dung người dùng
Khi đọc “The Unix Programming Environment”, tôi nhận ra rằng chỉ với các công cụ đơn giản và tệp văn bản cũng có thể làm được rất nhiều thứ
Điều đó khiến tôi tưởng tượng Slack sẽ ra sao nếu được xây theo phong cách UNIX xoay quanh tệp
Tôi muốn quay lại những hệ thống đơn giản và có thể kết hợp
Việc tuần tự hóa dễ đọc với con người thì tốt, nhưng cứ phải parse rồi format lại mỗi lần thì rất khổ sở
Khái niệm các nền tảng xã hội mới chia sẻ giao thức chung và định dạng dữ liệu chung trong môi trường phân tán/liên hợp là rất thú vị
Nhưng có lẽ sẽ khó thuyết phục các nền tảng thương mại hiện tại
Nếu những tiêu chuẩn như vậy được chấp nhận, các công cụ social marketing sẽ dễ quản lý hợp nhất nhiều mạng lưới hơn
Tuy vậy, thực tế hiện nay vẫn là các hệ sinh thái khép kín như Facebook, Instagram, TikTok đang thống trị