s@ : Mạng xã hội phi tập trung dựa trên trang web tĩnh

• Giao thức mạng xã hội phi tập trung sử dụng website tĩnh, trong đó mỗi người dùng trực tiếp sở hữu và quản lý dữ liệu của mình
• Toàn bộ dữ liệu được lưu trong kho JSON được mã hóa, còn client trên trình duyệt sẽ tổng hợp feed và đăng bài
• Hoạt động bằng giao tiếp trực tiếp giữa website và trình duyệt của bạn bè, không cần máy chủ hay relay
• Tên miền của người dùng chính là danh tính, được xác thực qua HTTPS/TLS
• Với cấu trúc đơn giản, giao thức hiện thực hóa mạng xã hội tự chủ về dữ liệu, tập trung vào tương tác dựa trên niềm tin giữa các cá nhân

---

Tổng quan về giao thức sAT

• s@ là giao thức mạng xã hội phi tập trung dựa trên site tĩnh, trong đó mỗi người dùng lưu dữ liệu trên website của riêng mình
  • Toàn bộ dữ liệu được lưu dưới dạng tệp JSON được mã hóa, và client trên trình duyệt sẽ đọc chúng để đăng bài và tổng hợp feed
  • Hoạt động không có máy chủ trung tâm hay relay, dữ liệu đi trực tiếp từ site của người dùng đến trình duyệt của bạn bè
• Chỉ khi có quan hệ theo dõi lẫn nhau thì mới có thể trao đổi bài viết, loại bỏ cấu trúc xoay quanh influencer
• Giao thức không phụ thuộc vào dịch vụ hosting cụ thể như GitHub Pages

Danh tính (Identity)

• Tên miền của người dùng đóng vai trò là danh tính
• HTTPS/TLS xác thực rằng chủ sở hữu tên miền đã đăng nội dung đó

Khám phá (Discovery)

• Cung cấp phiên bản giao thức và khóa công khai tại đường dẫn https://{domain}/satellite/profile.json

  {
    "satproto_version": "0.1.0",
    "public_key": "<base64-encoded X25519 public key>"
  }
  

• Nếu dùng đường dẫn khác ngoài mặc định /satellite/, có thể chỉ định vị trí kho thực tế bằng tệp .well-known/satproto.json

Mô hình mã hóa (Encryption Model)

• Toàn bộ dữ liệu người dùng được lưu trong kho JSON được mã hóa, chỉ người dùng và follower mới có thể giải mã
• Dùng cặp khóa X25519 để công bố khóa công khai trong profile.json, còn khóa riêng được lưu trong localStorage của trình duyệt
• Dữ liệu bài viết được mã hóa bằng XChaCha20-Poly1305, còn khóa nội dung được mã hóa riêng cho từng follower bằng crypto_box_seal của libsodium
• Tệp keys/_self.json chứa khóa nội dung và bí mật đăng bài của người dùng, chỉ chính họ mới giải mã được

Xoay vòng khóa và bỏ theo dõi

• Khi bỏ theo dõi, hệ thống tạo khóa nội dung mới và mã hóa lại toàn bộ bài viết
• Tạo các phong bì khóa mới cho những follower còn lại và cập nhật keys/_self.json
• Người đã bị bỏ theo dõi sẽ không thể giải mã bài viết nữa

Luồng giải mã

• Khi người truy cập vào site của bạn mình, họ sẽ dùng khóa riêng của mình để giải mã keys/{follower-domain}.json nhằm lấy khóa nội dung
• Sau đó lấy posts/index.json và từng bài viết riêng lẻ (posts/{id}.json.enc) để giải mã

Cấu trúc dữ liệu (Data Schema)

• Mỗi bài viết được lưu trong một tệp mã hóa riêng, còn posts/index.json liệt kê ID bài viết theo thứ tự mới nhất trước
• Ví dụ đối tượng bài viết:

  {
    "id": "20260309T141500Z-a1b2",
    "author": "alice.com",
    "created_at": "2026-03-09T14:15:00Z",
    "text": "Hello, decentralized world!",
    "reply_to": null,
    "reply_to_author": null
  }
  

• ID bài viết gồm timestamp UTC theo ISO8601 và hash ngẫu nhiên 4 ký tự

Danh sách theo dõi (Follow List)

