` nằm ở đâu

(overreacted.io)

2 điểm bởi GN⁺ 2025-10-05 | 1 bình luận | Chia sẻ qua WhatsApp

AT Protocol là giao thức làm nền tảng cho mạng xã hội phi tập trung, trong đó mọi dữ liệu đều được định danh bằng URI at://
URI at:// chỉ định người tạo dữ liệu (người dùng) làm authority, còn vị trí thực tế nơi dữ liệu được lưu trữ phải được tra cứu riêng
Quy trình phân giải URI diễn ra theo thứ tự: chuyển handle thành danh tính (DID), tra cứu máy chủ lưu trữ thông qua tài liệu DID, rồi yêu cầu dữ liệu JSON từ máy chủ đó
Hỗ trợ hai kiểu DID (did:web, did:plc), mỗi kiểu có ưu nhược điểm và cách bảo toàn dữ liệu khác nhau
Cách tiếp cận này nhấn mạnh rằng quyền sở hữu dữ liệu thuộc về người dùng, đồng thời bảo đảm tính bền vững của liên kết ngay cả khi handle và nơi lưu trữ thay đổi

AT Protocol, URI `at://`, và quá trình phân giải danh tính của dữ liệu xã hội

# Cấu trúc cơ bản của AT Protocol và URI `at://`

AT Protocol cho phép nhiều máy chủ phân tán giao tiếp với nhau theo một tiêu chuẩn nhất định, và toàn bộ hệ này được gọi là “atmosphere”
Mỗi dữ liệu trong atmosphere được gán một URI duy nhất bắt đầu bằng at://, URI này đóng vai trò như một liên kết tới dữ liệu JSON
Khác với cấu trúc URI truyền thống, trong AT Protocol, người tạo dữ liệu (người dùng) được đặt làm authority của URI
- Ví dụ, trong dạng at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z, ruuuuu.de cho biết chủ sở hữu của dữ liệu đó
Máy chủ vật lý thực sự lưu trữ dữ liệu không được đưa trực tiếp vào URI, nên cần một quy trình phân giải bổ sung để tìm ra

# Ba bước trong quy trình phân giải URI `at://`

Để ánh xạ URI at:// tới dữ liệu thực tế (JSON), cần ba bước
1. Chuyển handle (ruuuuu.de v.v.) thành danh tính (DID: Decentralized Identifier)
  - Handle là bí danh để nhận diện người dùng và có thể thay đổi
  - Cần chuyển sang DID là ID toàn cục bất biến
  - Cách chuyển đổi:
    - Truy vấn bản ghi DNS TXT tại _atproto.<handle> → kiểm tra giá trị did=...
    - Hoặc truy cập https://<handle>/.well-known/atproto-did
