atproto tidak memiliki instance
(overreacted.io)- Pertanyaan yang mencari “instance Bluesky” menerapkan begitu saja model instance Mastodon ke atproto, padahal atproto dirancang dengan memisahkan hosting dan agregasi aplikasi
- Seperti RSS dan Google Reader, data tidak terkurung di dalam aplikasi, tetapi berada di repositori yang di-host, lalu berbagai aplikasi mengambil dan menampilkan data tersebut
- Instance Mastodon adalah struktur di mana hosting, aplikasi, identitas, dan relasi federasi terikat dalam satu kotak, sehingga keputusan admin atau gangguan pada instance langsung memengaruhi pengalaman pengguna
- Di atproto, pengguna bisa memindahkan hosting atau membuat dan mencoba aplikasi baru, dan aplikasi seperti Tangled, Semble, dan Sidetrail berjalan terpisah dari Bluesky
- Untuk melihat desentralisasi atproto, yang perlu diperhatikan bukan jumlah instance Bluesky, melainkan apakah perpindahan ke hosting alternatif dan ekosistem aplikasi baru benar-benar berjalan
Model yang lebih dekat ke RSS dan Google Reader
- Pada era RSS, pengguna mempublikasikan tulisan di blog mereka sendiri, dan aplikasi seperti Google Reader atau Feedly mengagregasi tulisan dari berbagai blog
- Tulisan itu tidak “tinggal” di dalam Google Reader, melainkan tetap berada di blog masing-masing atau lokasi hostingnya
- Intinya adalah pemisahan antara hosting dan agregasi
- Hosting adalah tempat konten sebenarnya berada
- Aplikasi agregasi lebih mirip proyeksi (projection) yang menampilkan konten dari berbagai sumber
Media sosial terpusat dan respons Mastodon
- Media sosial tradisional beroperasi dengan mengumpulkan semua pengguna ke dalam satu aplikasi dan satu ruang
- Struktur ini menciptakan sentralisasi dan efek jaringan yang kuat, dan diskusi tentang jejaring sosial terdesentralisasi berangkat dari bagaimana memecah masalah ini
- Pendekatan ala Mastodon adalah tiap komunitas menjalankan “Facebook kecil” atau “Twitter kecil” mereka sendiri, dan kotak ini disebut instance
Hal-hal yang diikat oleh instance Mastodon
- Pengguna menjadi bagian dari instance tertentu
- Alasan format login Mastodon adalah
[email protected]juga karena instance menjadi bagian dari identitas - Pengguna bukan “Alice” yang abstrak, melainkan “Alice dari instance #1”
- Alasan format login Mastodon adalah
- Agar pengguna dari instance berbeda bisa berkomunikasi, instance-instance itu harus saling bertukar pesan
- Saat Alice ada di instance #1 dan Bree ada di instance #2, jika Alice mengikuti Bree, maka tulisan Bree dikirim ke instance #1
- Relasi pengiriman seperti ini adalah federasi
- Karena hosting dan aplikasi terikat bersama, pengguna menjadi sangat bergantung pada instance
Batasan yang muncul dari keterikatan instance
- Jika terjadi konflik antar admin instance, mereka bisa menghentikan federasi satu sama lain
- Dalam kasus ini, pengguna bisa tidak lagi melihat tulisan teman mereka
- Jika instance pengguna mati, identitas yang terikat pada instance itu juga ikut hilang
- Karena yang diikuti oleh para pengikut adalah “pengguna dari instance tersebut”
- Panah koneksi antar instance bertambah secara O(n²)
- Saat ini mungkin belum jadi masalah besar, tetapi bisa menjadi penting jika jejaring sosial dengan model ini makin populer
Perbedaan inti atproto
- atproto tidak berangkat dari konsep instance ala Mastodon, melainkan kembali ke model RSS dan Google Reader
- Di level jaringan, atproto memisahkan hosting dan agregasi
- Data berada di hosting
- Aplikasi mengagregasi data dari hosting milik banyak orang
- Karena itu, atproto tidak memiliki instance
- Hosting bisa diganti
- Aplikasi mengagregasi data dari banyak hosting
- Struktur ini terasa sebagai bentuk desentralisasi yang lebih kaya daripada sekadar “menjalankan banyak salinan dari satu aplikasi”
Desentralisasi yang bisa dilakukan langsung oleh pengguna
- Pengguna bisa mengganti hosting
- Penulis menyatakan bahwa ia memindahkan data atproto miliknya ke Eurosky, dan selain beberapa masalah UX, prosesnya berjalan otomatis
- Jika ingin lebih aktif, Anda bahkan bisa melakukan hosting sendiri gratis di Cloudflare
- Pengguna juga bisa mencoba aplikasi baru atau membuatnya sendiri
- Tangled dan Semble adalah contoh aplikasi atproto yang tidak terkait dengan Bluesky
- Penulis membuat aplikasi bernama Sidetrail, dan aplikasi ini bersifat open source
- atproto juga punya tutorial Statusphere untuk pembuatan aplikasi
Mengapa “jumlah instance Bluesky” meleset
- Di Mastodon, mengukur desentralisasi lewat jumlah instance adalah pendekatan yang wajar
- Karena bentuk utama desentralisasi yang tersedia di Mastodon adalah menjalankan lebih banyak kotak yang menggabungkan hosting dan aplikasi, lalu membuatnya saling berkomunikasi
- Di atproto, semua aplikasi lebih mirip proyeksi dari seluruh Atmosphere
- Strukturnya sama seperti Feedly dan Google Reader yang menampilkan keseluruhan Blogosphere
- Menjalankan banyak salinan penuh server basis data Bluesky memang mungkin, tetapi secara umum tidak lebih berguna daripada menjalankan banyak salinan Google Reader
- Beberapa salinan memang ada untuk kebutuhan tertentu
- Blacksky adalah contoh untuk kebutuhan spesifik seperti filosofi moderasi yang berbeda
- Klien reddwarf.app tidak memakai basis data khusus, melainkan menggunakan constellation, cache gratis yang dijalankan komunitas
- Infrastruktur jaringan bersama seperti relay disebut telah dioperasikan dengan biaya rendah selama setahun
Tolok ukur yang perlu dilihat di atproto
- Untuk melihat desentralisasi atproto, yang perlu diperhatikan bukan “jumlah instance Bluesky”, melainkan hal-hal berikut
- Apakah orang-orang berpindah ke hosting alternatif
- Apakah orang-orang membuat dan memakai aplikasi baru
- Memisahkan hosting dan aplikasi bisa memperbaiki insentif yang rusak baik di sosial tertutup maupun sosial federatif
- Inti atproto adalah menempatkan data pengguna di luar aplikasi, sementara aplikasi melakukan agregasi di atas data tersebut
1 komentar
Komentar Hacker News
Pertanyaan “di mana instance Bluesky” tampaknya sengaja disalahpahami untuk mengangkat ATProto dan merendahkan ActivityPub
Dengan begitu, fakta teknis menarik seperti relay ATProto beserta kelebihan dan kekurangannya, atau migrasi akun ActivityPub beserta plus-minusnya, jadi dihilangkan atau dipelintir, dan menciptakan konflik yang tidak perlu antara dua platform yang memecahkan masalah serupa
Ada juga orang yang memakai kata “instance” dalam arti umum seperti server, software yang sedang berjalan, virtual machine, atau container; saya tidak paham kenapa harus dipahami hanya dalam konsep ala Mastodon
Diagram dan penjelasannya bagus, tetapi sindiran halus ke ActivityPub terasa lahir dari sikap permusuhan alih-alih penyampaian informasi, jadi cukup disayangkan
Jika dibandingkan dengan “di mana instance Google Reader”, menurut saya kejanggalan pertanyaan itu jadi terlihat jelas, dan dua gambar di akhir tulisan cukup baik menjelaskan hal-hal yang sering terlewat dalam diskusi awal tentang atproto/ActivityPub
Alasan relay tidak dimasukkan ditulis di sini: https://news.ycombinator.com/item?id=48600963
Relay lebih dekat ke optimasi performa daripada inti modelnya, jadi di tulisan itu saya ingin fokus pada modelnya sendiri
Ketika sebuah kata mulai melekat pada konsep dan struktur tertentu, banyak orang akan membayangkan struktur federasi ala ActivityPub saat melihat “media sosial terdesentralisasi”, lalu saat melihat ATProto mereka bertanya, “kenapa hanya ada satu instance Bluesky tempat orang mendaftar?”
Mungkin bukan sudut pandang yang sepenuhnya baru, tetapi bagi orang yang sudah terlanjur punya asosiasi lama seperti itu, ini tampak seperti tulisan berguna yang layak ditautkan lagi nanti
Alih-alih dekret “filioque”, yang bolak-balik adalah tulisan blog dari kedua kubu yang membicarakan hal berbeda soal definisi “federasi”
Model Fediverse mudah dipahami dari sudut pandang jejaring sosial yang sudah ada, tetapi ATProto adalah konsep baru yang mencoba memberi pengguna kedaulatan data sambil tetap mendapatkan skalabilitas jejaring sosial yang terpusat
Menurut saya analogi di sini rusak
RSS sama sekali tidak bergantung pada Google Reader, dan bahkan di masa jayanya ketergantungannya lebih kecil daripada email sekarang bergantung pada Gmail
Dalam ATProto, agar AppView menjadi berguna, ia sangat bergantung pada relay, dan biaya menjalankan relay juga cukup besar
Selain itu, lingkaran kuning di diagram RSS yang berarti blog berbeda sifatnya dengan lingkaran yang berarti posting Facebook. Blog itu sendiri sudah independen
Ini bukan berarti ATProto buruk, tetapi tulisan ini terasa lebih menambah kebingungan daripada memperjelas
Dulu memang sedikit lebih mahal karena menyimpan semua traffic, tetapi bagian itu dihapus di sync 1.1, dan sekarang cukup mudah dijalankan bahkan di virtual machine seharga 20 dolar per bulan
Yang benar-benar mahal dan sulit adalah moderasi, baik di sistem terpusat maupun terdesentralisasi
Penulis tulisan ini pernah membahas salah paham umum tentang relay 9 bulan lalu: https://news.ycombinator.com/item?id=45077291#45078223
Menurut saya, relay adalah perekat yang membuat ATProto bekerja dengan performa baik
Ia tampaknya berperan mengangkut data tanpa peduli isi kontennya, sekaligus mengurangi jumlah layanan yang perlu diketahui tiap AppView
Seperti yang juga disebut di tulisan itu, peningkatan besar dibanding Mastodon adalah relay, AppView, dan PDS merupakan layanan terpisah dengan kebutuhan penskalaan yang berbeda-beda, dan ini adalah solusi yang cukup elegan untuk masalah desain sistem
[1] https://atproto.com/guides/glossary
Hanya saja itu optimasi yang tidak terlihat, dan ada strategi lain juga, jadi di tulisan itu sebagian besar sengaja dihilangkan
Misalnya, banyak aplikasi kecil saat ini tidak membuat indeks database sendiri dan malah bergantung pada Constellation(https://constellation.microcosm.blue/), sehingga sama sekali tidak memakai relay
Mereka mengklaim hanya menghapus konten yang ilegal untuk di-host, tetapi saya tidak tahu seberapa benar itu, dan selalu ada risiko kebijakan itu berubah ke depan
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
Penjelasan tentang perbedaan dua pendekatan itu bagus.
Namun, tidak menjawab pertanyaan “lalu bagaimana ATProto menyelesaikan masalah yang diselesaikan oleh instance,” jadi terasa frustrasi.
Misalnya, kalau defederation dianggap sekadar alasan tak jelas yang membuat postingan teman bisa tidak terlihat, maka kita juga tidak bisa menjawab “kalau begitu, bagaimana atproto menyelesaikan masalah yang diselesaikan oleh defederation?”
Dalam framing ini, jawaban dasar yang muncul secara alami adalah “tidak menyelesaikannya”.
Di tingkat hosting, seperti blogspot.com atau Cloudflare memblokir hal tertentu dalam kasus tertentu, penyedia hosting bisa menangguhkan akun karena sesuatu yang jelas-jelas ilegal.
Di tingkat aplikasi, pengelola aplikasi dan moderator menanganinya seperti layanan web lain yang mengelola konten buatan pengguna.
Itu menjadi pilihan pengembang aplikasi: bisa menyediakan elemen dasar moderasi ruang pengguna seperti Reddit, atau memasang layanan moderasi terpisah seperti Bluesky.
Karena tidak ada padanan “instance komunitas” yang bisa saling bertikai, maka juga tidak ada defederation. Yang ada hanya hosting, aplikasi, dan moderasi tingkat aplikasi sesuai pilihan pengembang aplikasi.
Ini pada dasarnya mirip dengan yang dilakukan Microsoft pada email. Selain penyedia terbesar, pesan dibuang, dan karena pada dasarnya sistemnya terfederasi, pengguna yang ingin pesannya terkirim akhirnya harus memakai Microsoft atau pemain besar lama lainnya.
Akibatnya, instance baru tidak bisa mengirim pesan dan tidak bisa mendapatkan pengguna. Ini menciptakan insentif yang menyimpang bagi pemain besar lama untuk tidak berfederasi dengan instance baru.
Dalam jangka panjang, pilihan arsitektur seperti ini mengokohkan oligopoli.
Katanya ini perlu untuk pencegahan spam, tetapi ada juga penyedia yang tidak melakukan itu, dan mereka juga tidak mengalami masalah spam lebih parah, sebagaimana email biasanya tetap bisa terkirim ke Gmail jika DKIM, reverse DNS, dan setelan lain dikonfigurasi dengan benar.
Alternatif yang jelas adalah pemfilteran di sisi klien. Jika filter disediakan oleh penyedia daftar filter yang sifatnya seperti uBlock, bukan oleh operator seperti Microsoft, maka mereka tidak punya insentif untuk menggiring semua orang ke instance mereka sendiri karena mereka tidak mengoperasikan instance tertentu.
Kecuali jika ada sangat banyak AppView yang bisa mengonsumsi seluruh firehose, bebas dipilih di antara satu sama lain, dan bisa dijalankan sendiri dengan murah sebagai semesta alternatif.
ATProto lebih mirip RSS di dunia tempat orang hanya bisa membaca RSS lewat Google Reader atau layanan kloning berskala serupa, tanpa RSS reader desktop atau mobile.
Kalau bunyinya seperti bebek, ya itu bebek.
Akun memiliki satu PDS, dan DID menunjuk ke PDS yang menjadi feed data resmi pengguna sekaligus tujuan penulisan.
Datanya bisa direplikasi, tetapi PDS diperlakukan sebagai sumber otoritatif.
Ini jauh lebih dekat ke arsitektur klien/server daripada arsitektur terdistribusi.
Tidak ada database P2P, juga bukan menulis ke DHT atau peer. Penulisan dilakukan ke PDS, lalu penulisan itu dicerminkan secara opsional.
Discovery juga dilakukan lewat DNS, jadi tidak ada proses bertanya ke peer untuk mendapatkan data.
Relay juga dihubungkan bukan sebagai peer, melainkan sebagai klien yang meminta salinan data yang secara otoritatif di-host di PDS.
Saya rasa tidak berlebihan menyebut PDS sebagai instance dan relay sebagai mirror.
Hanya saja, itu berbeda dari makna yang biasanya dimaksud orang ketika mengatakan “instance” di Mastodon.
Di Mastodon, instance adalah paket yang tak terpisahkan antara hosting data, aplikasi, komunitas, dan moderasi.
Saya memahaminya begini: ATproto mengorbankan desentralisasi yang benar-benar murni demi konsistensi, sedangkan Mastodon dan ActivityPub mengorbankan konsistensi yang benar-benar murni demi desentralisasi yang lebih mudah diakses
Karena menjalankan node ActivityPub jauh lebih mudah diakses bagi pengguna self-hosting biasa dibanding menjalankan relay konten AT
Pada AT, yang pada akhirnya bisa “didesentralisasikan” hanyalah data milik sendiri, jadi ini lebih dekat ke kepemilikan data sendiri daripada kepemilikan bersama atas sebagian jaringan
Ini juga sudah berkali-kali dibahas di HN
Di ActivityPub, menjalankan instance berarti menangani data, aplikasi, sampai masalah penskalaan berikutnya, jadi Anda harus memilih antara memikul tanggung jawab operasional sendiri atau terikat pada instance orang lain
Bahkan jika Anda tidak suka dengan instance yang dipilih dan ingin pindah, jika itu belum berubah, keadaannya hampir seperti harus mulai dari nol
Di AtProto, cukup mudah berpindah ke platform aplikasi lain sambil mempertahankan identitas yang sama, dan mengekspor data dari platform untuk self-hosting juga setidaknya memungkinkan, meskipun pengalaman penggunanya sulit
Misalnya saya baru-baru ini pertama kali mencoba Tangled, dan bisa masuk dengan domain berbasis bsky yang sudah ada (
h14h.com) Tidak perlu membuat akun baru atau nama pengguna baru, rasanya seperti saya memang sudah ada di sanaMenyiapkan self-hosting repositori
gitdi VPS juga paling lama cuma setengah hari, dan berjalan sebagai layanan backend yang nyaris tidak perlu diperhatikanDalam skenario terburuk, di tangled.org akan muncul banner seperti “repositori mungkin sudah usang dan tidak kompatibel dengan Tangled terbaru”, lalu cukup build ulang image Docker ke versi terbaru dan deploy lagi untuk menyelesaikannya
Secara arsitektur AtProto memang jelas lebih sulit dipahami, tetapi menurut saya membuatnya benar-benar bisa dipakai pengguna justru jauh lebih sederhana
Dalam kepala saya ini lebih mirip prasmanan trade-off daripada satu slider tunggal
Sebagai catatan, di dunia AP juga ada individu dan tim kecil yang menjalankan relay, mirror, cache, AppView, dan sebagainya. Hanya saja benar bahwa makin besar skalanya, biayanya bisa makin mahal
AT bukan hanya menawarkan konsistensi, tetapi juga model data bersama lintas aplikasi
Karena itu aplikasi bisa merujuk dan me-render konten dari aplikasi lain. Bentuknya seperti web dari JSON bertipe, dan aplikasi yang berbeda adalah lensa untuk melihat jaringan yang sama
Siapa pun bisa membangun pengalaman baru di atas data yang sudah ada, dan di AP hampir tidak ada padanannya
AP mengikat data ke aplikasi, tetapi pada AT lebih mirip semua aplikasi meng-query satu basis data global yang berisi data seluruh dunia
Saya tidak paham kenapa diskusi selalu macet di relay. Sekarang kalau mau, relay bisa dijalankan dengan biaya kira-kira $30 per bulan, dan Anda juga bisa memakai relay Bluesky atau relay komunitas secara gratis
Banyak aplikasi sama sekali tidak memakai relay dan bergantung pada indeks komunitas seperti Constellation(https://constellation.microcosm.blue/). Bahkan ada aplikasi yang tidak menjalankan server atau basis data sendiri sama sekali
Tetapi justru sebaliknya, saya ingin berargumen bahwa ATproto lebih terdesentralisasi, atau setidaknya sedang bergerak ke arah itu
Di dunia ActivityPub, identitas, aplikasi, dan hosting pada dasarnya saling terikat
Untuk memakai Lemmy, Anda harus membuat akun ActivityPub kedua yang permanen dan terpisah di instance Lemmy itu, atau hanya memakai Lemmy sejauh instance Mastodon Anda tahu cara mengirim pesan yang dipahami Lemmy
Setiap aplikasi ActivityPub baru menciptakan masalah interoperabilitas baru. Karena masing-masing aplikasi memiliki identitas dan hostingnya sendiri
Tidak ada cara agar instance Mastodon yang saya self-host bisa memberikan identitas ke server Lemmy, lalu server Lemmy itu menyuruh instance saya untuk meng-host konten atas nama saya
Untuk menyamai tingkat yang dibicarakan ATProto, setidaknya itu perlu ada. Meski saya tidak tahu seberapa jauh ini berlaku pada ATProto yang benar-benar ada, dan ActivityPub yang benar-benar ada juga tidak seinteroperabel seperti yang sering diklaim para pendukungnya
Blog ini menjelaskan arsitekturnya dengan baik
Tetapi dalam praktiknya, saya menganggap “masalahnya” adalah perusahaan Bluesky menjalankan aplikasi utama dan meng-host sebagian besar data pengguna
Pada tingkat protokol memang terdesentralisasi, tetapi sistem nyatanya masih sangat tersentralisasi dari sudut pandang siapa yang memegang kendali
Bukan berarti ini pasti salah Bluesky, tetapi bukankah sejauh ini memang begitu jalannya?
Ini bukan masalah yang khas Bluesky atau ATProto; entah organisasi laba, nirlaba, atau kelompok sukarelawan, selalu ada saja yang mencari sesuatu untuk dipermasalahkan
Saya juga tidak punya konflik kepentingan dengan Bluesky selain sebagai pengguna awal, bukan investor, dan saya memahami protokol, perusahaan, serta situs webnya sejauh kemampuan saya
Situs dan aplikasinya bekerja dengan baik. Orang terlalu fokus mencari masalah alih-alih membuat solusi yang lebih besar dan lebih baik
Kebanyakan orang tidak menginginkan solusi P2P sementara seperti Lemmy atau Mastodon. Mereka ingin konten berada di satu tempat, dan ada pihak yang bisa dimintai pertanggungjawaban
Karena itu saya rasa jejaring sosial P2P tidak akan pernah menjadi arus utama. Drama di sekitar Lemmy dan Mastodon lebih banyak daripada gabungan Twitter, Reddit, Facebook, dan lainnya
Itu pendapat pribadi saya, dan pasangan serta teman-teman saya tampaknya berpikir sama
Baik dalam teori maupun praktik, ini memang terdesentralisasi
Hanya saja karena Bluesky mengoperasikan bagian terbesar, orang bisa bilang bahwa pada tingkat komunitas atau mindshare ini belum terdesentralisasi, tetapi itu juga sedang berubah
Ia hanya mengatakan “tidak ada instance”, tetapi tidak menjelaskan bagaimana arsitektur itu mengakali masalah seperti autentikasi, sinkronisasi, dan penemuan
Memilih Google Reader sebagai analogi terasa seperti pertanda buruk
RSS memang tetap bertahan setelah Google Reader ditutup, tetapi bukan berarti semua komunitas yang memakai RSS ikut bertahan, dan banyak di antaranya bahkan sekarang tidak tahu lagi apa itu RSS
Mengklaim sesuatu terdesentralisasi sambil terus menunjuk sentralisasi sosial yang besar dalam ekosistem terdesentralisasi sebagai contoh yang baik terasa hampir Freudian
Apalagi kita sudah tahu bagaimana akhirnya
Google Reader menyatukan banyak rumah RSS menjadi satu, menambahkan nilai seperti grafik sosial dan komentar, tetapi runtuh karena perubahan sikap eksekutif Google, nyaris mematikan RSS dan menghancurkan grafik sosial yang mengesankan itu
Dengan analogi seperti itu, sulit menaruh kepercayaan besar pada ATProto
Aplikasi hanya mengindeksnya
Jadi dalam analogi ini, siapa pun bisa menghidupkan kembali Google Reader atau bersaing dengannya dengan memakai grafik yang sama
Kalau penasaran, saat ini http://leaflet.pub memang benar-benar bekerja seperti itu
Bayangkan kalau Anda tidak bisa memakai pembaca RSS desktop atau mobile, dan hanya bisa membaca RSS lewat Google Reader atau layanan tiruan dengan skala serupa
Belum lama ini juga ada yang membicarakan NetNewsWire
Perbedaan pentingnya adalah blog punya situs web sendiri, dan feed RSS tidak harus selalu memuat artikel lengkap
Bluesky biasanya tidak bekerja seperti itu. Semua yang ada di PDS direplikasi
Selain itu, demi memudahkan replikasi, orang juga didorong untuk menaruh seluruh tulisan blog di PDS
Kalau begitu, siapa pun yang ingin mengindeks bisa mengambil salinannya, dan Anda tidak bisa mengendalikan apa pun yang mereka lakukan dengannya
Sebenarnya tidak wajib seperti itu. Anda bisa memposting blog di situs web sendiri dan hanya menaruh tautannya di Bluesky
Menambahkan frontend HTTP di atas akun atproto adalah pendekatan yang direkomendasikan, dan memang banyak orang melakukannya
Saya juga melakukannya di pfrazee.com, dan tulisan blog leaflet saya yang versi kanoniknya ada di atproto juga dirender di blog saya
Perbandingan dengan RSS itu menyesatkan
Aplikasi Atproto berbeda dari pembaca RSS, yang berjalan di komputer pengguna dan terhubung langsung ke sumber konten
Aplikasi Atproto adalah server yang mengontrol, memfilter, dan membentuk konten yang disajikan kepada pembaca
Aplikasi Atproto bisa melakukan sensor, shadowban, menampilkan iklan, dan mengubah feed menjadi algoritmis sesuka mereka
Pengguna tidak berdaya, dan kreator menjadi korban yang tidak bisa berbuat apa-apa selain berteriak
Fakta bahwa siapa pun bisa meng-host data di mana saja sama sekali tidak berarti jika tidak ada cara untuk mendistribusikan data itu
Pertama, Anda bisa memakai AppView lain yang tidak melakukan hal-hal seperti itu
Feed bisa dibuat algoritmis sesuai keinginan pengguna, dan jika ada banyak aplikasi, Anda tidak terikat pada algoritme yang diinginkan satu pembuat pusat