Cara Kerja Bluesky

• BlueSky adalah aplikasi mikroblogging yang mirip dengan Twitter·Mastodon, tetapi tujuan yang lebih besarnya adalah memverifikasi apakah aplikasi sosial terdistribusi berskala besar dimungkinkan di atas AT Protocol (atproto)
• atproto bukan blockchain·DAO·NFT, melainkan protokol federatif yang menggunakan kriptografi dan Merkle tree sehingga catatan yang ditandatangani pengguna diproses secara terbagi oleh PDS, Relay, dan App View
• Skalabilitas berasal dari struktur di mana Personal Data Server (PDS) milik pengguna tidak mengirim posting langsung ke semua pengikut, melainkan Relay mengumpulkan data jaringan dan menyediakannya sebagai firehose
• Moderasi dibagi dengan model “speech vs reach”, memisahkan replikasi konten dan kontrol paparan sehingga labeler, feed generator, dan App View menerapkan pemfilteran serta pemblokiran
• DID yang stabil dan handle berbasis domain memberikan portabilitas akun, tetapi layanan resolusi did:plc yang dioperasikan BlueSky masih menjadi titik perdebatan soal sentralisasi

---

Hubungan BlueSky dan atproto

• BlueSky saat ini berfungsi sebagai aplikasi mikroblogging, tetapi dalam rancangan keseluruhan ia adalah aplikasi awal yang membuktikan kemungkinan Authenticated Transfer Protocol, yaitu atproto
• Situs web BlueSky menyatakan bahwa “media sosial terlalu penting untuk dikendalikan oleh segelintir perusahaan, dan kami sedang membangun fondasi terbuka bagi internet sosial tempat semua orang bisa membentuk masa depan”
• Karena BlueSky adalah sebuah perusahaan, bisa muncul pandangan skeptis bahwa “sesuatu yang tidak seharusnya dikendalikan perusahaan justru dibuat oleh perusahaan”, tetapi inti desainnya ada pada atproto, bukan aplikasinya
• atproto adalah protokol federatif untuk aplikasi sosial terdistribusi berskala besar

Protokol terdistribusi, bukan kripto

• atproto bisa tampak seperti mata uang kripto karena memakai istilah “jaringan terdistribusi” dan “protokol”, tetapi ini bukan mata uang kripto
• Ini bukan blockchain, DAO, atau NFT, dan hanya memakai sebagian teknologi seperti kriptografi dan Merkle tree

Struktur dasar atproto

• atproto memilih struktur federatif di mana banyak pihak mengoperasikan bagian-bagian berbeda dari sistem dan saling berkomunikasi
• Dengan mempertimbangkan basis pengguna berskala besar, desainnya dibuat agar pihak yang mampu menanggung beban mengambil lebih banyak peran, sementara beban pihak yang tidak mampu dikurangi
• BlueSky telah melampaui 5 juta pengguna pada minggu saat tulisan ini dibuat, dan dinilai jauh lebih stabil dibanding Twitter awal
• Saat ini atproto berbasis 100% terbuka, dan tidak memiliki fitur seperti pesan privat
  • Karena sulit mengimplementasikan fitur privat dengan baik dalam sistem federatif, dipilih untuk membangun dengan benar daripada merilis fitur yang memiliki kelemahan serius
  • Untuk sekarang, ia cocok dipakai hanya untuk hal-hal yang aman jika bersifat publik

Record, repository, App View, Relay

• Pengguna membuat record yang ditandatangani secara kriptografis, dan tanda tangan ini membuktikan siapa penulisnya
• Record mengikuti skema bernama Lexicon
• Record disimpan di repository, dan repositori ini berjalan sebagai layanan yang mengekspos HTTP dan WebSocket
  • Layanan seperti ini biasanya disebut PDS (Personal Data Server)
  • Pengguna dapat menjalankan PDS sendiri, atau memakai PDS yang di-host oleh orang lain