2. Xác định thông tin lưu trữ dữ liệu bằng cách tra cứu tài liệu DID (DID Document)
  - Tài liệu DID chứa các thông tin như khóa công khai của danh tính đó, service endpoint (máy chủ), v.v.
  - Với did:web:~, dùng cách tiếp cận dựa trên tên miền (https://tên-miền/.well-known/did.json)
  - Với did:plc:~, tra cứu trong PLC directory (https://plc.directory/DID)
  - Service endpoint (serviceEndpoint) chính là máy chủ lưu trữ dữ liệu thực tế
3. Yêu cầu dữ liệu JSON qua API của máy chủ lưu trữ
  - Gửi các phần của at:// làm tham số tới endpoint com.atproto.repo.getRecord để yêu cầu dữ liệu
  - JSON trả về chính là dữ liệu thực được ánh xạ với URI at://

# Giải thích quy trình phân giải qua ví dụ

Ví dụ: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
- Bước 1: ruuuuu.de → did:web:iam.ruuuuu.de (xác nhận qua DNS TXT record hoặc .well-known)
- Bước 2: tra cứu DID Document tại https://iam.ruuuuu.de/.well-known/did.json → serviceEndpoint là https://blacksky.app
- Bước 3: yêu cầu tới https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → trả về JSON thực tế
```
{
  "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
  "cid": "...",
  "value": {
    "text": "posting from did:web, like a boss",
    "$type": "app.bsky.feed.post",
    ...
  }
}
```
Ngay cả khi handle thay đổi, nếu dùng URI at:// dựa trên DID (permalink), liên kết giữa tài khoản và dữ liệu vẫn được duy trì

# Sự khác nhau giữa hai kiểu DID: `did:web` và `did:plc`

did:web:
- Có thể tự quản lý và xác thực tên miền của mình
- Nếu mất quyền kiểm soát tên miền, có thể mất toàn bộ ID
did:plc:
- PLC (Public Ledger of Credentials) là chủ thể vận hành ID
- Không gắn với tên miền, nhưng có khả năng tồn tại mức kiểm soát hạn chế như việc phía vận hành PLC từ chối cập nhật
- Mọi lịch sử thay đổi đều có thể được xác minh và theo dõi bằng hash

# Tách biệt danh tính, lưu trữ và dữ liệu, cùng tính bền vững

at:// tách biệt danh tính và nơi lưu trữ dữ liệu, nhờ đó cho phép dữ liệu người dùng có tính di động và tạo liên kết bền vững
Handle (bí danh) có thể thay đổi bất cứ lúc nào, và máy chủ lưu trữ cũng có thể chuyển đi tương tự
DID (danh tính) là bất biến, vì vậy URI at:// dựa trên DID có thể được dùng như permalink lâu dài
Tài liệu DID chứa đầy đủ bằng chứng sở hữu handle, khóa xác minh chữ ký và thông tin lưu trữ, từ đó bảo đảm độ tin cậy và tính linh hoạt

# Ứng dụng thực tế và ghi chú cho lập trình viên

Trong thực tế, phần lớn ứng dụng dựa trên AT sẽ nhận dữ liệu dạng push qua Websocket rồi tổng hợp vào DB nội bộ
Dù vậy, việc nắm vững cách phân giải URI at:// vẫn là điều thiết yếu để hiểu đặc tính mạng và bảo đảm khả năng di chuyển dữ liệu
Hệ thống at:// cung cấp một lớp trừu tượng mạng xã hội trên nền HTTP, DNS và JSON, qua đó hiện thực hóa về mặt kỹ thuật việc người dùng sở hữu dữ liệu của mình

# Kết luận

AT Protocol và URI at:// đưa danh tính, khả năng liên kết và tính bền vững của dữ liệu xã hội lên một bước tiến kỹ thuật mới
Lập trình viên cần nắm rõ workflow cốt lõi như phân giải handle, sử dụng DID, cấu trúc tài liệu DID và cách yêu cầu dữ liệu thực tế
Nhờ cấu trúc này, người dùng có thể đạt được tính linh hoạt và quyền sở hữu đối với nội dung, danh tính và vị trí lưu trữ của mình

1 bình luận

GN⁺ 2025-10-05

Ý kiến trên Hacker News

Gần đây đọc vài bài về ATProto nên thử đăng ký bsky, nhưng thứ hiện ra chỉ là vô tận các câu chuyện chính trị Mỹ, bấm "ít thấy nội dung này hơn" liên tục mà cũng chẳng ăn thua, tự hỏi không biết đó có phải bản chất của nền tảng này không, cứ phải xem mãi những ý kiến quen thuộc về các cuộc tranh cãi kỳ quặc ở nước ngoài thì khá mệt mỏi về mặt tinh thần
- Với tài khoản mới, feed "Discover" không thực sự tốt, khi tích lũy thêm dữ liệu like và follow thì sẽ cải thiện dần, nhưng vẫn chưa thể gọi là tốt nhất, cá nhân tôi khuyên dùng feed "For You", feed này phản ánh like khá nhanh và đẩy ít nội dung ngẫu nhiên hơn, feed "Dev Trending" cũng khá ổn For You Feed, Dev Trending
- Cách tôi làm là tìm vài tài khoản ổn rồi follow, sau đó ẩn hẳn tab "Discovery", rồi từ các tương tác của những người trong danh sách follower/following mà tự nhiên mở rộng danh sách follow, hoặc tìm tài khoản trên blog hay website rồi follow, theo tôi đây mới là cách nó vận hành như một mạng xã hội thực sự, còn bị nhồi nội dung gợi ý tự động thì không hay lắm
- May là bsky có feed phi thuật toán chỉ hiển thị bài của những người bạn follow, tôi nghĩ đó là cách duy nhất để giữ gìn sức khỏe tinh thần
- Tôi đã dùng bsky hơn 1 năm nhưng phần lớn vẫn là nội dung chính trị Mỹ, với tôi là người châu Âu thì nó chỉ như tạp âm, nên tôi quay lại Mastodon, để follow người trong giới công nghệ thì Mastodon tốt hơn nhiều, còn tin tức thì tôi lấy hết qua RSS trên feedly, giờ tôi cũng không rõ cần Bluesky để làm gì, cảm giác nó chỉ là phiên bản thiên tả của Twitter, còn công nghệ thì thú vị như một bản tiến hóa của Nostr, nhưng cũng chỉ đến thế
- Khuyên bạn vào Settings > Contents and Media > Your Interests > tắt mục News and Politics, còn nếu bạn chỉ muốn xem tin tức và nội dung chính trị của nước khác chứ không phải Mỹ thì tôi cũng không biết có cách nào đặc biệt
Tôi vẫn chưa rõ dự án này có thật sự giải quyết vấn đề danh tính và quyền sở hữu dữ liệu theo cách có ý nghĩa hay không, về mặt danh tính thì hoặc là dùng domain của mình hoặc dùng domain của người khác (như Bluesky), mà đa số mọi người không có domain nên rốt cuộc danh tính của họ vẫn nằm trong tay bên thứ ba, dữ liệu cũng vậy, nếu tài khoản bị chặn trên Bluesky hay máy chủ khác thì kho lưu trữ cũng đóng lại và bạn còn mất cả cơ hội chuyển dữ liệu đi nơi khác, cái này chẳng khác email là mấy, nếu không có domain và server riêng thì thực tế bạn chẳng kiểm soát được gì
- Trong AT, dữ liệu gắn với DID (Decentralized Identifier, định danh phi tập trung), không gắn với handle hay hosting, tôi đã giải thích kỹ điểm này trong bài viết, nếu bạn mất domain của "handle" thì đơn giản là handle đó mất hiệu lực và ứng dụng sẽ hiện "invalid handle" thay cho tên người dùng, còn dữ liệu như bài viết và follower vẫn còn nguyên vì có thể tra qua DID, handle chỉ như biệt danh thôi, bạn cũng có thể đổi handle bằng tính năng "đổi handle" trong app, hosting cũng tương tự, dù có vài trở ngại nhưng nếu có backup kho lưu trữ thì vẫn có thể chuyển đi nơi khác, cũng có thể tự động hóa backup, và đã có app bên thứ ba hỗ trợ backup tự động, app Bluesky chính thức cũng cho xuất kho lưu trữ, khi nhà cung cấp hosting hợp tác thì có trường hợp như PDSMover, còn nếu họ không hợp tác thì xem adversarial pds migration vẫn làm được, hiện tại cần chút kiến thức kỹ thuật nhưng hy vọng sau này quy trình này sẽ dễ hơn, khi tải kho lưu trữ lên host mới thì bạn sẽ lấy lại toàn bộ bài viết, follower v.v. với đúng danh tính cũ, điểm này rất khác email, hiện giờ còn hơi khó nhưng tôi kỳ vọng khi hệ sinh thái AT phát triển thì sẽ thuận tiện hơn nhiều
- Ngay cả khi có domain thì rồi cũng có thể đến lúc không còn giữ được nữa, khác với server, domain phụ thuộc vào registrar nên tôi thấy mong manh hơn, vì thế khi chọn registrar tôi đã chọn một đơn vị thuộc phạm vi pháp luật nước mình, để nếu có vấn đề thì còn hy vọng khôi phục được phần nào
- Đa số người dùng không có domain luôn phải đối mặt với rủi ro khi đơn vị hosting trở thành "kẻ thù" của họ, ví dụ chặn tài khoản đột ngột, muốn phòng thủ triệt để thì cuối cùng vẫn phải tự sở hữu domain trên TLD trung lập và tự định tuyến traffic bằng DNS, nhưng ngay cả trong thực tế này, nơi rất ít người chịu dùng domain riêng, dự án vẫn là một bước tiến vì nó bổ sung phần nào tính linh hoạt và bảo vệ so với cảnh dữ liệu bị nhốt vĩnh viễn trong Big Social như Facebook, X, Instagram, Bluesky dường như còn hấp dẫn vì trong môi trường như vậy bạn có thể giữ nguyên handle mà chỉ chuyển hosting dữ liệu, tôi nghĩ ngành này không thể đạt sự hoàn hảo ngay lập tức mà phải tiến bộ bằng cách cải thiện dần những vấn đề thực tế
- Theo tôi, cách tốt nhất để chứng minh danh tính là sở hữu private key, còn về hosting thì có lẽ BitTorrent là bền vững nhất, cũng có thể cân nhắc để nội dung trong một kho git, ký các commit rồi phát tán qua torrent, còn thông báo cập nhật thì tôi từng nghĩ đến NNTP hoặc RSS, vấn đề là khả năng khám phá nội dung và thiếu tương tác như bình luận
- Ít nhất với email thì bạn có thể mang khóa PGP/SMIME sang nơi khác, tôi tự hỏi ATproto có phải là ý tưởng tương tự không
Giải thích của Dan lúc nào cũng rất hay, và lần này cũng đúng lúc khi gần đây có tin Bluesky sẽ chuyển quyền vận hành PLC, nhóm của chúng tôi cũng đã chọn cùng hệ thống DID tại fair.pm để phân phối phi tập trung plugin WordPress, có thể xem như một kiểu quản lý gói giống App Store, phía Bluesky, đặc biệt là Bryan, đã hỗ trợ rất nhiều, và chúng tôi còn xin được cả hỗ trợ khóa Ed25519 để dùng được libsodium, giao thức của chúng tôi đang được thiết kế trên DID và cơ chế moderation có thể xếp chồng của Bluesky, nhưng không dùng trực tiếp atproto, điểm quan trọng là DID là tiêu chuẩn W3C nên PLC không bị ràng buộc vào atproto
- "Chúng tôi" là ai, và nếu đây là nỗ lực giải quyết drama WordPress bằng kỹ thuật thì tôi rất muốn nghe giải thích chi tiết hơn
- Bạn nói PLC không phụ thuộc atproto, nhưng PLC (did method) rốt cuộc chẳng phải vẫn bị trói vào bluesky hay một thẩm quyền trung tâm nào đó sao? Tôi thắc mắc vì sao đã tập trung như vậy mà vẫn gọi là DID, did:plc cũng không portable, tại sao không viết theo kiểu did:web rồi thêm cơ chế như PLC, tại sao method-specific-id lại không được thiết kế để có thể di trú như dựa trên hash public key, và vì sao không đi theo hướng phân tán như DHT, ví dụ did:pkarr? PLC trông như một hệ thống tập quyền nữa mà thôi
Để tìm at:// thì phải gửi yêu cầu GET đến plc.directory, ở chỗ này hệ thống có vẻ biến thành mô hình tập trung 100%, ít nhất tôi đã mong có thể tách nhiều trusted directory khỏi giao thức như DNS root hay CA
- Nếu muốn làm riêng lẻ thì cũng có thể dùng did:web:fqdn, bài viết cũng có nói đến điều này
Có vẻ mọi server lưu liên kết at:// cuối cùng cũng phải đi qua DNS/HTTPS để tìm biểu diễn chính thức của permalink, nếu DNSSEC không được triển khai đúng thì cấu trúc này có vẻ khá mong manh, tôi chưa nghĩ quá sâu nhưng nỗi lo xuất hiện ngay là các vấn đề như DNS poisoning có thể cho phép kẻ tấn công đăng bài dưới tên tôi, vì public key được chứa trong DID lấy từ DNS
- Lo DNS poisoning là điều dễ hiểu, nhưng thực tế không hẳn luôn như vậy, thông thường người ta đặt DID vào phần authority của at://, nên nếu truy vấn bằng DID thay vì handle thì cuối cùng chỉ phụ thuộc vào HTTPS và web PKI, ngay cả khi bắt đầu từ handle thì cũng đi qua web PKI và TXT record, cách được khuyến nghị là resolve handle ở phía server, còn nếu phải tự làm thì truy vấn qua nhà cung cấp DoH đáng tin cậy, không hoàn hảo nhưng giảm đáng kể bề mặt tấn công, DNSSEC dĩ nhiên là lời giải cho vấn đề đó, nhưng trong mạng vận hành thực tế tôi đã nhiều lần khổ vì DNSSEC, ví dụ các thượng nghị sĩ Mỹ dùng domain senate.gov để xác minh danh tính, nhưng gần đây cấu hình DNSSEC bị lỗi làm hàng chục thượng nghị sĩ hiện thành "invalid handle" trên Bluesky, vì những trải nghiệm thất vọng như vậy nên hiện giờ tôi không mạnh tay ép DNSSEC, nếu có giao thức lớn nào khác đã thành công khi bắt buộc DNSSEC thì cũng đáng để cân nhắc lại
- Để kẻ tấn công giả mạo bạn và đăng bài thì nhất định phải có private key, DNS record chỉ cho biết lấy DID document ở đâu, và DID document đó lại phải được xác minh ngược qua DNS, trong quy trình này có logic xác minh, DNSSEC giúp giảm rủi ro bị sửa DNS record, nhưng việc không có DNSSEC không có nghĩa là người lạ có thể mạo danh bạn để đăng bài, server cũng sẽ từ chối
- Phần này hơi khó, nhưng trong DNS TXT method cũng ghi rõ là "không cần DNSSEC", dù sao DNS chỉ phụ trách chuyển Handle -> DID, còn xác minh là một quy trình hai chiều đi DID -> Handle
Trong bài thiếu thông tin về khóa dùng cho lịch sử thay đổi DID, ví dụ nếu tôi là foobar.bsky.social thì tôi không nhớ đã từng tự tải khóa lên hay được hướng dẫn tải khóa xuống, tôi muốn biết chính xác khóa đó nằm ở đâu, ai sở hữu nó, và nó được dùng như thế nào, khi nào, thêm nữa, nếu DID nằm trên plc.directory thì cơ chế nào ngăn người vận hành site đó tự ý ghi đè DID của tôi để chiếm danh tính của tôi?
Khái niệm at:// khá thú vị, nhưng tôi cũng lo về các vấn đề có thể phát sinh trong một hệ thống dựa trên quyền sở hữu dữ liệu thực sự, ví dụ người dùng giữ dữ liệu của mình nên có thể tùy ý sửa hoặc xóa nội dung bất cứ lúc nào, lúc đầu họ viết bài đàng hoàng rồi sau đó ác ý sửa lại thì sao, ngay cả nếu lưu hash bài cũ để chống thay đổi thì dịch vụ mới cũng có thể không biết lịch sử đó, rồi việc theo dõi like hay upvote cũng khó, nếu ai cũng lưu mọi thứ thành object riêng thì rất khó biết ai đã upvote cái gì, và nếu cứ tạo tài khoản giả để tự đăng bài cho mình thì có vẻ cũng chẳng bị hạn chế, cuối cùng, nếu có số lượng khổng lồ tài khoản từ nhiều nền tảng khác nhau đổ vào thì liệu có thể moderation spam hay hành vi xấu được không, với giả định mỗi tài khoản tự quản dữ liệu của mình, tôi không chắc thiết kế hệ thống cho minh bạch, trách nhiệm, moderation, chống spam v.v. có thực sự đứng vững hay không
- Quản lý thay đổi, tức history, có thể công khai kèm theo, vì trong dữ liệu (json) bạn có thể chứa đủ thông tin mình muốn, nên hoàn toàn có thể mô tả bài cũ theo chuỗi at:// nối tiếp kiểu linked list, DID giải thích khá tốt về moderation ở cấp danh tính, tức là nó cung cấp đủ cơ sở để biết ai là ai, để chặn hay đánh giá họ, điểm mấu chốt là đây không phải blockchain mà là cách tiếp cận xoay quanh chủ sở hữu dữ liệu, có thể chia sẻ bất cứ lúc nào, miễn là không có ai cố tình phá hoại thì đây là một cấu trúc khá hấp dẫn, vì bạn biết rõ "dữ liệu nào của người này đang ở đâu", còn nếu bạn không quan tâm đến kiểu minh bạch này thì cũng không cần dùng
- Để ngăn việc sửa ác ý nội dung gốc, có strongRef, tức permalink thật dựa trên hash, Dan không nói kỹ trong bài nhưng nếu bạn lưu strongRef thì sẽ phát hiện ngay khi nội dung bài cũ bị thay đổi, Bluesky cũng không đưa tính năng edit vì lo chuyện sửa ác ý, tham khảo: tổng kết thử nghiệm permalink, thử nghiệm lịch sử record editing, việc theo dõi upvote có thể làm đại khái bằng cách crawl mạng rồi gom dữ liệu bằng roaring bitmap v.v. (ví dụ roaring-bitmaps), còn bài toán moderation thì có stackable moderation, khá ngầu hơn nhiều so với các hệ thống hiện có, cũng đang có bàn về việc làm labeler/feedgen theo kiểu DAG, tức hệ thống kết hợp quy tắc dựa trên phép toán tập hợp, chuyện giả mạo dữ liệu thì phát hiện thay đổi bằng hash CID riêng của từng mục, còn việc theo dõi history cũng làm được về mặt kỹ thuật
Tôi có cảm giác khá giống với rất nhiều giao thức crypto khác, đều nói về phi tập trung nhưng cuối cùng vẫn bị buộc vào một nền tảng
- Còn sớm, nhưng tangled.org (na ná GitHub), leaflet.pub (na ná Medium) cũng đã được dùng khá tích cực, và nhờ các công cụ tự động index mạng như slices.network, rào cản làm app mới đang tiếp tục giảm xuống nên có lẽ sẽ còn nhiều app hơn nữa, trong bài tôi cũng giải thích cách chúng vận hành, điều quan trọng là với người dùng "bình thường" thì công nghệ này không quan trọng lắm, phần lớn người dùng Bluesky thực ra không quan tâm hoặc thậm chí còn dị ứng với "phi tập trung", nhưng vì cấu trúc phi tập trung không lộ thẳng ra trên bề mặt sản phẩm, giống như web vậy, nên tôi nghĩ dạng chấp nhận này là khả thi, người dùng chỉ muốn thứ gì đó "hoạt động tốt" thôi
- Cũng thấy hơi giống lịch sử của Git và GitHub, khi tính năng tăng dần thì mọi thứ cũng dần phân tán và linh hoạt hơn
Có một câu hỏi mang tính cấu trúc là "làm sao tìm JSON bằng at:// URI", đọc tài liệu xong tôi vẫn không thấy tại sao lại cần đến "JSON đó", cá nhân tôi không hợp với cách làm này
- Xin lỗi vì phần giới thiệu hơi đột ngột, giao thức at:// cho phép các app tự do nhúng và xuất dữ liệu qua lại, chia sẻ danh tính người dùng, và cho phép tự host hoặc di chuyển nội dung, đồng thời cung cấp URI lâu dài không bị ràng buộc vào handle/server, nguyên lý kỹ thuật đã được giải thích xuyên suốt bài, ví dụ leaflet.pub và bsky.app đều tổng hợp dữ liệu từ cùng một mạng công khai nên có thể dễ dàng liên kết và hiển thị dữ liệu của nhau mà không cần API riêng (bài demo)
- Để dễ hình dung thì có thể ví nó với câu hỏi "làm sao tìm HTML bằng https:// URI?", hơi đơn giản hóa quá mức nhưng phù hợp để giải thích cho người mới học DNS, HTTP, TLS
Tôi tự hỏi liệu giao thức này có đóng vai trò như một public Kafka topic khổng lồ hay không, ví dụ khi làm webapp mới thì không cần tự lưu dữ liệu mà mọi người tự lưu dữ liệu trong không gian của họ, còn app chỉ cần có listener để nghe, giao thức bảo đảm việc lan truyền dữ liệu, rồi app nghe và cache lại, về mặt khái niệm thì rất lạ nhưng thú vị, tôi cũng tò mò liệu các khái niệm của Kafka như offset để không bỏ lỡ cập nhật, hay partition để scale, có áp dụng ở đây không
- Đúng vậy, firehose gần như làm đúng vai trò đó, bất kỳ ai cũng có thể subscribe hoặc tự chạy firehose, tham khảo giải thích ATProto cho kỹ sư hệ thống phân tán, firehose và jetstream có cursor nên dù kết nối muộn vẫn có thể nhận cập nhật đến dữ liệu mới nhất, thời gian lưu tùy instance, từ 1 đến 72 giờ, nếu cần toàn bộ lịch sử thì có thể xử lý bằng cách backfill

Vị trí của `at://` nằm ở đâu

AT Protocol, URI at://, và quá trình phân giải danh tính của dữ liệu xã hội

# Cấu trúc cơ bản của AT Protocol và URI at://

# Ba bước trong quy trình phân giải URI at://

# Giải thích quy trình phân giải qua ví dụ

# Sự khác nhau giữa hai kiểu DID: did:web và did:plc

# Tách biệt danh tính, lưu trữ và dữ liệu, cùng tính bền vững

# Ứng dụng thực tế và ghi chú cho lập trình viên

# Kết luận

Bài viết liên quan

1 bình luận

Ý kiến trên Hacker News

AT Protocol, URI `at://`, và quá trình phân giải danh tính của dữ liệu xã hội

# Cấu trúc cơ bản của AT Protocol và URI `at://`

# Ba bước trong quy trình phân giải URI `at://`

# Sự khác nhau giữa hai kiểu DID: `did:web` và `did:plc`