Meninggalkan fedify – hal-hal baik tentang fedify yang baru saya sadari setelah pergi

(Ini adalah tulisan dari blog yang saya kelola. Isi utamanya ditulis dengan bantuan AI assistant saya, Shiro, yang bekerja bersama saya. Jika ada salah baca atau kekeliruan, saya akan berterima kasih jika Anda memberi tahu saya)

Server fediverse kecil sukhi-fedi—jaringan SNS tempat server saling terhubung seperti Mastodon—mencatat proses melepas fedify (library yang berjalan sebagai worker Bun), yang sebelumnya menangani perakitan JSON-LD (pekerjaan membentuk pesan ke format yang bisa dipahami antarsesama server) dan tanda tangan HTTP (prosedur penandatanganan untuk memverifikasi bahwa pesan itu asli), lalu mengimplementasikan semuanya sendiri langsung dengan Elixir. Ini bukan tulisan untuk menjelek-jelekkan; separuh isinya justru tentang "hal-hal baik tentang fedify yang baru saya sadari setelah pergi."

• Sejak awal saya memang tidak memakai fitur framework fedify (createFederation, inbox listener, dispatcher, dll.—alat tingkat atas yang menangani seluruh fungsi federasi secara otomatis), dan hanya meminjam komponen paling bawahnya:

  • kelas vocab
  • toJsonLd/fromJsonLd (konverter yang saling mengubah format pesan)
  • signRequest/verifyRequest yang memahami dua metode penandatanganan: draft-cavage dan RFC 9421
  • tanda tangan LD, document loader
  • input/output kunci/JWK (format standar untuk menyimpan kunci publik)

• Ada tiga alasan untuk pergi:

  1. Begitu memutuskan untuk tidak memakai framework, hal-hal yang sebelumnya diberikan fedify secara cuma-cuma (balasan Accept untuk Follow, idempoten—mekanisme agar hasil hanya diterapkan sekali meski permintaan yang sama datang berkali-kali, authorized fetch, instance actor) pada akhirnya harus saya tangani sendiri semuanya. Yang tersisa hanya komponen dasar, jadi jumlah yang harus dipindahkan pun sudah jelas
  2. Targetnya adalah server kecil dengan memori 512~768MB, tetapi dalam uji daya tahan Elixir menyelesaikan run dengan stabil di 130MB, sementara worker Bun sendiri mengalami OOM (mati karena kehabisan memori) di 120MB. Satu-satunya bagian sistem yang berjalan dengan bahasa lain justru menjadi yang paling berat dan paling rapuh
  3. Batas antara bahasa dan proses itu sendiri menciptakan masalah. Menjaga data asli yang diperlukan untuk verifikasi tanda tangan, memulihkan alamat yang diubah oleh tunnel, membungkus kunci di DB menjadi JWK lalu memindahkannya ke proses lain—ini memang bukan kesalahan fedify, tetapi pekerjaan perpipaan yang terus bertambah

• Pekerjaan penggantian selesai dengan 12 file, sekitar 2.100 baris. Struktur message queue dibiarkan apa adanya, cukup dimasukkan ke grup yang sama, lalu peralihannya pada dasarnya hanya "mematikan container Bun"

• Yang menyusun jaring pengamannya justru fedify itu sendiri. Tanda tangan Ed25519 dan normalisasi URDNA2015 (aturan untuk selalu merapikan dokumen dalam urutan yang sama) menghasilkan output yang selalu sama untuk input yang sama, sehingga saya bisa lebih dulu mengekstrak "data jawaban benar" dengan kode fedify asli, lalu memverifikasi bahwa hasil yang dipindahkan ke Elixir cocok tanpa meleset satu karakter pun

• Worker Bun sudah pensiun, tetapi tidak dihapus. Sampai sekarang ia masih dipertahankan di lingkungan pengembangan untuk membuat data jawaban benar

• Tim fedify sedang membuat DrFed(https://drfed.org/), alat debugging ActivityPub. Rencananya akan mencakup fungsi diagnosis yang menunjukkan di tahap mana federasi rusak (DNS/TLS/HTTP/tanda tangan/JSON-LD), serta debugger yang memungkinkan kita menelusuri kedua metode penandatanganan langkah demi langkah (didukung NLnet NGI0, open source AGPL-3.0, saat ini masih dalam pengembangan)

• Kesimpulannya: jika Anda memakai seluruh framework-nya dalam TypeScript/JavaScript, fedify tetap merupakan pilihan terbaik. Fitur ActivityPub milik Ghost, hackers.pub, dan Hollo semuanya berjalan di atasnya