• Aplikasi membaca record yang tersimpan di jaringan dan membangun fitur di atasnya
  • Layanan seperti ini disebut App View karena menampilkan sudut pandang tertentu atas informasi
  • Membangun aplikasi berarti mendefinisikan Lexicon, membaca record yang memakai Lexicon itu, dan mengabaikan sisanya
• Cara PDS saling memberi notifikasi secara langsung memiliki masalah skalabilitas besar
  • Jika setiap posting baru harus dikirim langsung ke repository semua pengikut, hal itu tidak efisien dan biaya pengoperasian repository populer menjadi tinggi
• Relay mengurangi masalah ini dengan mengumpulkan informasi jaringan dan mengeksposnya sebagai firehose
  • App View yang sebenarnya melihat Relay, bukan langsung melihat repository
  • Saat penerbit mengunggah tulisan, repository memberi tahu Relay, dan pengikut melihat hasil keluaran Relay yang telah difilter oleh App View
  • Relay bisa besar dan mahal dioperasikan, tetapi masih mungkin dibayangkan Relay yang lebih kecil yang hanya menyebarkan subset pengguna tertentu

Model moderasi “speech vs reach”

• Karena atproto adalah protokol untuk aplikasi sosial, ia mempertimbangkan bukan hanya cara menghubungkan orang, tetapi juga cara memutuskan hubungan
• Model moderasi BlueSky dibagi menjadi speech vs reach
  • Lapisan speech bertugas mereplikasi konten ke jaringan tanpa memandang maknanya
  • Lapisan reach menyediakan alat untuk membatasi jangkauan hal-hal yang tidak ingin dilihat pengguna
• Mengatakan bahwa BlueSky “tidak melakukan moderasi” atau “hanya mementingkan kebebasan berbicara” itu tidak akurat
  • Alat moderasi sudah ada di dalam protokol itu sendiri, dan dapat bekerja juga pada konten aplikasi selain BlueSky
  • Pengguna tidak harus tunduk pada pilihan moderasi orang lain atau ketiadaan moderasi, dan dapat memilih moderatornya sendiri

Feed generator

• Di atproto, feed dipisahkan menjadi layanan tersendiri bernama feed generator
• feed generator menerima firehose yang dibuat Relay, lalu memfilter dan mengurutkan konten menurut kriteria yang diinginkan untuk ditampilkan sebagai daftar
• Pengguna dapat membagikan feed yang mereka buat kepada pengguna lain
• Contoh feed:
  • Quiet Posters: menampilkan posting dari orang yang jarang menulis
  • the ‘Gram: hanya menampilkan posting yang menyertakan foto
  • My Bangers: menampilkan posting populer milik sendiri
• Salah satu kekuatan BlueSky adalah pengguna dapat membuat feed algoritmik mereka sendiri dan membagikannya dengan mudah
• Feed adalah fitur yang ditambahkan relatif baru ke atproto, jadi mungkin belum sepenuhnya matang dan bisa berubah di masa depan

Labeler dan moderasi tingkat jaringan

• Labeler adalah layanan yang menempelkan label pada konten atau akun
• Pengguna dapat berlangganan labeler tertentu, dan membuat pengalaman mereka berbeda tergantung label pada posting
• labeler dapat bekerja dengan cara yang diinginkan operatornya
  • Dapat menjalankan algoritme otomatis pada posting
  • Dapat memakai persetujuan atau penolakan manual oleh manusia
  • Dapat dipakai sebagai daftar blokir atau filter NSFW
• Fitur label memang ada, tetapi pada saat tulisan ini dibuat belum jelas apakah pengguna bisa menjalankan labeler sendiri
  • BlueSky mengoperasikan labeler miliknya sendiri
  • Belum ada rilis eksternal yang diketahui
• Dengan menggabungkan feed, App View, dan labeler, pengguna dapat memilih pengalaman moderasi di dalam maupun di luar aplikasi
  • Di satu feed hanya melihat SFW, sementara di tempat lain mengizinkan konten NSFW
  • Dapat membuat dan membagikan daftar blokir
