Sosial Terbuka

• Open source telah menjadi standar infrastruktur perangkat lunak, dan kini paradigma 'sosial terbuka' juga muncul di aplikasi sosial
• AT Protocol memungkinkan pengguna memiliki dan mengendalikan data sosial mereka secara langsung, menghadirkan konsep yang berbeda dari platform sosial yang ada
• Data sosial tidak lagi dikurung di dalam layanan tertentu, melainkan disimpan di penyimpanan pribadi yang dikelola langsung oleh pengguna
• Dengan ini, penggunaan ulang dan remix data antar aplikasi menjadi mungkin, dan data tetap bertahan meski sebuah layanan ditutup
• Dengan meluasnya sosial terbuka, kepemilikan data yang dipimpin pengguna dan skalabilitas yang fleksibel diperkirakan akan muncul sebagai nilai utama

---

Pendahuluan: keberhasilan open source dan arus baru

• Open source kini menjadi fondasi infrastruktur bersama, meskipun dulu menghadapi banyak penolakan
• Berbeda dengan masa lalu, kini memilih open source bukan lagi masalah, dan di bidang perangkat lunak penting open source telah menjadi pilihan default
• Saat ini kita sedang menghadapi titik balik di bidang aplikasi sosial yang mirip dengan open source 35 tahun lalu
• Arus baru 'sosial terbuka' telah muncul, dan AT Protocol dari Bluesky dinilai sebagai implementasi yang paling meyakinkan

Struktur dasar web dan kepemilikan data pribadi

• Di masa lalu, web memiliki alamat pribadi seperti alice.com dan bob.com, dan setiap pengguna memiliki ruangnya sendiri untuk bebas mempublikasikan konten
• Jika tidak suka dengan hosting, pengguna bisa pindah ke tempat lain dan alamatnya tetap sama, sehingga tautan lama tidak putus
• Karena itu, pengguna tidak terikat pada penyedia hosting tertentu, dan penyedia harus bersaing
• Dengan kata lain, berkat desain web yang terdesentralisasi, pengguna memegang datanya, dan penyedia hanya berperan sebagai penyedia layanan

Jejaring sosial modern: hilangnya kepemilikan data

• Saat ini, alih-alih mengelola situs sendiri, orang biasanya menerima ID seperti @alice dan @bob yang diberikan perusahaan lalu memposting di aplikasi media sosial
• Data seperti postingan, komentar, dan like disimpan di database perusahaan sosial tertentu
• Struktur ini memungkinkan lahirnya fungsi agregasi sosial seperti pencarian, feed, rekomendasi, dan notifikasi
• Namun, ada efek samping berupa data inti tidak lagi menjadi milik kita
• Pengguna berada dalam situasi di mana mereka tidak bisa bebas membawa keluar data dan relasi yang mereka buat

Masalah: pengguna terkunci di platform

• Saat pengguna pergi, mereka harus meninggalkan seluruh jaringan koneksi yang mereka bangun
• Tidak mudah berganti penyedia hosting, dan ketika meninggalkan platform, koneksi serta data ikut hilang
• Karena platform mengetahui hal ini, pengguna akhirnya harus bertahan meski ada perubahan yang merugikan (iklan berlebihan, distorsi algoritme, penghapusan fitur, dll.)
• Bahkan jika data dibackup atau diekspor, itu hanya 'data mati' tanpa konteks sosial sehingga sulit dihidupkan kembali di tempat lain

Sosial terbuka: pemulihan kepemilikan data dan jaringan

• Dalam sosial terbuka, melalui handle berbasis domain seperti @alice.com, kepemilikan nyata atas data sosial diberikan kepada pengguna
  • Nama terhubung ke domain yang saya miliki seperti @alice.com
