ActivityPub untuk Situs Pribadi — Apa yang Distandardisasi Federation, dan Apa yang Tetap Menjadi Tanggung Jawabmu

Situs pribadi biasanya berbicara satu arah: penulis menerbitkan halaman, lalu pembaca mengunjunginya. RSS, WebSub, dan hyperlink biasa membuat hubungan itu lebih berguna, tetapi belum menjadikan situs sebagai peserta dalam social graph bersama. ActivityPub memulai dari pertanyaan yang berbeda: apa yang diperlukan agar satu server memahami bahwa server lain telah menerbitkan, mengikuti, menyukai, atau memperbarui sesuatu?

Jawabannya bukan “gunakan satu aplikasi media sosial universal”. ActivityPub adalah protokol dengan data model di sekelilingnya. Ia mendefinisikan pesan dan endpoint penting, sementara banyak keputusan yang terlihat oleh pengguna dan keputusan operasional tetap diserahkan kepada setiap implementasi. Perbedaan ini penting bagi siapa pun yang mempertimbangkan federation untuk situs pribadi. Kita dapat memahami arsitekturnya tanpa menganggap setiap situs harus berubah menjadi jejaring sosial lengkap.

Activity Streams Adalah Vocabulary-nya

ActivityPub dibangun di atas Activity Streams 2.0. Activity Streams menyediakan cara berbasis JSON untuk menjelaskan object dan activity. Sebuah object dapat berupa note, article, image, person, collection, atau tipe lain yang didefinisikan vocabulary. Activity menjelaskan tindakan seperti Create, Follow, Like, Update, atau Undo.

Hal ini lebih mudah dibayangkan sebagai kalimat daripada tabel database: sebuah actor membuat object, atau actor mengikuti actor lain. Representasi JSON memberikan field seperti actor, object, type, dan properti addressing. Activity Vocabulary mendefinisikan tipe dan properti umum, sedangkan spesifikasi core menjelaskan serialisasi JSON serta model collection.

Vocabulary ini dapat diperluas. Itu berguna karena aplikasi sosial tidak selalu memiliki object atau tindakan yang sama. Namun, ada batasnya: extension yang dipahami satu implementasi mungkin diabaikan implementasi lain. Implementasi dapat menerima bentuk sebuah object tanpa memberikan perilaku yang sama untuk setiap extension. Interoperability lebih terbantu jika kita memakai tipe umum ketika memang sesuai, bukan menciptakan nama baru untuk konsep yang sudah ada.

ActivityPub Memiliki Dua API yang Saling Berkaitan

ActivityPub Recommendation menjelaskan dua lapisan protokol:

• Client to server: client bertindak atas nama actor, misalnya mengirim activity ke outbox actor tersebut.
• Server to server: server mengirimkan activity kepada actor di server lain. Inilah bagian federation.

Sebuah server dapat mengimplementasikan salah satu profile tanpa harus mengimplementasikan keduanya. Ini mengoreksi anggapan bahwa “ActivityPub” adalah satu fitur monolitik. Situs pribadi dapat memulai dengan menerbitkan actor dan outbox yang dapat dibaca mesin, sedangkan layanan yang lebih besar juga dapat menyediakan client, authentication, moderation tool, dan remote delivery.

Actor, Inbox, dan Outbox

Dalam ActivityPub, person, organization, application, atau service dapat direpresentasikan sebagai actor. Actor memiliki identifier berupa URI dan menyediakan inbox serta outbox. Inbox adalah tempat activity yang ditujukan kepada actor diterima. Outbox berisi activity yang dibuat actor, sesuai aturan akses server.

Di sana juga dapat ada collection seperti followers dan following. Ini adalah protocol object, bukan halaman yang wajib dilihat manusia. User interface dapat menampilkannya sebagai daftar, menyembunyikannya, melakukan pagination, atau memakai desain yang sama sekali berbeda. ActivityPub hanya memerlukan data dan endpoint tersebut memiliki makna yang diharapkan.

Untuk public post sederhana, alurnya kira-kira seperti ini:

1. Client mengirim object atau activity baru ke outbox actor.
2. Server membuat atau mencatat object dan menentukan penerima dari field addressing seperti to dan cc.
3. Server asal menemukan actor penerima dan inbox remote-nya.
4. Server asal mengirimkan activity ke inbox tersebut.
5. Server penerima memvalidasi dan memproses activity sesuai aturannya sendiri.

Ini adalah model delivery, bukan jaminan bahwa server remote akan menampilkan content di timeline tertentu. Implementasi penerima tetap menentukan cara menyimpan, memoderasi, mengurutkan, menyembunyikan, atau menampilkan apa yang diterimanya.

Discovery Adalah Masalah yang Berbeda

Server tidak dapat mengirimkan sesuatu kepada actor yang tidak dapat ditemukannya. ActivityPub memberikan identifier dan endpoint yang stabil, tetapi account discovery sering melibatkan WebFinger. RFC 7033 mendefinisikan protokol untuk menemukan informasi tentang entity yang diidentifikasi oleh URI. Client mengirim request HTTPS ke /.well-known/webfinger dengan query target dan menerima JSON Resource Descriptor.