• Karena alat moderasi bekerja pada tingkat protokol, bukan tingkat aplikasi, labeler yang sama dapat dipakai juga oleh aplikasi lain di atas atproto
  • Jika dibuat klon Instagram di atas atproto, labeler daftar blokir yang sama bisa dipakai
  • Pengguna yang diblokir di satu tempat bisa, jika diinginkan, diblokir di semua tempat

Perbedaan dengan model instance ala Mastodon

• Model atproto berbeda dari cara Mastodon yang menempatkan “akun” pada “instance” tertentu
• Pertanyaan seperti “apa yang terjadi jika instance saya di-defederate” sulit diterapkan begitu saja
• Tujuan serupa masih bisa dicapai, misalnya dengan tidak menyukai posting dari PDS tertentu lalu mengabaikannya
• Namun keputusan itu bukan ditentukan pemilik server atas nama akun pengguna, melainkan pilihan pengguna sendiri

DID, handle, dan portabilitas akun

• Inti identitas di atproto adalah DID (Decentralized Identifier)
  • Contoh DID berbentuk did:plc:3danwc67lo7obz2fmdg6jxcr
• Pada identitas yang benar-benar dilihat pengguna, handle dipakai bersama DID, dan handle adalah nama domain
  • Contoh: @steveklabnik.com
  • Pendaftar BlueSky bisa mendapatkan handle berbentuk @username.bsky.social
• Karena DID stabil, saat handle diubah dari @steveklabnik.bsky.social menjadi @steveklabnik.com, tidak terjadi gangguan bagi pengikut dan hanya handle di UI yang berubah
• Untuk memakai domain sebagai handle, ambil DID yang dibuat PDS lalu tambahkan TXT record ke DNS domain tersebut
• Pengguna yang tidak memahami DNS pun dapat mendaftarkan domain dan menjadikannya handle tanpa pengetahuan teknis melalui kemitraan BlueSky dengan NameCheap
• Portabilitas akun didasarkan pada DID dan tanda tangan kriptografis
  • Konten yang dibuat oleh orang yang memakai DID tertentu ditandatangani dan direplikasi ke jaringan
  • Untuk “menutup” sebuah akun, penggunaan kunci yang dimiliki pengguna harus dipaksa berhenti, tetapi dalam desain jaringan pihak lain tidak memiliki akses ke kunci tersebut
  • Meski PDS mati, isi dapat di-backfill dari jaringan dan perpindahan ke PDS baru bisa diumumkan

Isu did:web dan did:plc

• BlueSky mendukung dua jenis DID
  • did:web: metode berbasis nama domain
  • did:plc: metode khusus yang diimplementasikan BlueSky
• plc dalam did:plc berarti “placeholder”, dan BlueSky berencana terus mendukungnya
• did:plc memiliki kelemahan karena informasi yang benar harus diresolusikan melalui layanan yang dioperasikan BlueSky
  • Contoh lookup dapat dilihat di plc.directory
  • Karena struktur ini, ada kritik bahwa BlueSky dapat melakukan ban terhadap pengguna lebih kuat daripada yang semestinya dimungkinkan oleh desain jaringan
• Ada juga alasan mengapa masalah ini tidak dianggap fatal
  • Jika tidak menginginkannya, pengguna bisa memakai did:web
  • Sistem ini dirancang agar bisa berpindah jika muncul sistem yang lebih baik
  • Di masa depan, tata kelola did:plc mungkin dipindahkan ke model konsensus
  • Pihak lain juga dapat mengoperasikan layanan did:plc dan memakainya

Cara BlueSky berjalan di atas atproto

• BlueSky adalah aplikasi yang dibangun di atas jaringan atproto
• BlueSky mengoperasikan App View dan aplikasi web yang menggunakannya
• BlueSky juga mengoperasikan PDS untuk pengguna yang mendaftar lewat web app, serta Relay yang digunakan PDS-PDS itu untuk berkomunikasi
• BlueSky menerbitkan dua jenis Lexicon
  • com.atproto.*: operasi tingkat rendah yang dibutuhkan aplikasi mana pun di jaringan
  • app.bsky.*: operasi yang dikhususkan untuk BlueSky