• Được lưu dưới dạng JSON thuần văn bản tại đường dẫn https://{domain}/satellite/follows/index.json

  { "follows": ["bob.example.com", "carol.example.com"] }
  

• Không được mã hóa, vì quan hệ theo dõi đã bị lộ qua các phong bì khóa

Tổng hợp feed (Feed Aggregation)

• Client đọc danh sách theo dõi và giải mã bài viết của từng follower để tạo thành feed theo trình tự thời gian
• Các bài viết được sắp xếp giảm dần theo created_at

Bình luận (Reply)

• Bình luận là các bài viết có trường reply_to và reply_to_author được thiết lập
• Không hỗ trợ bình luận lồng nhau, chỉ có thể trả lời trực tiếp bài viết cấp cao nhất
• Nếu không thể xem bài gốc (ví dụ không ở trạng thái theo dõi), bình luận sẽ không được hiển thị

Đăng bài (Publishing)

• Tạo bài viết mới → mã hóa bằng khóa nội dung → tải lên site tĩnh → cập nhật posts/index.json
• Có thể dùng GitHub Contents API để tải lên
• Bí mật đăng bài được lưu ở dạng mã hóa trong keys/_self.json

Ví dụ cấu trúc site tĩnh

{domain}/satellite/
  profile.json              # khóa công khai và hồ sơ
  posts/
    index.json              # danh sách ID bài viết
    {id}.json.enc           # bài viết được mã hóa
  follows/
    index.json              # danh sách theo dõi
  keys/
    _self.json              # khóa nội dung và thông tin xác thực
    {domain}.json           # khóa nội dung cho từng follower

FAQ

• “Có phải RSS + mã hóa không?” → Có
• “Có phải là phiên bản không có firehose của AT Protocol không?” → Có
• “Có mở rộng được không?” → Không (“tình bạn cũng không mở rộng được”)
• “s có phải viết tắt của slow/shitty không?” → Có
• “Có thể tự host không?” → Có, nhưng cần bật CORS

[GN⁺]

Ý kiến trên Hacker News

• Có cảm giác dự án này cũng gặp những vấn đề mà nhiều mạng xã hội thay thế/tự host khác từng gặp
  Thiết kế lấy mã hóa làm trung tâm thì hay thật, nhưng khi đổi sang thiết bị mới sẽ khó khôi phục danh sách theo dõi bạn bè, và các khái niệm như cặp khóa X25519 cũng quá khó hiểu với người dùng phổ thông
  Tôi nghĩ cấu trúc dựa trên ID và mật khẩu để máy chủ xử lý phần mã hóa thay là thực tế hơn
  Chính hướng tiếp cận đó mới có thể trở thành giải pháp thay thế Big Tech mà cả người không rành kỹ thuật cũng dùng được

  • Tôi cũng nghĩ tương tự. Nhưng nếu muốn một thế giới không có bên trung gian, thì cuối cùng người dùng không chuyên cũng cần một sự thay đổi văn hóa theo hướng tự quản lý lấy phần nào
  • Sau khi thiết lập ban đầu, chỉ cần xuất private key ra và lưu trong trình quản lý mật khẩu là được. Nếu không tự triển khai giao thức thì cũng không quá phức tạp
    Có điều với gia đình hay bạn bè thì có thể tôi vẫn phải cài giúp. Dù vậy, nếu họ có được website của riêng mình thì có lẽ họ sẽ khá thích
  • Theo FAQ ở cuối bài, đây gần hơn với một thử nghiệm ý niệm lược bớt một số yếu tố của AT Protocol (BlueSky)
    Trên thực tế có thể xem như ý tưởng tích hợp blog tĩnh vào BlueSky.
    Có thể cải thiện bằng cách tận dụng danh tính BlueSky, hoặc dùng plugin cho static site generator để tự động lấy thông tin xác thực
  • Trước đây tôi từng thử ý tưởng dùng email làm lớp truyền tải cho mạng xã hội nhưng đã thất bại
    Xem bài viết liên quan
  • Tôi không chắc mục tiêu có phải là thay thế Big Tech hay không. Chỉ cần cộng đồng nhỏ dùng thấy hữu ích thì như vậy cũng đã là thành công