• Pengguna mengelola langsung semua data sosial yang mereka buat melalui penyimpanan pribadi (repository)
  • Aktivitas seperti tulisan, komentar, dan follow dicatat di penyimpanan pribadi (repo)
  • Penyimpanan itu hanyalah server web sederhana yang menyimpan catatan dalam format JSON
  • Alamatnya berbentuk at://alice.com/... sehingga bisa saling terhubung
• Penyimpanan berbasis AT Protocol berjalan di atas DNS, HTTP, dan JSON, dan setiap data disimpan dalam bentuk JSON yang terhubung lewat hyperlink
• Bahkan orang yang tidak paham teknologi akan otomatis dibuatkan penyimpanan saat mendaftar aplikasi, sehingga data tetap menjadi milik pengguna terlepas dari aplikasinya
• Data dimiliki di penyimpanan pengguna, dan meski penyedia layanan berganti, kepemilikan serta keterhubungan data tetap terjaga

Struktur dan penerapan aplikasi sosial terbuka

• Setiap aplikasi sosial terbuka, seperti CMS, mengelola sebagian penyimpanan sosial pengguna; aplikasi kini hanyalah alat untuk membaca dan menulis ke penyimpanan pengguna
• Misalnya, data dari berbagai aplikasi seperti Bluesky, Tangled, dan Leaflet bisa hidup berdampingan dalam satu penyimpanan milik pengguna
  • Jika saya menulis di Bluesky, catatannya tersimpan di penyimpanan saya; jika saya memberi bintang pada proyek di Tangled, itu juga masuk ke penyimpanan saya
  • Format data dibedakan dengan namespace (misalnya app.bsky.post, sh.tangled.star) untuk mencegah konflik
  • Seiring waktu, penyimpanan saya menjadi kumpulan data dari banyak aplikasi

Perubahan ekosistem yang dibawa keterbukaan data

• Karena data disimpan secara terbuka, integrasi antar aplikasi, pengembangan layanan baru, referensi bebas ke data satu sama lain, penggunaan ulang, dan remix menjadi lebih mudah
• Bahkan jika sebuah aplikasi berhenti beroperasi, data tetap tinggal di penyimpanan pengguna dan dapat digunakan kembali oleh layanan lain
• Aplikasi baru dapat memanfaatkan relasi/data dari jaringan yang ada untuk mengatasi 'cold start' (masalah membangun jaringan awal)
• Karena data ini bisa dibaca siapa saja, aplikasi lain dapat mengambilnya untuk memuat foto profil atau langsung memanfaatkan relasi follow yang sudah ada
• Walau sebuah aplikasi tutup, data tetap berada di penyimpanan pengguna dan bisa dipakai kembali oleh aplikasi lain

Agregasi dan tantangan teknis

• Data pengguna tersebar di penyimpanan masing-masing, tetapi stream peristiwa perubahan data diterima melalui langganan WebSocket lalu diterapkan ke database lokal
• Melalui relay besar (server perantara), aplikasi menerima event dari seluruh jaringan lalu hanya memfilter event yang diperlukan
• Record data ditandatangani secara kriptografis untuk menjamin keandalan dan konsistensi
• Infrastruktur seperti Graze dan Slices mendukung agregasi sosial terbuka

Bagaimana fungsi agregasi bekerja?

• Meski penyimpanan tiap pengguna terpisah, aplikasi menerima stream event real-time dari penyimpanan pengguna lalu mencatatnya ke database sendiri
• Server perantara (relay) seperti Bluesky mengumpulkan dan meneruskan seluruh stream, lalu aplikasi menyimpan hanya event yang diminati
• Database yang dibangun dengan cara ini dapat menyediakan fungsi seperti pencarian, feed, dan rekomendasi dengan cepat
• Record data ditandatangani secara kriptografis untuk menjamin keandalan dan konsistensi: tanpa harus mempercayai relay, kita tetap bisa memverifikasi keaslian data
• Infrastruktur seperti Graze dan Slices mendukung agregasi sosial terbuka

Gambaran besar