• Tujuan produk BlueSky adalah agar pengguna bisa memakainya tanpa perlu tahu detail teknis ini
  • Karena tidak ada instance, tidak ada alur memilih instance untuk membuat akun
  • Jika host mati, pengguna dapat pindah, dan pengikut tidak perlu menyadarinya

Membuat aplikasi baru di atas atproto

• Aplikasi atproto dimulai dari membuat Lexicon
• Setelah itu, aplikasi mengoperasikan App View yang memproses data jaringan yang terkait dengan Lexicon tersebut
• Aplikasi harus memungkinkan pengguna menulis data ke PDS mereka sendiri dengan memakai Lexicon itu

Pemisahan inti dalam desain

• Pemisahan peran antara atproto dan BlueSky adalah elemen desain yang penting
• “Killer app” seperti BlueSky memberi alasan bagi orang untuk menggunakan jaringan tersebut
• BlueSky sendiri juga berperan sebagai bentuk dogfooding untuk memverifikasi apakah benar aplikasi nyata dapat dibangun di atas atproto

[GN⁺]

Opini Hacker News

• Sepertinya dirancang dengan sangat baik, dan tampaknya mengatasi sebagian masalah besar ActivityPub
  Dulu saya tidak tertarik pada Bluesky, tetapi sekarang jadi terpikir untuk membuat akun

  • Masalah utama Bluesky dan AT Protocol bukanlah keunggulan teknisnya, melainkan sikap NIH (Not invented here) yang kuat
    Alih-alih memakai protokol yang sudah ada seperti user@host dan WebFinger yang digunakan semua orang, mereka memilih “memakai domain sebagai identitas”, dan tidak mengacu pada cara yang sudah ditangani ACME untuk sertifikat, sehingga sempat terjadi seseorang mengambil domain s3.amazon.com di Bluesky https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
    Mereka juga membuat protokol remote call baru bernama XRPC, dan memakai skema data berbasis code generation bernama Lexicon yang kelebihannya tidak jelas selain lebih baru daripada protobuf atau jsonld
    Sulit mempercayai sebuah “jaringan terbuka” yang terus menunjukkan sikap tidak mau menghormati atau berdialog dengan ekosistem lain, dan saya juga curiga berapa banyak kesalahan umum dalam desain yang masuk karena menolak pengetahuan bersama
  • AT Protocol tampak lebih baik secara teknis, tetapi secara sosial terlihat seperti struktur yang mudah gagal
    Karena tidak ada insentif sosial bagi seseorang untuk memasang dan memelihara relay serta layanan moderasi yang terpisah dari komunitas nyata, yang tersisa hanya insentif finansial seperti layanan berbayar, penyisipan iklan, penambangan data, dan manipulasi informasi
    Jika distribusi data dan moderasi tersentralisasi, biaya hosting maupun biaya manusia menjadi bisnis besar, dan arahnya praktis menghalangi pihak selain Bluesky untuk menjalankan relay atau layanan moderasi sendiri
    Terlepas dari kekurangan ActivityPub, pendekatan seperti “komunitas berpintu gerbang” membuat pengguna merasa menjadi bagian dari server, dan membuat operator serta moderator bangga karena menyediakan layanan bagi pengguna
    AT Protocol secara teknis mengizinkan banyak relay dan layanan moderasi, tetapi patut dipertanyakan berapa banyak yang benar-benar akan muncul di dunia nyata
    Menilai protokol jejaring sosial hanya dari sudut pandang teknis dan adversarial murni adalah kesalahan menurut saya. Sebagai gantinya tidak terikat pada server, pengguna juga terpisah dari komunitas yang erat, dan tidak ada lagi yang dipertaruhkan
    Tidak punya sesuatu yang bisa hilang dari sisi data, identitas, dan komunitas adalah pedang bermata dua

