Rời khỏi fedify – những điểm hay của fedify mà tôi nhận ra sau khi rời đi

(Đây là bài viết trên blog tôi vận hành. Phần nội dung được viết với sự hỗ trợ của Shiro, trợ lý AI làm việc cùng tôi; nếu có chỗ nào tôi hiểu sai, rất mong được góp ý.)

Đây là bản ghi lại việc sukhi-fedi, một máy chủ fediverse nhỏ (mạng SNS nơi các máy chủ liên kết với nhau như Mastodon), đã gỡ bỏ fedify (thư viện chạy bằng Bun worker) — thành phần phụ trách lắp ráp JSON-LD (công việc tạo thông điệp theo định dạng để các máy chủ có thể hiểu nhau) và chữ ký HTTP (quy trình ký để xác minh thông điệp là thật) — rồi tự triển khai toàn bộ bằng Elixir. Đây không phải là bài nói xấu; một nửa bài viết là về “những điểm hay của fedify mà tôi nhận ra sau khi rời đi”.

• Ngay từ đầu, tôi đã không dùng các chức năng framework của fedify (createFederation, inbox listener, dispatcher, v.v. — các công cụ cấp cao tự xử lý toàn bộ chức năng liên hợp), mà chỉ mượn các bộ phận ở tầng thấp nhất:

  • các lớp vocab
  • toJsonLd/fromJsonLd (bộ chuyển đổi qua lại giữa các định dạng thông điệp)
  • signRequest/verifyRequest, hiểu cả hai phương thức ký là draft-cavage và RFC 9421
  • chữ ký LD, document loader
  • nhập/xuất khóa/JWK (định dạng tiêu chuẩn chứa khóa công khai)

• Có ba lý do rời đi:

  1. Ngay khi quyết định không dùng framework, những thứ fedify vốn cung cấp miễn phí (trả lời Accept cho Follow, tính idempotency — cơ chế để dù cùng một yêu cầu đến nhiều lần thì kết quả cũng chỉ được phản ánh một lần, authorized fetch, instance actor) đều đã phải tự xử lý. Những gì còn lại chỉ là các bộ phận cơ bản, nên khối lượng cần chuyển đổi đã được xác định
  2. Mục tiêu là một máy chủ nhỏ với bộ nhớ 512–768MB, nhưng trong bài kiểm tra độ bền, Elixir hoàn thành ổn định ở mức 130MB, còn riêng Bun worker thì OOM (chết vì thiếu bộ nhớ) ở 120MB. Phần duy nhất trong hệ thống chạy bằng ngôn ngữ khác lại là phần nặng nhất và yếu nhất
  3. Chính ranh giới giữa ngôn ngữ và tiến trình đã tạo ra vấn đề. Việc giữ nguyên dữ liệu gốc cần thiết để xác minh chữ ký, khôi phục địa chỉ bị tunnel thay đổi, gói khóa trong DB thành JWK rồi chuyển sang tiến trình khác, v.v. không phải lỗi của fedify, nhưng đó là các công việc “đường ống” cứ ngày càng tăng

• Việc thay thế kết thúc với 12 tệp, khoảng 2.100 dòng. Cấu trúc message queue được giữ nguyên; sau khi cho phần mới tham gia cùng group, thao tác chuyển đổi chỉ đơn giản là “dừng container Bun”

• Chính fedify là thứ đã dựng nên lưới an toàn. Chữ ký Ed25519 và chuẩn hóa URDNA2015 (quy tắc sắp xếp tài liệu luôn theo cùng một thứ tự) là các phương thức cho cùng kết quả với cùng đầu vào, nên có thể dùng mã fedify thật để trích xuất sẵn “dữ liệu đáp án”, rồi kiểm chứng kết quả chuyển sang Elixir không sai dù chỉ một ký tự

• Bun worker đã nghỉ hưu nhưng không bị xóa. Hiện nó vẫn còn trong môi trường phát triển với vai trò tạo dữ liệu đáp án

• Nhóm fedify đang xây dựng DrFed (https://drfed.org/), một công cụ gỡ lỗi ActivityPub. Dự kiến công cụ sẽ bao gồm chức năng chẩn đoán chỉ ra liên hợp bị hỏng ở bước nào (DNS/TLS/HTTP/chữ ký/JSON-LD), cùng trình gỡ lỗi cho phép lần theo từng bước hai phương thức ký, v.v. (được NLnet NGI0 hỗ trợ, mã nguồn mở AGPL-3.0, hiện đang phát triển)

• Kết luận là: nếu dùng trọn framework bằng TypeScript/JavaScript, fedify vẫn là lựa chọn tốt nhất. Tính năng ActivityPub của Ghost, hackers.pub và Hollo đều đang chạy trên nền tảng đó