• Web di masa lalu: pengguna memegang konten dan alamat mereka sendiri
• Aplikasi sosial saat ini: ada fungsi agregasi, tetapi data terikat di dalam database milik perusahaan
• Sosial terbuka: fungsi agregasi tetap dipertahankan, tetapi data tetap berada di tangan pengguna
• Aplikasi berubah menjadi sekadar jendela yang mengumpulkan dan menampilkan data pengguna
• Bahkan jika layanan menghilang, data tetap ada dan aplikasi lain dapat menampilkannya kembali dalam konteks baru

Kesimpulan

• Inti dari sosial terbuka adalah menggabungkan keunggulan web pribadi (kepemilikan data, kebebasan hosting, tautan yang tetap hidup) dan kekuatan jejaring sosial tertutup (agregasi, skalabilitas)
• Sosial terbuka menjamin kepemilikan data yang dipimpin pengguna, mobilitas data yang bebas antar aplikasi, dan keberlangsungan layanan
  • Seperti open source yang mengatakan bahwa kode harus menjadi milik pengguna, maka data juga harus menjadi milik pengguna
  • Ini menyelesaikan masalah pengguna yang kehilangan data dan konektivitas di platform tertutup
• Jika lebih banyak produk sosial terbuka bermunculan, batas antar aplikasi akan memudar, dan ekosistem tempat data mengalir secara alami akan berkembang
  • Pada akhirnya, ada kemungkinan masa depan di mana pengguna benar-benar mengendalikan data dan jaringan mereka
• Pada tahap awal, ini akan didorong oleh sejumlah kecil pengembang dan pengguna yang antusias, tetapi ketika fondasi bersama makin matang, pendekatan terbuka berpeluang menang suatu saat nanti
  • Bahkan tanpa memahami konsep teknis (desentralisasi, federasi), orang tetap bisa merasakan manfaat nyata (interoperabilitas data, migrasi yang mudah, keberlanjutan)
  • Sosial terbuka akan meluas secara bertahap berkat upaya jangka panjang berbasis komunitas yang bersemangat dan efek akumulatif

[shakespeares]

Instagram memang juga tempat menyimpan kenangan, tapi sepertinya tidak mudah untuk keluar sesuka hati.
Dari sisi berbagi dan penggunaan data, saya juga merasa ada bagian-bagian yang memang perlu sedikit dikompromikan.

[kimjoin2]

KakaoTalk... sial

[GN⁺]

Komentar Hacker News