• Setahu saya saat ini hanya ada satu relay
  Jika muncul banyak relay, masing-masing akan melihat jaringan secara berbeda, dan relay yang memuat lebih banyak posting akan menjadi relay yang lebih baik
  Mungkin cukup sulit memastikan keberagaman relay alih-alih satu relay dominan, mirip dengan sistem DNS alternatif yang berusaha mendapatkan traction. Kalau begitu, jika posting saya tidak tertangkap oleh relay dominan, tampaknya tidak ada jalan lain
  Ini masih tahap sangat awal, jadi mungkin saja tidak menjadi seperti itu, dan meskipun ada relay dominan, GitHub juga tidak seburuk itu, serta ada alternatifnya

  • Dulu Bluesky terasa cukup membingungkan bagi saya, tetapi belakangan saya sadar bahwa kebingungan itu terutama karena terminologi
    Jika sistemnya disebut [mikroblog] -> [pengindeks] -> [klien], akan jauh lebih mudah dipahami
    Sebenarnya ada lebih banyak elemen, tetapi cara kerja dasar Bluesky kira-kira seperti ini, hanya penamaannya terasa tidak sesuai ekspektasi
    Alasan pengindeks diperlukan adalah karena ID pengguna tidak dipertahankan secara statis di sistem. DID:PLC awalnya dimulai sebagai substring dari hash, lalu karena “rotasi kunci”, seiring waktu terjadi penataan ulang kriptografis yang aneh sehingga ID pengguna berubah bahkan tanpa disadari pengguna itu sendiri
    Bayangkan sistem seperti LiveJournal, tetapi handle terus berubah, dan dibutuhkan otoritas untuk melacak perubahan itu. Tentu saja hanya bisa memposting pesan pendek, tanpa dukungan judul atau Markdown
    Secara pribadi saya menunggu DID:PLC baru yang menerima public key statis dan menandatangani pesan dengan private key. Hal yang perlu dilacak akan jauh berkurang, dan self-hosting serta pengembangan local-first tampaknya akan jauh lebih mudah
  • Jika diperlukan, saya rasa App View sebagai klien bisa menggunakan beberapa relay secara paralel
    Strukturnya seperti UI GitHub lokal yang mengambil data dari beberapa instance GitHub yang meng-host kumpulan repositori berbeda tetapi mungkin saling tumpang tindih
    Ini juga mirip dengan klien Usenet yang mengumpulkan dan menampilkan newsgroup dari beberapa server NNTP
  • Saya memperkirakan semua relay akan memiliki seluruh data, kecuali perbedaan penilaian terhadap konten ilegal
    Saya penasaran mengapa Anda berpikir setiap relay akan melihat jaringan secara berbeda

• Yang membuat saya penasaran adalah bagaimana BlueSky bisa berjanji secara tepercaya bahwa mereka akan hanya menggunakan bagian protokol yang terbuka
  BlueSky pada dasarnya terlihat cukup tersentralisasi, jadi tampaknya tidak ada alasan teknis mengapa klien pihak pertama harus selalu menjadi klien ATProto
  Dalam jangka pendek atau menengah, melakukan itu memang akan menjadi pengkhianatan besar terhadap kepercayaan pengguna, tetapi struktur ActivityPub yang pada praktiknya terdistribusi tampak seperti pengaman yang lebih kuat di sini

  • Saya tidak tahu apa yang dimaksud dengan klien BlueSky pihak pertama
    Jika maksudnya relay pihak pertama dan PDS bisa berkomunikasi dengan protokol lain, saya tidak terlalu paham apa yang dikhawatirkan
    Dua klien ActivityPub pun bisa saling berbicara dengan protokol yang bukan ActivityPub
  • Karena semua kodenya open source, itu bisa dipercaya
    Mereka memang benar-benar melakukannya, dan jika mulai mengubah arah menjadi tidak melakukannya, orang-orang akan menyadarinya dengan sangat cepat