Secara praktis, WebFinger dapat membantu memetakan identifier yang mudah dibaca manusia ke URL profile atau actor. Batasnya perlu jelas: WebFinger adalah protokol discovery, bukan pengganti ActivityPub untuk activity delivery. WebFinger juga memiliki persyaratan privasinya sendiri. Informasi yang dibuka melalui discovery menjadi lebih mudah ditemukan, sehingga server tidak seharusnya menerbitkan data pribadi hanya karena data itu dapat dimasukkan ke dalam response.

Setelah discovery, client atau server ActivityPub mengambil actor atau object menggunakan HTTP content negotiation. Recommendation menjelaskan representasi Activity Streams seperti application/activity+json dan media type JSON-LD Activity Streams. Halaman HTML untuk browser dan representasi Activity Streams untuk mesin dapat merujuk resource yang sama, tetapi keduanya bukan dokumen yang sama.

Apa yang Tidak Distandardisasi ActivityPub

Protokol sering paling berguna ketika kita memperhatikan hal yang sengaja dibiarkannya terbuka. ActivityPub tidak menentukan satu algoritma timeline. Ia tidak menetapkan apakah server harus menampilkan post secara kronologis, memakai rekomendasi, menyediakan list, atau tidak menyediakan timeline sama sekali.

ActivityPub juga tidak memberikan account model yang sama kepada semua implementasi. Actor dapat mewakili person, bot, organization, atau service. Hubungan antara pengguna manusia dan actor diserahkan kepada implementasi. Satu orang dapat mengendalikan beberapa actor, dan actor dapat berjalan otomatis.

Moderation tidak selesai hanya karena sebuah inbox tersedia. Server penerima tetap memerlukan kebijakan dan kontrol untuk spam, follow yang tidak diinginkan, impersonation, content berbahaya, pemblokiran remote, dan banding. Security considerations dalam spesifikasi ActivityPub membahas validation, spoofing, recursive object, spam, federation denial of service, dan content sanitization, tetapi peringatan itu bukan produk moderation yang lengkap.

Authentication juga perlu ditangani dengan hati-hati. Protokol core menjelaskan authorization dan menunjuk mekanisme seperti signature, tetapi deployment tetap harus memilih dan mengimplementasikan profile yang sesuai. Repository ActivityPub resmi W3C mencantumkan profile WebFinger dan HTTP Signature sebagai dokumen tambahan. Server tidak boleh menganggap dokumen JSON yang bentuknya valid sebagai bukti bahwa actor yang diklaim benar-benar mengirimkannya.

Mengapa Ini Penting bagi Situs Pribadi

Bagi situs pribadi, ActivityPub bukan otomatis fitur berikutnya setelah RSS. Ia memperkenalkan permukaan baru: identifier stabil, representasi publik, request remote, perilaku retry dan deduplication, access control, moderation, storage, serta security review.

Desain yang berhati-hati dapat memisahkan keputusan menjadi beberapa tahap. Pertama, tentukan apa yang memang harus publik dan URL mana yang stabil. Berikutnya, definisikan representasi Activity Streams kecil untuk artikel atau penulis. Setelah itu, pertimbangkan discovery dan read-only federation sebelum menerima remote write. Hanya setelah threat model dan biaya operasional dipahami, situs dapat mempertimbangkan follow, reply, like, atau activity remote yang sewenang-wenang.

Urutan ini bukan persyaratan spesifikasi. Ini adalah pertimbangan engineering. Protokol membuat federation mungkin, tetapi tidak membuat graph tersebut mudah dioperasikan. Situs kecil mungkin memperoleh lebih banyak manfaat dari canonical URL yang jelas, RSS, WebSub, dan halaman HTML yang accessible daripada dari menerima setiap activity yang dapat dikirim server lain.

Kesimpulan

ActivityPub paling tepat dipahami sebagai sekumpulan kesepakatan antarserver. Activity Streams menyediakan vocabulary; ActivityPub mendefinisikan interaksi client-server dan server-server; WebFinger dapat membantu discovery. Actor, inbox, outbox, collection, addressing, dan representasi HTTP menyediakan komponen untuk membangun federation.

Namun, federation tidak sama dengan pengalaman sosial yang sudah selesai. Protokol tidak memilih timeline, kebijakan moderation, storage engine, desain account, atau model security deployment untuk kita. Itu sekaligus kekuatan dan biayanya. Situs pribadi dapat melihat ActivityPub sebagai peluang untuk menerbitkan tulisan di luar satu platform, sambil tetap mengajukan pertanyaan yang kurang populer: bagian mana dari hubungan itu yang benar-benar perlu menjadi tanggung jawab situs?

References

1. ActivityPub, W3C Recommendation, Christine Lemmer-Webber et al., 23 January 2018.
2. Activity Streams 2.0, W3C Recommendation, James M. Snell and Evan Prodromou, 23 May 2017.
3. Activity Vocabulary, W3C Recommendation, James M. Snell and Evan Prodromou, 23 May 2017.
4. RFC 7033: WebFinger, Peter Saint-Andre et al., IETF, September 2013.
5. W3C ActivityPub repository, official project documentation.