• Awalnya kupikir AT Protocol adalah sistemnya Bluesky, jadi semacam versi korporat dari ActivityPub, tetapi setelah membaca tulisan ini, aku jadi sangat suka dengan cara data disimpan di repository yang kupilih. Ini juga selaras dengan prinsip umumnya diriku: aku percaya lebih baik pemfilteran dan semacamnya dijalankan di sisi pembaca daripada saat menulis. Jadi struktur di mana aku bisa menaruh semua yang kuinginkan di repositoriku, lalu orang lain bisa membaca dan memakainya, terasa bagus. Panahnya memang tampak seolah komentar masuk ke dalam repositoriku, tetapi itu sepertinya hanya sedikit ketidakakuratan saat mengekspresikan ide. Secara keseluruhan, menurutku ini struktur yang sangat keren dan terdesentralisasi. Namun ketika benar-benar mencoba menjalankan PDS terpisah sendiri di AT, aku menyadari bahwa meskipun cukup mulus dan rapi dikemas, ada beberapa prasyarat:

  1. Menangani hal seperti SSL secara otomatis
  2. Menjalankan server HTTPS/WSS untuk mendukung berbagai pemrosesan RPC Karena itu, meskipun secara praktis aku ingin memakai https://roshangeorge.dev dan at://roshangeorge.dev sekaligus, untuk yang kedua aku memerlukan https://roshangeorge.dev/xrpc dan wss://roshangeorge.dev. Jadi pada akhirnya aku menjalankannya sebagai https://roshangeorge.dev dan at://at.roshangeorge.dev, serta https://at.roshangeorge.dev dan wss://at.roshangeorge.dev. Tentu ini hal kecil dan tidak merusak arah keseluruhannya. Tetap saja, menurutku ini layak dicatat.

  • Sepertinya aku membuat bingung karena memakai dua jenis panah. Panah garis penuh (turun dari @alice.com) menunjukkan kepemilikan. Itu sama dengan pengelompokan berdasarkan warna. Semua yang berwarna biru berarti milik Alice. Panah putus-putus adalah tautan antar-record. Ini sama seperti <a href>, jadi record apa pun bisa ditautkan secara bebas ke record lain, walaupun berada di repositori yang berbeda. Jika seseorang mengomentari postinganku, komentar itu masuk ke repositori orang yang berkomentar dan dibuatkan keterkaitan dengan tulisan aslinya. Alasan model data dirancang seperti ini adalah agar orang yang melakukan pengindeksan bisa dengan mudah merekonstruksi relasi jika memiliki kedua record itu. Misalnya Bob mengomentari tulisan Alice, maka komentar Bob ada di repositori Bob dan tulisan Alice ada di repositori Alice. Jika seseorang menulis komentar di postinganku, komentar itu selalu tetap berada di repositori orang tersebut. Asumsi kuncinya adalah tidak ada yang bisa membuat record di repositori orang lain.

  • Paket PDS bawaan memang mendukung penanganan SSL otomatis, tetapi itu bukan keharusan; itu hanya dibuat agar mudah diterapkan oleh pengembang. URI at:// berbentuk at://DID/..., dan handle yang mudah dibaca manusia dipetakan ke DID melalui DNS TXT record (_atproto.roshangeorge.dev). DID itu terhubung ke dokumen yang menyatakan lokasi server, jadi rute HTTPS/WSS juga bisa ditempatkan di mana saja. Selain itu, like, balasan, dan semacamnya pada postinganku masuk ke repositori orang yang melakukan aksi itu, bukan ke repositoriku. Intuisiku tentang bagian ini ternyata benar.

• Aku tadinya mengira ActivityPub adalah protokol yang lebih baik dan AT hanyalah tiruan murahan, tetapi tulisan ini membuatku sadar bahwa AT jauh lebih baik. Inti utamanya adalah beberapa program bisa berbagi identitas yang sama. Itu benar-benar fitur yang luar biasa dan rasanya sangat membuka wawasan.

  • Penjelasan tentang ATProto biasanya berfokus pada kepemilikan data, tetapi sebenarnya ActivityPub lebih kuat di sisi pemrosesan data. ATProto punya struktur yang memandang dunia secara terbuka, jadi semua peristiwa terlihat oleh AppServer global tepercaya dan harus dinilai langsung, sehingga pembuatan feed, hak akses, dan sebagainya semuanya bergantung pada perantara kepercayaan. ActivityPub justru lebih mirip RSS atau email: serverku hanya mengelola feed yang kuikuti, dan inbox langsung berisi postingan yang memang bisa kuakses. Inilah juga alasan di Bluesky tidak mungkin ada "like privat" seperti di Twitter. Setiap AppView harus melacak sendiri jumlah like untuk semua posting di jaringan, yang sangat merepotkan. Dalam jangka panjang, menurutku struktur ActivityPub akan lebih menguntungkan. Dan bagian “beberapa program berbagi identitas yang sama” sebenarnya juga sudah ada dalam desain awal ActivityPub. Hanya saja implementasi awal yang paling populer membuang fitur itu agar cocok dengan struktur yang sudah ada.

  • Perdebatan AT vs AP memang sangat rumit. Di komunitas kami juga sudah berkali-kali dibahas, jadi kutinggalkan thread yang mungkin berguna: https://github.com/bevyengine/bevy/discussions/18302

  • Senang mendengar bagian seperti ini terasa nyambung. Selalu melelahkan ketika harus terus dibandingkan dengan AP, karena cakupannya memang sama sekali berbeda.

  • Tulisan yang membahas sudut pandang serupa dari perspektif engineer sistem terdistribusi juga menarik. https://atproto.com/articles/atproto-for-distsys-engineers

  • Jadi aku penasaran, apakah itu berarti ada layanan identitas yang terpusat.

