Di Mana Posisi `at://`

• AT Protocol adalah protokol yang menjadi fondasi jejaring sosial terdesentralisasi, dan semua data diidentifikasi dengan at:// URI
• at:// URI menetapkan pembuat data (pengguna) sebagai authority, sedangkan lokasi hosting sebenarnya untuk data tersebut harus dicari secara terpisah
• Prosedur resolusi URI terdiri dari urutan mengubah handle menjadi identitas (DID), memeriksa server hosting melalui DID Document, lalu meminta data JSON dari server tersebut
• Dua jenis metode DID (did:web, did:plc) didukung, dan masing-masing memiliki kelebihan, kekurangan, serta cara preservasi data yang berbeda
• Pendekatan ini menekankan bahwa kepemilikan data ada pada pengguna, serta menjamin persistensi koneksi sehingga hubungan tetap terjaga meskipun handle dan hosting berubah

---

AT Protocol, at:// URI, dan proses resolusi identitas data sosial

# Struktur dasar AT Protocol dan at:// URI

• AT Protocol memungkinkan banyak server terdistribusi berkomunikasi menurut standar tertentu, dan keseluruhan ekosistem ini disebut 'atmosphere'
• Setiap data di dalam atmosphere diberi URI unik yang diawali dengan at://, dan URI ini berfungsi seperti tautan ke data JSON
• Berbeda dari struktur URI tradisional, dalam AT Protocol pembuat data (pengguna) ditetapkan sebagai authority URI
  • Misalnya, dalam bentuk at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z, ruuuuu.de menyatakan pemilik data tersebut
• Server fisik tempat data sebenarnya di-host tidak langsung tercantum di dalam URI, sehingga diperlukan proses resolusi tambahan untuk menemukannya

# Tiga tahap prosedur resolusi at:// URI