• Tôi khá sốc ở chỗ họ lưu private key trong localStorage của trình duyệt
  Nếu đặt lại cài đặt trình duyệt hoặc cài lại thì dữ liệu sẽ mất, việc sao lưu cũng khó, còn mã độc thì lại dễ truy cập
  Cuối cùng nếu mất khóa thì feed cũng biến mất vĩnh viễn, nên nguy cơ người dùng rời đi là rất lớn

  • Đồng ý. Việc họ dùng những thuật ngữ như “cặp khóa X25519” một cách rất tự nhiên cho thấy dự án này gần với thử nghiệm ý niệm hơn là nhắm tới phổ cập đại chúng
  • Tôi nghĩ chỉ cần một nút “xuất khóa ra vị trí an toàn” là giải quyết được. Có thể dùng đoạn mã đơn giản như URL.createObjectURL(localStorage.getItem(...)) để gợi ý lưu ra file
  • Đừng vì theo đuổi sự hoàn hảo mà bỏ lỡ một giải pháp 'đủ tốt'. Chỉ cần thêm tính năng tải xuống/tải lên khóa là phần lớn vấn đề đã được giải quyết
    Tất nhiên nếu mất khóa thì sẽ không truy cập được, nhưng người dùng 2FA hay ví tiền mã hóa cũng chấp nhận trách nhiệm tương tự, nên không phải chuyện hoàn toàn bất khả thi

• Có người đề xuất dùng /.well-known/ thay cho đường dẫn /satellite/
  Họ viện dẫn tiêu chuẩn Well-known URI

  • Có người đáp lại đùa rằng nên gọi là “.poorly-known”
  • Có người lo ngại vì nhớ lại thời kỳ đầu của AT Proto từng dùng đường dẫn gốc và tạo ra lỗ hổng bảo mật
  • Có ý kiến cho rằng .well-known dành cho toàn bộ host nên không phù hợp ở cấp stream. Họ cho rằng tách nhiều thư mục riêng ra sẽ tốt hơn

• Tôi thấy đề xuất .well-known/ đáng để cân nhắc nghiêm túc
  Nó đã là chuẩn đăng ký IANA được dùng rộng rãi, và nhiều tệp phục vụ bảo mật/khám phá đều nằm ở đó
  Nếu đặt tại /.well-known/satproto.json thay vì /satellite/satproto.json thì vừa tránh xung đột vừa thể hiện rõ đây là endpoint của giao thức

  • Nhưng cũng có ý kiến phản biện rằng .well-known hoạt động ở cấp host, nên nếu muốn có nhiều thư mục theo từng tài khoản thì nó không phù hợp

• Giao thức mạng xã hội không nên tồn tại chỉ vì bản thân công nghệ, mà phải đem lại lợi ích trực tiếp cho người dùng
  Cũng như BitTorrent, phải khiến người ta tham gia đơn giản vì họ cần nó thì mới tạo được hiệu ứng mạng
  Một hướng tiếp cận bắt đầu từ việc quản lý dữ liệu và sự tiện lợi khi chia sẻ có lẽ thực tế hơn

  • Tôi đã thử nhiều SNS phi tập trung, và rốt cuộc thấy rằng nếu không có kích thích dopamine thì người ta sẽ không ghé vào
    Lemmy hay Pixelfed có quá ít nội dung nên tạo cảm giác như “nơi chẳng có gì xảy ra”
    Signal cũng vậy, chỉ phục vụ nhắn tin đơn thuần nên không có lý do để lướt
    Cuối cùng vẫn phải có nội dung và FOMO (nỗi sợ bị bỏ lỡ) thì người dùng mới quay lại thường xuyên
  • Dù vậy, thiết kế giao thức tốt vẫn rất quan trọng. Nếu quá phức tạp hoặc không chuẩn bị cho tương lai thì ý tưởng hay đến đâu cũng nhanh chóng biến mất