• Apa pun protokol terdistribusi yang menang, aku tidak terlalu peduli, tetapi meskipun ATProtocol tampak bagus secara teori, dalam praktiknya ActivityPub makin terasa lebih menarik. Aku cukup aktif di Lemmy, dan di sana cukup hidup dan menyenangkan.

  1. 99,99% pengguna AT terkonsentrasi di Bluesky. Ini adalah layanan yang dipimpin perusahaan. Meski mereka bilang tidak mengendalikan protokol, pada praktiknya mereka adalah instans dominan dari protokol tersebut, jadi ada risiko mereka mengubahnya sesuai keinginan sendiri. Bahkan ada kekhawatiran mereka bisa memutuskan lima tahun lagi bahwa migrasi tidak dimungkinkan. Hal seperti ini sudah berulang kali terjadi di berbagai media sosial.
  2. Pengguna tidak peduli dengan protokol; yang jauh lebih penting adalah inersia dan basis pengguna. Bahkan di berbagai layanan alternatif Reddit yang memakai AP, masuknya pengguna baru sangat sulit, dan meyakinkan orang untuk pindah lagi juga susah. Aku takut upaya seperti ini hanya akan semakin memecah komunitas kecil yang sudah ada, dan pada akhirnya semua orang menyerah lalu kembali ke platform besar. Kemudahan pindah akun memang fitur yang keren, tetapi pencadangan/pemulihan setelan dan proses membuat akun di instans baru saja sebenarnya sudah cukup sederhana. Jadi tidak terasa sebagai perubahan besar. Situs rujukan: https://arewedecentralizedyet.online/ Lemmy, programming.dev, Piefed dan lainnya juga sedang dinilai cukup baik belakangan ini

  • Berbeda dengan Mastodon, di AT konsep instans itu sendiri berbeda. Bahkan di dalam infrastruktur Bluesky ada banyak PDS, dan secara struktural cara kerjanya juga berbeda secara hierarkis (lihat artikel terkait). Jadi tidak tepat menyebutnya sebagai satu instans dominan tunggal. Tentu kekhawatiran bahwa perusahaan bisa mengatur protokol sesuka hati adalah hal yang realistis. Tetapi sejauh ini mereka dinilai berperan sebagai pengelola yang baik. Menurutku ini akan terselesaikan bertahap seiring ekosistem bertumbuh. Dan memang ada kekhawatiran Bluesky bisa tutup dan migrasi jadi mustahil, tetapi pencadangan dan migrasi sudah tertanam di protokolnya sendiri. Selama ada file CAR, kapan pun bisa pindah ke host lain. Mastodon kehilangan banyak hal saat migrasi akun, tetapi atproto memungkinkan perpindahan yang 100% transparan.

  • Pada akhirnya, entah Bluesky atau Mastodon, begitu masuk isinya cuma politik Amerika. Aku tidak terlalu suka drama politik mingguan, jadi sepertinya platform yang lebih beragam seperti Tumblr, Pinterest, atau TikTok lebih cocok buatku.

  • Mastodon memang tidak sepenuhnya identik dengan ActivityPub, tetapi aku tidak bisa memercayainya karena balasan kadang tiba-tiba menghilang. Ada postingan yang tadinya masih ada lalu hilang lagi, dan itu menjadi salah satu dari dua alasan aku meninggalkan Mastodon.