• Pembagian antara “ujaran dan jangkauan” sudah bagus, tetapi dalam jangka panjang, karena kesederhanaannya, Mastodon terasa seperti pilihan yang lebih cerdas
  Dalam jangka pendek, kurasi feed di Mastodon memang jelas lebih sulit, jadi bisa saja kurang menyenangkan atau kurang berguna
  Pertanyaan intinya adalah: jika ada pelaku jahat hipotetis, mungkin kaya atau berkuasa, ingin mengguncang keadaan di sini, bagaimana ia bisa melakukannya?
  Tulisan itu melewati bagian ini terlalu sepintas dengan mengatakan semacam “tidak begitu tahu bagaimana feed bekerja”, sehingga sangat mencurigakan. Mereka tampaknya tahu betul bagaimana feed akan bekerja, dan juga tahu bahwa di titik itulah ada kekuasaan dan uang, sehingga ingin mempertahankannya

  • Ringkasan “tidak begitu tahu bagaimana feed bekerja” tampaknya tidak tepat
    Penulis mengatakan begini: “Feed adalah fitur yang baru-baru ini ditambahkan ke atproto, jadi meski sudah ada, fiturnya mungkin belum lengkap dan bisa berubah ke depannya. Mari kita lihat. Dari sudut pandang saya, ini bekerja dengan baik, tetapi saya tidak mengikuti sampai detail teknis tingkat rendahnya.”
    Tepat di paragraf sebelumnya juga ada konteks seperti ini: “Salah satu killer feature BlueSky dibanding alat mikroblog lain adalah pilihan pengguna yang penuh. Kalau saya ingin membuat algoritme feed sendiri, saya bisa membuatnya, dan bisa dengan mudah membagikannya kepada orang lain.”
  • Saya tidak tahu bagian mana yang berarti mereka tidak tahu cara kerja feed
    Feed bersifat open source, sudah ada sekarang, dan bisa dijalankan sendiri
    Tidak jelas juga “mengguncang keadaan” itu keadaan yang mana dan dalam arti apa. Ada banyak bagian bergerak di sini

• Ide bahwa pengguna memilih penyedia moderasi yang independen dari penyedia hosting terlihat bagus, karena berarti mereka tidak perlu terlalu khawatir soal memilih instance
  Namun instance sepertinya tetap harus melakukan moderasi agar tidak meng-host konten yang ilegal secara lokal
  Pada akhirnya ini menjadi hal yang cukup sulit bagi orang-orang yang menjalankan instance, dan bisa menimbulkan kekacauan besar. Mungkin saya salah paham

  • Orang yang meng-host konten harus menangani konsekuensi hukum dari konten yang mereka host, dan pada akhirnya itu tidak bisa dihindari
    Namun apa pun protokol yang dipakai, ini tetap sama
  • Anda tidak salah paham. Menurut saya desentralisasi Bluesky nyaris palsu
    PDS bisa berjalan di mesin Ubuntu biasa, tetapi bahkan tulisan ini mengakui bahwa relay mahal dan merupakan titik kendali terpusat yang sangat besar
    Apa rencana Bluesky untuk menangani spam? Mungkin dengan memblokirnya di relay
    Server DID juga merupakan titik kendali terpusat lainnya
    Meski begitu, PDS tetap bisa Anda jalankan sesuka hati

• Trivia menarik tentang Bluesky: jika dikaitkan dengan tulisan beberapa waktu lalu, ini juga bisa dibilang diambil dari nama seseorang
  Nama CEO-nya dalam bahasa Mandarin secara harfiah berarti blue sky

  • Lucunya, Twitter sudah menamai proyek ini bluesky sebelum saya bergabung
    Itu kebetulan. Namun nama tengah saya dalam bahasa Mandarin berarti bluesky

• Komik pendek ini juga bagus: https://bsky.social/about/welcome-to-bluesky-comic