• Untuk memetakan at:// URI ke data sebenarnya (JSON), dibutuhkan tiga tahap
  1. Mengubah handle (ruuuuu.de dan sejenisnya) menjadi identitas (DID: Decentralized Identifier)
     • Handle adalah alias untuk identifikasi pengguna dan bisa berubah
     • Karena itu, perlu diubah menjadi DID, yaitu ID global yang tidak berubah
     • Cara konversi:
       • Kueri DNS TXT record _atproto.<handle> → periksa nilai did=...
       • Atau akses https://<handle>/.well-known/atproto-did
  2. Memeriksa informasi hosting data melalui DID Document
     • DID Document berisi informasi seperti kunci publik identitas terkait, service endpoint (server), dan lainnya
     • Untuk did:web:~, digunakan pendekatan berbasis domain (https://domain/.well-known/did.json)
     • Untuk did:plc:~, pencarian dilakukan di PLC directory (https://plc.directory/DID)
     • Service endpoint (serviceEndpoint) adalah server hosting data yang sebenarnya
  3. Meminta data JSON melalui API server hosting
     • Minta data dengan mengirimkan setiap bagian at:// sebagai parameter ke endpoint com.atproto.repo.getRecord
     • JSON yang dikembalikan adalah data nyata yang dipetakan ke at:// URI tersebut

# Penjelasan proses resolusi lewat contoh

• Contoh: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • Tahap 1: ruuuuu.de → did:web:iam.ruuuuu.de (dikonfirmasi melalui DNS TXT record atau .well-known)
  • Tahap 2: Periksa DID Document di https://iam.ruuuuu.de/.well-known/did.json → serviceEndpoint adalah https://blacksky.app
  • Tahap 3: Minta https://blacksky.app/xrpc/com.atproto.repo.getRecord?... → JSON sebenarnya dikembalikan

    {
      "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",
        ...
      }
    }
    

• Meskipun handle berubah, jika menggunakan at:// URI berbasis DID (permalink), hubungan antara akun dan data tetap terjaga

# Perbedaan metode DID: did:web dan did:plc

• did:web:
  • Bisa mengelola dan memverifikasi domain sendiri
  • Jika kehilangan kendali atas domain, ada kemungkinan kehilangan seluruh ID
• did:plc:
  • PLC (Public Ledger of Credentials) menjadi pihak yang mengoperasikan ID
  • Tidak terikat pada domain, tetapi ada kemungkinan kontrol terbatas, misalnya jika operator PLC menolak pembaruan
  • Seluruh riwayat perubahan dapat diverifikasi dan dilacak melalui hash

# Pemisahan identitas, hosting, dan data serta persistensinya

• at:// memisahkan identitas dan hosting data, sehingga memungkinkan portabilitas data pengguna dan pembuatan tautan permanen
• Handle (nama alias) bisa diubah kapan saja, dan server hosting pun bisa dipindahkan dengan cara yang sama
• DID (identitas) tidak berubah, sehingga at:// URI berbasis DID dapat digunakan sebagai permalink yang persisten
• DID Document memuat bukti kepemilikan handle, kunci verifikasi tanda tangan, serta informasi hosting, sehingga menjamin kepercayaan dan fleksibilitas

# Aplikasi nyata dan catatan pengembangan

• Dalam praktiknya, sebagian besar aplikasi berbasis AT menerima push data melalui WebSocket dan sejenisnya lalu mengagregasikannya ke DB internal
• Meski begitu, memahami cara resolusi at:// URI tetap penting untuk memahami karakteristik jaringan dan memastikan portabilitas data
• Skema at:// menyediakan abstraksi jejaring sosial di atas HTTP, DNS, dan JSON, serta mewujudkan secara teknis bahwa kepemilikan data berada di tangan pengguna

# Kesimpulan

• AT Protocol dan at:// URI membawa evolusi teknis pada identitas, keterhubungan, dan persistensi data sosial
• Pengembang perlu memahami workflow inti seperti resolusi handle, pemanfaatan DID, struktur DID Document, dan cara meminta data nyata
• Berkat struktur ini, pengguna dapat memperoleh fleksibilitas dan kepemilikan atas konten, identitas, serta lokasi hosting mereka

[GN⁺]

Komentar Hacker News

• Baru-baru ini saya terinspirasi oleh tulisan tentang ATProto lalu mencoba mendaftar ke bsky, tetapi yang saya lihat cuma cerita politik Amerika tanpa habisnya. Walau saya terus menekan "lihat lebih sedikit seperti ini", efeknya hampir tidak ada. Saya jadi penasaran apakah memang itu hakikat platform ini. Harus terus melihat opini klise tentang debat aneh dari luar negeri rasanya tidak bagus untuk mental.

  • Untuk akun baru, feed "Discover" memang tidak terlalu bagus. Setelah data like dan follow mulai terkumpul, feed itu perlahan membaik, tetapi tetap belum bisa dibilang yang terbaik. Secara pribadi saya merekomendasikan feed "For You". Feed ini cepat merefleksikan like dan lebih sedikit mendorong konten acak. Feed "Dev Trending" juga cukup bagus For You Feed, Dev Trending
  • Cara yang saya pakai adalah mencari beberapa akun yang lumayan, lalu mengikutinya dan menyembunyikan tab "Discovery" sama sekali. Setelah itu saya melihat interaksi dari orang-orang di daftar followers/following, lalu secara alami menambah daftar akun yang saya ikuti. Kadang saya juga mencari akun dari blog atau situs web lalu mengikutinya. Menurut saya, inilah cara kerja media sosial yang sebenarnya, dan dipaksa menerima konten rekomendasi otomatis itu tidak enak.
  • Untungnya bsky punya feed nonalgoritmik yang hanya menampilkan postingan dari orang-orang yang Anda ikuti. Menurut saya, model seperti ini adalah satu-satunya cara menjaga kesehatan mental.
  • Saya sudah memakai bsky lebih dari setahun, tetapi sebagian besar kontennya tetap politik Amerika. Sebagai orang Eropa, itu cuma terasa seperti noise. Jadi saya kembali ke Mastodon. Untuk mengikuti orang-orang di dunia teknologi, Mastodon jauh lebih baik. Untuk berita, saya ambil semuanya lewat RSS di feedly. Sekarang saya bahkan tidak tahu lagi untuk apa Bluesky dibutuhkan. Rasanya cuma seperti versi kiri dari Twitter. Teknologinya menarik sebagai bentuk evolusi dari Nostr, tetapi hanya itu.
  • Saya sarankan masuk ke Settings > Contents and Media > Your Interests > News and Politics lalu matikan opsi itu. Kalau Anda ingin melihat berita dan konten politik dari negara selain Amerika, saya sendiri tidak tahu ada cara khusus untuk itu.

• Saya masih belum yakin proyek ini benar-benar menyelesaikan masalah identitas dan kepemilikan data secara bermakna. Dari sisi identitas, pilihannya pada dasarnya cuma punya domain sendiri atau memakai domain milik orang lain seperti Bluesky. Kebanyakan orang tidak punya domain, jadi pada akhirnya identitas mereka tetap dimiliki pihak ketiga. Data juga begitu. Kalau akun diblokir di Bluesky atau server lain, penyimpanannya ikut ditutup, dan Anda bahkan kehilangan kesempatan memindahkan data ke tempat lain. Ini sama saja seperti email. Kalau tidak punya domain dan server sendiri, secara praktis Anda tidak mengendalikan apa pun.

  • Di AT, data melekat pada DID (Decentralized Identifier, pengenal terdesentralisasi), bukan pada handle atau hosting. Di tulisan saya, poin ini saya jelaskan lebih rinci. Kalau Anda kehilangan domain "handle", yang terjadi cuma handle itu menjadi tidak valid dan di aplikasi nama pengguna Anda tampil sebagai "invalid handle". Postingan, followers, dan data lain tetap ada karena bisa diambil lewat DID. Handle itu hanya semacam nama panggilan. Mengganti handle juga bisa dilakukan lewat fitur "change handle" di aplikasi. Hosting juga sama: walau ada hambatan, selama Anda punya backup repositori, Anda bisa memindahkannya ke tempat lain. Backup itu juga bisa diotomatisasi, dan sudah ada aplikasi pihak ketiga yang melakukan backup otomatis. Aplikasi resmi Bluesky juga bisa mengekspor repositori. Saat penyedia hosting kooperatif, ada kasus seperti PDSMover. Kalaupun tidak kooperatif, adversarial pds migration menunjukkan bahwa itu tetap mungkin. Saat ini memang butuh pengetahuan teknis, tetapi saya berharap suatu hari proses ini jadi lebih mudah. Setelah repositori diunggah ke host baru, semua postingan, followers, dan lain-lain kembali dengan identitas yang sama tanpa perbedaan dari sebelumnya. Ini sangat berbeda dari email. Sekarang memang masih agak sulit, tetapi saya berharap seiring ekosistem AT berkembang, semuanya akan jauh lebih mudah.
  • Bahkan kalau punya domain sendiri, bisa saja suatu hari Anda kehilangannya. Tidak seperti server, domain bergantung pada registrar, jadi terasa lebih rentan. Karena itu saya memilih registrar yang berada di bawah hukum negara saya sendiri. Dengan begitu, kalau ada masalah, saya merasa masih ada sedikit harapan untuk memulihkannya.
  • Mayoritas pengguna yang tidak punya domain selalu terekspos pada risiko ketika penyedia hosting berubah menjadi "musuh", misalnya pemblokiran akun mendadak. Perlindungan penuh pada akhirnya hanya mungkin jika Anda memiliki domain sendiri di TLD yang netral dan mengarahkan trafik lewat DNS. Meski begitu, dalam realitas saat ini—di mana hampir tak ada orang yang akan memakai domain sendiri—proyek ini tetap merupakan kemajuan karena menambahkan fleksibilitas dan perlindungan parsial dibanding Big Social yang ada sekarang (Facebook, X, Instagram, dll.), tempat data Anda terkunci selamanya. Dalam lingkungan seperti ini, Bluesky tampaknya menarik karena memungkinkan memindahkan hosting data sambil mempertahankan handle yang sama. Menurut saya, industri tidak bisa mencapai kesempurnaan sekaligus; kemajuan terjadi dengan memperbaiki masalah nyata sedikit demi sedikit.
  • Menurut saya, bukti identitas terbaik adalah kepemilikan private key. Untuk hosting, mungkin BitTorrent yang paling tangguh. Bisa juga dibayangkan model yang menaruh konten di repositori git, menandatangani commit, lalu mendistribusikannya lewat torrent. Untuk notifikasi update, saya pernah memikirkan NNTP atau RSS. Masalahnya adalah discoverability dan tidak adanya interaksi seperti komentar.
  • Setidaknya email memungkinkan Anda membawa kunci PGP/SMIME ke tempat lain. Saya penasaran apakah ATproto pada dasarnya punya konsep yang mirip.

• Penjelasan Dan selalu luar biasa, dan kali ini juga terasa sangat tepat waktunya mengingat kabar terbaru bahwa Bluesky akan memindahkan kendali operasional PLC. Tim kami di fair.pm juga memilih sistem DID yang sama untuk distribusi terdesentralisasi plugin WordPress, semacam package management seperti App Store. Orang-orang dari Bluesky, terutama Bryan, banyak membantu kami, dan kami bahkan berhasil mendapatkan dukungan kunci Ed25519 agar bisa memakai libsodium. Protokol kami sedang dirancang di atas DID dan stackable moderation milik Bluesky, tetapi kami tidak memakai atproto secara langsung. Yang penting adalah DID merupakan standar W3C, jadi PLC tidak terikat pada atproto.

  • Saya penasaran "kami" itu siapa, dan kalau ini upaya menyelesaikan drama WordPress secara teknis, saya ingin mendengar penjelasan yang lebih detail.
  • Anda bilang PLC tidak bergantung pada atproto, tetapi bukankah PLC (did method) pada akhirnya tetap terikat ke bluesky atau otoritas terpusat tertentu? Kalau terpusat seperti ini, saya jadi bertanya kenapa masih disebut DID. did:plc juga tidak portabel. Kenapa tidak ditulis seperti did:web lalu diberi perilaku ala PLC, kenapa method-specific-id tidak dibuat portabel misalnya berbasis hash public key, dan kenapa tidak memakai pendekatan terdesentralisasi seperti DHT, misalnya did:pkarr? PLC pada akhirnya terlihat seperti sistem terpusat lain.

• Untuk menemukan at://, kita harus mengirim permintaan GET ke plc.directory, dan di titik ini sistemnya terasa berubah menjadi model yang 100% tersentralisasi. Setidaknya saya berharap bisa ada beberapa direktori tepercaya yang dipisahkan dari protokol, seperti DNS root atau CA.

  • Kalau ingin melakukannya secara individual, Anda juga bisa memakai did:web:fqdn. Itu juga dijelaskan di tulisan.

• Semua server yang menyimpan tautan at:// pada akhirnya tampaknya harus melewati DNS/HTTPS untuk menemukan representasi resmi permalink-nya. Kalau DNSSEC tidak berjalan semestinya, struktur ini terasa agak rapuh. Saya belum memikirkannya terlalu dalam, tetapi kekhawatiran yang langsung muncul adalah masalah seperti DNS poisoning yang memungkinkan penyerang memposting atas nama saya, karena public key ada di DID yang diambil dari DNS.

  • Kekhawatiran soal DNS poisoning memang masuk akal, tetapi praktiknya tidak selalu demikian. Umumnya orang memasukkan DID ke posisi authority pada at://, jadi kalau Anda meminta berdasarkan DID alih-alih handle, pada akhirnya Anda bergantung pada HTTPS dan web PKI. Bahkan jika mulai dari handle, Anda tetap melewati web PKI dan TXT record. Cara yang direkomendasikan adalah membiarkan server menyelesaikan handle, dan jika harus melakukannya sendiri, kuerilah penyedia DoH (DNS over HTTPS) yang tepercaya. Ini memang tidak sempurna, tetapi sangat mengurangi permukaan serangan. DNSSEC tentu merupakan solusi untuk masalah itu, tetapi saya sudah berkali-kali mengalami kesulitan dengan DNSSEC di jaringan operasional nyata. Misalnya, para senator AS memakai domain senate.gov untuk verifikasi identitas, dan belum lama ini konfigurasi DNSSEC mereka rusak sehingga puluhan senator tampil sebagai "invalid handle" di Bluesky. Karena pengalaman mengecewakan seperti itu, saya saat ini tidak terlalu mendorong kewajiban DNSSEC. Kalau ada protokol besar lain yang berhasil menerapkannya dengan baik, mungkin layak dipertimbangkan lagi.
  • Agar penyerang bisa menyamar sebagai Anda dan memposting, mereka tetap harus memiliki private key Anda. DNS record hanya memberi tahu dari mana DID document harus diambil, dan DID document itu sendiri harus diverifikasi lagi terhadap DNS. Ada logika verifikasi dalam proses itu. DNSSEC mengurangi risiko manipulasi DNS record, tetapi tanpa DNSSEC pun tidak mungkin orang sembarang menyamar sebagai Anda lalu memposting atas nama Anda. Server juga akan menolaknya.
  • Bagian ini memang agak rumit, tetapi di DNS TXT method juga tertulis "DNSSEC not required". Intinya, DNS hanya menangani konversi Handle->DID, sedangkan verifikasi adalah proses dua arah DID->Handle.

• Dalam tulisan itu tidak banyak informasi tentang kunci yang dipakai untuk riwayat perubahan DID. Misalnya, kalau saya adalah foobar.bsky.social, saya tidak ingat pernah mengunggah kunci sendiri atau mendapat petunjuk untuk mengunduhnya. Saya jadi penasaran kunci itu sebenarnya ada di mana, siapa yang memilikinya, dan kapan dipakai. Selain itu, kalau DID saya ada di plc.directory, mekanisme apa yang mencegah operator situs itu menimpa DID saya secara sewenang-wenang lalu mencuri identitas saya?

• Konsep at:// ini menarik, tetapi saya juga khawatir tentang isu-isu yang bisa muncul dalam sistem yang benar-benar berbasis kepemilikan data. Misalnya, karena pengguna memegang datanya sendiri, mereka bisa mengubah atau menghapus isi kapan saja. Seseorang bisa menulis postingan yang awalnya baik lalu belakangan mengubahnya secara jahat. Walaupun kita menyimpan hash tulisan lama untuk mencegah perubahan, layanan baru tidak akan tahu riwayat itu. Melacak like/upvote juga terasa sulit, dan kalau semua orang menyimpannya sebagai objek mereka sendiri, mencari siapa yang memberi upvote akan susah. Orang juga bisa membuat akun palsu tanpa batas lalu terus mengangkat postingannya sendiri. Terakhir, bila ada jumlah akun yang sangat besar dari berbagai platform, apakah moderasi terhadap spam atau aktivitas jahat tidak akan menjadi mustahil? Dengan asumsi tiap akun mengelola datanya sendiri, saya belum yakin desain sistem untuk transparansi, akuntabilitas, moderasi, pemblokiran spam, dan semua unsur lain benar-benar bisa berdiri.

  • Manajemen perubahan (history) bisa dipublikasikan bersama. Karena data (json) bisa memuat informasi sebanyak yang Anda mau, alamat postingan lama tetap bisa dijelaskan sebagai rangkaian tertaut dengan at://. DID juga memberi penjelasan yang baik untuk identity moderation, yaitu menyediakan cukup dasar untuk mengetahui siapa seseorang dan menentukan apakah mereka perlu diblokir atau dinilai dengan cara tertentu. Intinya, ini bukan blockchain, melainkan model yang berpusat pada pemilik data dan dapat dibagikan kapan saja. Selama tidak ada pihak yang berniat merusaknya secara jahat, strukturnya cukup menarik. Karena kita bisa mengetahui dengan jelas "data orang ini ada di mana", kalau Anda memang tidak peduli pada transparansi seperti itu, ya tidak perlu memakainya.
  • Untuk mencegah pengubahan jahat pada konten asli, ada permalink nyata berbasis hash bernama strongRef. Dan memang tidak dibahas secara mendetail oleh Dan di tulisan itu, tetapi jika Anda menyimpan strongRef, Anda bisa segera mendeteksi perubahan isi postingan lama. Salah satu alasan Bluesky belum menambahkan fitur edit juga karena risiko pengubahan jahat itu. (Lihat juga ringkasan eksperimen permalink, eksperimen history pengeditan record) Untuk pelacakan upvote, Anda kira-kira bisa mengumpulkan data dengan merayapi jaringan lalu memakai roaring bitmap atau sejenisnya (contoh roaring-bitmaps). Untuk moderasi ada stackable moderation, yang menurut saya jauh lebih keren daripada sistem lama. Ada juga diskusi untuk membangun labeler/feedgen sebagai DAG, yaitu sistem penggabungan aturan berbasis operasi himpunan. Masalah pemalsuan data bisa dideteksi lewat hash CID masing-masing, dan pelacakan riwayat perubahan juga secara teknis memungkinkan.

• Ini terasa mirip dengan banyak protokol kripto yang berbicara soal desentralisasi tetapi pada akhirnya tetap terikat ke satu platform.

  • Memang masih tahap awal, tetapi tangled.org (mirip GitHub), leaflet.pub (mirip Medium), dan lain-lain sudah aktif dipakai. Hambatan untuk membuat aplikasi baru juga terus menurun berkat alat yang mengotomatisasi pengindeksan jaringan (slices.network), jadi saya rasa akan ada lebih banyak aplikasi lagi. Saya sudah menjelaskan cara kerjanya di tulisan itu. Yang penting adalah bagi pengguna "biasa", teknologi seperti ini tidak terlalu penting. Mayoritas pengguna Bluesky pada dasarnya tidak peduli soal "desentralisasi", bahkan sebagian ada yang alergi terhadapnya. Tetapi karena struktur terdesentralisasinya tidak langsung terlihat di permukaan produk—seperti saat kita menjelajah web—maka adopsi model seperti ini tetap mungkin terjadi. Pengguna hanya ingin sesuatu yang "berfungsi dengan baik".
  • Rasanya juga mirip dengan sejarah Git dan GitHub, yang sedikit demi sedikit menjadi lebih terdistribusi dan fleksibel seiring bertambahnya fitur.

• Ada pertanyaan yang lebih struktural: "bagaimana cara menemukan JSON lewat URI at://?" Meski membaca dokumentasinya, saya tetap tidak merasa paham kenapa 'JSON itu' diperlukan. Secara pribadi pendekatan seperti ini tidak cocok untuk saya.

  • Maaf kalau pengantarnya terasa mendadak. Protokol at:// memungkinkan data di-embed dan diekspor bebas antar aplikasi, berbagi identitas pengguna, serta mendukung self-hosting atau pemindahan konten, sambil menyediakan URI permanen yang tidak terikat ke handle/server. Prinsip teknisnya dijelaskan sepanjang tulisan itu. Sebagai contoh nyata, karena leaflet.pub dan bsky.app sama-sama mengambil data dari jaringan publik yang sama, keduanya bisa dengan mudah menampilkan dan mengintegrasikan data satu sama lain tanpa API terpisah (demo post).
  • Untuk membantu memahaminya, ini bisa dianalogikan dengan pertanyaan "bagaimana cara menemukan HTML lewat URI https://?"; Memang terlalu disederhanakan, tetapi cukup cocok untuk menjelaskan kepada orang yang baru belajar DNS, HTTP, dan TLS.

• Saya penasaran apakah protokol ini pada dasarnya berfungsi seperti topik Kafka publik raksasa. Misalnya, saat membuat aplikasi web baru, Anda tidak menyimpan data sendiri, melainkan semua pengguna menyimpan data di ruang mereka masing-masing, lalu Anda punya listener yang mendengarkannya, protokol menjamin propagasi data, dan aplikasi tinggal mendengar lalu meng-cache. Secara konsep ini menarik, tetapi saya juga penasaran apakah konsep Kafka seperti offset agar update tidak terlewat atau partition untuk skala juga berlaku di sini.

  • Ya, firehose pada dasarnya hampir berperan seperti itu. Siapa pun bisa berlangganan atau menjalankan firehose sendiri. Lihat penjelasan ATProto untuk engineer sistem terdistribusi. Firehose dan jetstream punya cursor, jadi walau Anda terlambat tersambung, Anda masih bisa menerima update hingga data terbaru. Masa cakupannya tergantung instance, berkisar antara 1–72 jam. Kalau butuh seluruh riwayat, itu bisa ditangani dengan pendekatan backfill.