• Nếu thực sự muốn tạo ra một mạng xã hội/ứng dụng nhắn tin E2EE phi tập trung thì cần cấu trúc giống Discord, nơi mỗi máy chủ thực sự được host độc lập
  Tài khoản nên được quản lý bằng giao thức như Nostr, và hệ thống nên chạy trên Yggdrasil Network để giảm phụ thuộc vào IPv4/6 và DNS
  Nếu bọc lưu lượng trong HTTPS và tự động hóa việc vượt NAT thì ai cũng có thể vận hành máy chủ
  Chỉ khi đó mới có thể thoát khỏi sự kiểm soát của Big Tech và chính phủ

  • Nhưng chỉ công nghệ thôi là chưa đủ. Đại chúng cuối cùng vẫn sẽ đổ về những nền tảng có vốn marketing lớn
  • Tôi cho rằng cách tiếp cận bằng mạng phân tán dựa trên cache như BitTorrent hay IPFS tốt hơn
    Dù máy chủ biến mất thì dữ liệu vẫn còn ở edge, và trình duyệt của người dùng thậm chí có thể đóng vai trò host
    Tham khảo ephemeral-p2p-project
  • Kiểu kiến trúc này đang được thử nghiệm tại geogram.radio
    Mỗi thiết bị hoạt động như một máy chủ, và WebRTC được dùng để hiện thực nhắn tin P2P hoàn toàn
    Ngay cả khi không có internet, vẫn có thể trao đổi dữ liệu qua kết nối radio
  • Tôi đang làm thứ gì đó tương tự ở Mikoto Platforms. “Spaces” có thể tồn tại trên bất kỳ node vật lý nào, còn DM thì được định tuyến E2EE qua nhiều node

• Trước đây từng có những nỗ lực mạng xã hội hoàn toàn phi tập trung như FOAF hay Pingback

  • Phiên bản hiện đại của hướng đó là Webmention
    Tôi khuyên nên xem IndieWeb wiki vì đây là nguồn tài liệu rất tốt để tìm hiểu các công nghệ xã hội dựa trên web cá nhân như vậy
  • Một ví dụ khác cũng không nên quên là XFN

• Khi đọc mô tả “sAT Protocol là một mạng xã hội phi tập trung dựa trên static site”, tôi đã muốn vẽ một biểu đồ lông mày cứ nhướng lên dần

  • Dù vậy, vì phạm vi mục tiêu khá hẹp nên tôi vẫn thấy đây là một hệ thống hợp lý
    Chỉ là ciphertext có thể bị liệt kê công khai, nên trong thời đại máy tính lượng tử có thể sẽ rủi ro
  • Nó khá giống tổ hợp PGP + RSS. Mỗi feed được mã hóa để chỉ người phù hợp mới giải mã được
    Nó phù hợp với mạng quy mô nhỏ, nhưng sẽ khó mở rộng lớn vì vấn đề phân phối và xoay vòng khóa
  • Tôi hiểu ý tưởng này theo nghĩa “truyền cơ sở dữ liệu để client tự build static site”
  • Phần “Key Rotation (Unfollow)” được diễn tả đùa bằng ASCII art

• Từ góc nhìn người dùng, tôi thấy cần giải thích trước hết đây là dịch vụ làm gì
  Toàn là các thuật ngữ kỹ thuật như fork, path, JSON, mã hóa nên không hình dung ra kịch bản sử dụng thực tế

  • Dù vậy, tôi có khá nhiều bạn bè hứng thú với công nghệ, nên đang nghĩ sẽ thử nghiệm cùng những người có gu bảo mật kiểu hoang tưởng
    Đây là vùng mà Mastodon hay Signal chưa đáp ứng được, nên đáng để đem ra thử

• Mỗi khi thấy những thử nghiệm mạng phi tập trung như thế này tôi đều thấy rất thú vị
  Dù về cấu trúc có nhiều vấn đề, việc học những cách kết hợp mới vẫn rất vui
  Chỉ là việc phải mã hóa lại và build lại toàn bộ site mỗi lần follow/unfollow thì quá phiền
  Ngoài ra, cấu trúc mà nếu không follow thì không thấy bình luận cũng hạn chế khả năng mở rộng rất mạnh
  Dù vậy, việc pha trộn RSS, ActivityPub và static site vẫn rất hấp dẫn
  Nỗ lực hiện thực kiểm soát truy cập danh sách bạn bè động bằng static site vừa mâu thuẫn vừa thú vị
  Cuối cùng đây là một cấu trúc khiến tôi vừa yêu vừa ghét. Nhưng tôi vẫn vui và biết ơn vì có những thử nghiệm như thế này