• Agak disayangkan bahwa tiap aplikasi memakai tipe koleksi sendiri, dan walaupun mereka bisa saling berbagi koleksi, pada akhirnya belum jelas apakah aplikasi-aplikasi itu benar-benar akan kompatibel satu sama lain. Salah satu keindahan ActivityPub adalah pengguna Mastodon bisa mengikuti pengguna Pixelfed tanpa perlu terlalu memikirkannya. Rasanya seperti Twitter, Instagram, Reddit, YouTube, dan Substack semuanya otomatis terhubung tanpa pengaturan khusus.

  • AP pada dasarnya memiliki interoperabilitas yang cukup baik lintas layanan pada tipe Status dan Question. Mastodon, Pixelfed, Misskey, Pleroma, dan lainnya semua berputar di sekitar skema itu. Tetapi dukungan untuk tipe lainnya sangat terbatas, jadi jenis konten lain tidak didukung dengan baik. Masalahnya adalah kurangnya organisasi komunitas untuk ekstensi di luar standar. ATproto mewajibkan definisi lexicon/schema untuk koleksi data, dan implementasi referensi maupun pihak ketiga menyediakan validasi skema. Jadi interoperabilitas dasar lebih terstruktur dengan jelas, tetapi menurutku perlu juga lebih fleksibel agar dukungan opsional untuk beberapa field tambahan dimungkinkan. Ada juga contoh seperti Bridgy Fed yang menempelkan data dari APub sebagai metadata seperti URL asli, teks, dan sebagainya. (Lihat https://fed.brid.gy/docs#bluesky-fields)

  • Upaya untuk memperbaiki lexicon bersama sedang berjalan: https://github.com/lexicon-community

• Aku mulai merasa proyek-proyek yang menyerukan "Twitter generasi berikutnya" sedikit meleset dalam cara mereka menyelesaikan masalah. Setelah berhasil mereplikasi fitur Twitter dengan sempurna, mereka tetap akan mentok pada masalah kurangnya pengguna dan konten, alias chicken and egg problem. Pada akhirnya orang berkumpul di tempat yang banyak orangnya, dan saat ini itu masih Twitter. Sebaliknya, pendekatan yang tampak lebih baik bagiku adalah seperti timeline yang baru diluncurkan OpenAI belakangan ini: kumpulkan data dulu di belakang layar, lalu sampaikan ke pengguna. Implementasi konkretnya bisa berbeda, tetapi arah besarnya terasa benar. Kebanyakan pengguna tidak terlalu menghargai kemampuan menulis tweet itu sendiri; nilai sesungguhnya ada pada konsumsi data (sourcing konten). Dari sudut pandang ini, pembaca RSS multi-sosial + opsi P2P terasa sebagai arah yang lebih baik. Ini cuma pendapat pribadiku.

  • Seperti dijelaskan di artikel, pada tahap awal framing-nya memang memakai microblogging, tetapi sebenarnya bentuknya bisa jauh lebih beragam daripada sekadar gaya Twitter. Misalnya Tangled adalah "Github on atproto", dan Leaflet adalah "Medium on atproto". Keterbatasan pendekatan P2P sisi klien adalah sulitnya menjamin agregasi berskala besar dan konsistensi, padahal itu adalah hal dasar yang diharapkan kebanyakan pengguna umum dari aplikasi sosial. Contoh OpenAI itu juga justru area yang menjadi kekuatan atproto. Karena datanya sudah ada di jaringan, crawling, indexing, dan alat otomasi bisa dipasang dengan mudah. Sebagai contoh awal, lihat https://github.com/graze-social/iftta.

  • Jejaring sosial tumbuh bukan dengan pendekatan “sama, tapi ada tambahan sedikit!”, melainkan ketika muncul cara baru yang sebelumnya mustahil dilakukan di platform lama.

  • Itulah kenapa Nostr berbeda! Mau bikin blog, layanan ala Twitter, streaming, messenger, atau apa pun, semua bisa. Kumpulan contohnya: https://nostrapps.com

• Aku penasaran apakah TLD gratis itu mungkin. Biaya sebenarnya dari pendaftaran domain itu apa? Mengingat Let's Encrypt bisa membagikan sertifikat keamanan secara gratis, aku heran kenapa organisasi nirlaba tidak bisa juga menyediakan domain gratis. Tidak perlu tampak cantik. Menumpuk beberapa UUID v7 juga tidak masalah; yang penting unik secara global dan gratis. Setelah browser terhubung, alamat panjang pun akan diingat, jadi itu bukan masalah. Apa ide seperti ini memang seburuk itu?

  • Di atproto, peran seperti ini diambil oleh did:plc. https://web.plc.directory/ bisa menerbitkan ID gratis. Contohnya ID-ku adalah https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. Itu bisa dikaitkan dengan domain melalui TXT record yang mengarah ke did:plc tersebut.

  • TLD gratis secara realistis sulit diwujudkan. TLD dan public suffix list punya berbagai aturan, biaya, dan kekhususan pengelolaan; lihat https://github.com/publicsuffix/list. Namun domain biasa yang bukan TLD bisa dipakai dengan bebas, dan subdomain gratis juga bisa saja dibagikan. Masalahnya, kalau benar-benar mengoperasikan layanan seperti itu, segera akan dihantam spam, phishing, dan serangan dark internet lainnya, sampai akhirnya menyesal menjalankannya. Mirip siapa pun bisa membuat URL redirector, tetapi mengoperasikannya di dunia nyata adalah perkara lain. Jika dijalankan dengan serius, cepat atau lambat akan menabrak masalah. Realitas yang menyedihkan.

  • Ini pada dasarnya mirip dengan distribusi alamat IPv6. Sekarang sebagian besar internet rumahan memberi public IPv6 dalam blok /64, tetapi kebanyakan ISP memblokir port dengan firewall sehingga secara praktis sulit dimanfaatkan. Selain itu, kalau berganti ISP, alamatnya juga mudah hilang. Untuk menjadikannya alamat IPv6 yang benar-benar permanen dan portabel, kita perlu membagikan ruang alamat provider-independent ke individu secara gratis, lalu menghubungkannya sampai ke routing global melalui BGP. Secara teori mungkin, tetapi belum pernah benar-benar diwujudkan (mirip kondisi sebelum Let's Encrypt lahir). Aku juga tidak yakin kenapa penamaan berbasis DNS dibutuhkan, karena jika bukan untuk sesuatu yang pendek dan mudah diingat, DNS tidak terlalu cocok. Tetapi pendekatan seperti ngrok yang menerbitkan domain di bawah gTLD sendiri mungkin layak dicoba. Dulu ccTLD .me memang pernah membagikan domain gratis seperti ini, dan sebagai gantinya mereka menyisipkan iklan ke semua trafik lewat server proxy perantara.

  • .tk dulu gratis dan sempat menjadi ccTLD terbesar di dunia berdasarkan jumlah pendaftaran. Namun kebanyakan dipakai untuk penyalahgunaan. Setelah Facebook menggugat operatornya (perusahaan Belanda Freenom) dengan tuduhan terlibat dalam phishing, layanan gratis itu kini tidak lagi tersedia.

  • Dulu pernah ada inisiatif TLD .FREE, tetapi karena hambatan pelaksanaan dan tenggat yang tidak terpenuhi, sekarang proyeknya meredup https://icannwiki.org/.free

• Kalau melihat tulisan Dan, aku selalu klik. Aku agak khawatir open web berhasil terutama karena first-mover advantage. Di sisi lain, melihat open source berhasil memberiku harapan. Aku ingin melihat dunia di mana sesuatu seperti atproto berhasil. Sangat disayangkan bahwa aplikasi yang lebih baik sering tidak bisa menang hanya karena network effect.

  • HTML berhasil karena sifatnya ‘gratis’. Saat itu ada banyak standar hypermedia berbayar, tetapi HTML jauh lebih mudah diakses dibanding para pesaing itu. Siapa pun bisa dengan mudah membuat browser atau server.

  • Fakta bahwa ATProto dirancang untuk menembus batas network effect juga merupakan keunggulan besar. Jika semua orang bermigrasi ke basis atproto, maka kita tidak lagi perlu memindahkan jejaring sosial “sekali lagi untuk terakhir kalinya”. Pada akhirnya ini menyediakan lingkungan yang terdesentralisasi dan memungkinkan persaingan bebas.

• Secara realistis, sulit membayangkan sistem seperti ini bisa tersebar luas. Target pengguna media sosial tradisional dan pengguna yang berorientasi pada desentralisasi adalah kelompok yang sama sekali berbeda. Kebanyakan orang hanya peduli pada platform sebagai alat, bukan pada sistem di baliknya. Pada akhirnya, kalau semua orang hanya membuat akun Bluesky, semuanya akan terkonsentrasi lagi pada segelintir layanan besar dan menjadi tidak bermakna seperti sebelumnya.

  • Bahkan jika semua orang berkumpul di bsky.social, itu tetap kemajuan yang sangat besar dibanding sebelumnya. Sama seperti kita tidak menyebut web terpusat hanya karena banyak server berkumpul di AWS, di sini orang juga tetap bisa pindah kapan saja kalau perlu.

  • Faktanya, bluesky sendiri belum sepenuhnya mengimplementasikan federation. Semua trafik masih bergantung pada satu server router "BGS".

  • Sayangnya, pada akhirnya sumber masalahnya memang ‘manusia’.

• Perasaanku campur aduk soal upaya ini. Di satu sisi, idenya sepenuhnya sesuai seleraku. Gagasan bahwa semua orang memiliki konten mereka sendiri selaras dengan gerakan Indie web, dan kualitas halaman serta tulisan-tulisan ini juga sangat mengesankan. Di sisi lain, hampir tidak ada pengembang yang benar-benar menerapkan standar seperti ini ke blog pribadi atau proyek open source, dan adopsinya pun rendah di kalangan vlogger/blogger maupun pengguna umum. Aku khawatir karena begitu banyak orang tidak peka terhadap kepemilikan data, keterbukaan, dan interoperabilitas. Orang-orang tampaknya hanya menginginkan feed seperti TikTok atau Instagram Reels. Aku menghormati visi dan usahanya, tetapi aku masih bertanya-tanya apakah ini bisa menjadi arus utama, bukan sekadar hobi yang sangat niche.

  • Masih ada pekerjaan untuk membuat pengalaman pengembang lebih mudah. Tetapi laju perkembangan di area ini sangat cepat, jadi 6~12 bulan ke depan terasa sangat menjanjikan. Kebanyakan orang belum memahami bahwa ATProto bukan hanya untuk Bluesky, melainkan bisa diterapkan ke bidang yang jauh lebih beragam, dan butuh waktu sampai hal ini terlihat lebih konkret di pasar.

  • Aku penasaran kenapa konsep 'kepemilikan data' dianggap sepenting itu, dan kenapa fakta bahwa publik tidak peduli harus benar-benar dikhawatirkan. Dulu orang juga mengonsumsi konten tanpa kepemilikan, seperti TV, buku, atau radio. Sekarang hanya ditambahkan kesempatan untuk mengunggah sesuatu dan dilihat oleh sekitar, jadi apakah benar-benar penting apakah seseorang 'memiliki' postingan Instagram-nya atau tidak.

  • Aku setuju. Pada akhirnya, kalau kita ingin teknologi ini berhasil, kita sendirilah yang harus aktif menyebarkannya dan mendorong adopsi massal. Mungkin suatu hari akan muncul pendiri/CTO yang jatuh cinta pada open social lalu meluncurkan aplikasi sukses untuk publik, dan jika kita tidak melakukan apa-apa, ini tidak akan pernah berhasil.