• Jika Bluesky menghentikan dukungan did:plc, apakah semua identitas PLC yang ada akan rusak?
  Saya penasaran karena PLC strukturnya melakukan ping ke layanan mereka

  • https://plc.directory bisa di-mirror, dan jika hal seperti itu terjadi, mirror baru bisa menjadi server otoritatif

• Saya skeptis terhadap labeler pihak ketiga
  Bagaimana penyalahgunaannya bisa dicegah?

  • Pengguna memilih labeler pihak ketiga mana yang akan mereka langgani
    Jika layanan labeler mulai menyalahgunakan posisinya, pengguna tinggal berhenti menggunakannya
    Penjelasan lebih rinci tentang bagaimana Bluesky ingin memasukkan labeler ke dalam ekosistem ada di https://github.com/bluesky-social/proposals/tree/main/0002-l...
  • Jawabannya bergantung pada jenis penyalahgunaan apa yang Anda maksud
    Saya bisa memberikan pandangan, tetapi pertanyaannya terlalu luas sehingga saya tidak tahu harus mulai menjawab dari mana
  • Kami akan segera memublikasikan jauh lebih banyak hal tentang moderasi, tetapi dasar dari labeler adalah seperti ini
    Siapa pun di dalam jaringan bisa memberi label pada apa pun, termasuk labeler lain
    Aplikasi bisa menampilkan labeler yang dapat dilanggan pengguna, seperti feed kustom Bluesky saat ini
    Aplikasi juga bisa mengkurasi bagaimana labeler ditampilkan dan diberi peringkat, sebagaimana saat ini mereka menampilkan dan memeringkat feed kustom berdasarkan popularitas yang diekspresikan lewat suka dan simpan

• Pendekatan bahwa “alat moderasi berada di lapisan jangkauan. Ia mengambil semua ujaran, tetapi menyediakan cara untuk membatasi jangkauan hal-hal yang tidak ingin saya lihat” pada akhirnya terlihat seperti moderasi ala “kalau tidak mau melihat, tutup saja mata”
  Saya tahu ini filosofi yang disukai di Silicon Valley, tetapi menurut saya secara mendasar cacat
  Ada situasi yang sah ketika orang lain yang tidak terkait perlu dicegah untuk membicarakan persoalan tertentu atau memperoleh konten tertentu
  Contoh klasiknya adalah perundungan siber, doxing, dan revenge porn. Misalnya dua orang atau lebih membicarakan cara menyakiti pihak ketiga, atau memublikasikan informasi yang pribadi, menghina, atau palsu
  Menghapus informasi ini dari feed korban sama sekali tidak berguna, dan sejak awal kemungkinan besar informasi itu tidak akan muncul di feed korban. Kerugiannya muncul karena orang lain melihat konten itu atau ikut dalam diskusinya, tetapi kerugian itu nyata
  Dalam sistem moderasi tradisional, moderator bisa menghentikan perilaku ini dengan menghapus postingan untuk semua orang atau memblokir pelaku. Dalam sistem yang “hanya menyembunyikan konten”, hal ini tidak mungkin dilakukan
  Daftar blokir bersama atau “label” juga tidak berfungsi. Konsumen konten tidak punya insentif untuk memblokirnya; justru mereka ingin melihat revenge porn
  Yang ingin memblokir adalah korban, tetapi korban tidak punya kuasa untuk memaksa semua orang memakai daftar blokir tertentu. Karena inti sistem ini adalah tidak seorang pun bisa memaksakan daftar blokir kepada orang lain

  • Akan ada lebih banyak hal yang muncul di area ini ke depannya. Tulisan ini berfokus pada kasus normal dan tidak membahas kasus buruk
    Tim telah meninjau masalah-masalah ini dan “juga berkonsultasi dengan para ahli”, tetapi karena ini masih pekerjaan yang sedang berjalan, saya tidak merasa berwenang untuk membicarakannya
    Bagian bahwa “label tidak berfungsi karena orang-orang ingin melihatnya, bukan mencegahnya” termasuk dalam ruang masalah yang secara eksplisit diakui oleh tim
    Tambahan, lihat ini: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei