1 poin oleh GN⁺ 1 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Tangled secara bawaan mendukung fitur vouching yang memungkinkan pengguna menjamin atau mencela pengguna lain yang pernah berinteraksi dengan mereka, dan memanfaatkannya sebagai sinyal kepercayaan untuk menghadapi peningkatan kiriman berbasis LLM
  • Pengguna yang dijamin akan ditandai dengan ikon perisai hijau di samping foto profil, sedangkan pengguna yang dicela akan ditandai dengan ikon perisai merah, sebagai petunjuk untuk menilai apakah perlu berinteraksi
  • Seiring turunnya hambatan untuk mengirimkan kode ke proyek dengan alat berbasis LLM, kiriman bergaya “uncanny valley” yang tampak benar tetapi keliru secara halus dapat meningkat, dan maintainer dapat menjamin atau mencela kontributor yang menyalahgunakan alat ini hingga menambah beban pemeliharaan
  • Vouching dan kecaman mencakup kolom alasan berbasis teks dan menerapkan attenuasi, sehingga pengguna hanya dapat melihat penilaian yang dibuat oleh diri mereka sendiri dan lingkaran mereka
  • Saat menjamin atau mencela di Tangled, catatan publik akan dibuat di PDS pengguna, lalu appview mengagregasikannya dan menampilkan “topi” vouching di atas profil pada issue, komentar, pull request, dan komentar pull request

Sinyal kepercayaan di Tangled

  • Tangled secara bawaan mendukung fitur vouching yang memungkinkan pengguna menjamin atau mencela pengguna lain yang pernah berinteraksi dengan mereka
  • Pengguna yang dijamin ditandai dengan ikon perisai hijau di samping foto profil, dan pengguna yang dicela ditandai dengan ikon perisai merah
  • Pengguna juga dapat melihat penilaian jaminan dan kecaman yang dibuat oleh lingkaran mereka, dan memakainya sebagai sinyal untuk memutuskan apakah akan berinteraksi
  • Seiring turunnya hambatan untuk mengirimkan kode ke proyek dengan alat berbasis LLM, kiriman bergaya “uncanny valley” yang tampak benar tetapi keliru secara halus dapat meningkat
  • Maintainer di jaringan Tangled dapat menjamin atau mencela kontributor yang menyalahgunakan alat ini hingga menambah beban pemeliharaan

Cara kerja dan batasan desain

  • Desain yang hati-hati

    • Vouching dan kecaman mencakup kolom alasan berbasis teks
    • Attenuasi diterapkan, sehingga pengguna hanya dapat melihat penilaian yang dibuat oleh diri mereka sendiri dan lingkaran mereka
    • Saat ini, pengguna yang dicela tidak diblokir dari proyek; hanya label peringatan merah yang ditampilkan di sebagian UI
  • Fitur tambahan yang direncanakan

    • Karena maintainer dan kontributor dapat meninggalkan proyek seiring waktu, jaminan akan melemah seiring waktu dan perlu diperbarui sesekali
    • Fitur pelacakan bukti dapat ditambahkan sehingga jika pengguna dijamin tepat setelah PR digabungkan, PR tersebut akan ditambahkan sebagai bukti dalam catatan jaminan
  • Catatan publik dan lokasi tampilan

    • Jika seseorang dijamin atau dicela di Tangled, catatan publik akan dibuat di PDS pengguna
    • Catatan ini memuat apakah itu jaminan atau kecaman serta alasan opsional
    • Appview Tangled mengagregasikan data vouching di seluruh jaringan, lalu menampilkan “topi” vouching di atas profil pada titik interaksi
    • Lokasi tampilannya adalah issue, komentar issue, pull request, dan komentar pull request
  • Visibilitas berbasis lingkaran

    • “Topi” hanya ditampilkan di atas pengguna jika target tersebut dijamin/dicela langsung oleh pengguna, atau jika target tersebut dijamin/dicela oleh orang yang sebelumnya dijamin oleh pengguna
    • Dengan mengklik “topi”, pengguna dapat melihat siapa saja dalam lingkaran mereka yang menjamin atau mencela pengguna tersebut
    • Saat ini, hasil dari kecaman hanyalah tampilan “topi”; dampaknya bisa berubah di masa depan, tetapi untuk sekarang dipakai sebagai sinyal bantu penilaian

1 komentar

 
GN⁺ 1 jam lalu
Pendapat di Lobste.rs
  • Cara yang lebih baik dan sederhana adalah membuat kebijakan anti-LLM yang kuat dan menegakkannya dengan benar. Juga perlu menjauh dari platform yang mendorong penggunaan LLM atau pro-AI seperti GitHub
    Ini memang tidak 100% efektif, tetapi ketika orang mencoba menyembunyikan penggunaan LLM, biasanya tetap ketahuan, dan saat itu bisa langsung diblokir. Jika perusahaan mendorong spam LLM, blokir seluruh perusahaan, dan jika ini forge yang di-host sendiri, blokir jaringan perusahaan itu di firewall
    Sistem setengah matang seperti proof of work merugikan kontributor pertama kali dan kontributor yang hanya lewat, dan penjaminan kepercayaan pada akhirnya juga merupakan bentuk proof of work. Daripada merepotkan pihak yang lemah, lebih efektif menghantam pelaku buruk dengan cepat

    • Tujuan Tangled tampaknya lebih dekat ke menghindari spam daripada menghindari LLM itu sendiri
      Bahkan di kutipannya tertulis bahwa alat ini menjamin atau mencela kontributor yang menyalahgunakan alat ini hingga menambah beban pemeliharaan
    • Untuk itu dibutuhkan platform yang benar-benar baru, dan dampaknya pun sepertinya tidak akan besar. Banyak proyek menerima kiriman hasil LLM, dan banyak pengembang juga tidak masalah mengganti kebijakan penggunaan per proyek
      Membuat orang menerima larangan di tingkat platform hanya karena ada yang melakukan perburuan penyihir LLM akan menjadi kontraproduktif. Di sini maupun di HN, kadang terlihat kecurigaan keliru bahwa sebuah tulisan dibuat dengan LLM; kalau itu harus ditangani di PR, akan sangat melelahkan
    • Tujuan yang dinyatakan di sini bukan menghindari LLM, melainkan menghindari spam
      Sistem ini dimaksudkan untuk menghindari kontributor yang menyalahgunakan alat dan menambah beban pemeliharaan, dan juga bisa dipakai terhadap kontributor yang menambah beban pemeliharaan dengan cara lama. Ini terlihat seperti model hak commit yang lebih maju
    • Ini bukan soal kebijakan spesifik apa yang dilanggar, melainkan lebih merupakan jawaban yang dipakai ketika seseorang melanggar kebijakan
      Jika ada kebijakan anti-LLM, ini bisa dipakai untuk menegakkannya; jika ada kebijakan anti-pelecehan, itu pun bisa ditegakkan dengan ini
  • Jika tidak terhubung langsung dengan boleh tidaknya mengirim PR, ini paling bagus pun terasa tidak berguna, dan paling buruk bisa menjadi sistem moderasi yang berbahaya. Seseorang akan mencela pengguna yang pernah memakai LLM secara massal, dan setelah itu serangan kelompok karena alasan lain juga bisa dimulai
    Web of trust itu sendiri keren, tetapi proyek ini hanya membahas sisi teknis dan tidak menyentuh sisi sosial. Jika membuat sistem moderasi tanpa bagian besar yang benar-benar menanamkan ke hasil sistem pertanyaan “bagaimana ini akan diskalakan tanpa penyalahgunaan”, akan muncul kejutan

    • Penjaminan hanya menampilkan apa yang saya lakukan atau yang dilakukan oleh akun yang saya jamin, jadi celaan massal terhadap pengguna yang tidak dikenal dirancang agar tidak terlihat
    • Saya khawatir itu bisa terjadi, tetapi dalam praktiknya tampaknya kita baru akan tahu pasti setelah kasus cancel terkenal pertama meledak
    • Adanya konsep peluruhan adalah satu langkah ke arah yang benar. Saat ini pun sistem ini belum mengendalikan kebijakan secara langsung
      Ini eksperimen yang cukup menarik karena mencoba memberi motivasi sosial lebih dulu untuk menyelesaikan masalah sosial, dan desainnya juga tampak cerdas
  • Jika “pengguna yang dicela tidak menerima konsekuensi apa pun. Mereka hanya mendapat topi”, lalu sebenarnya apa artinya? Pada akhirnya penanganan PR tetap harus dilakukan seperti biasa

    • Ini titik awal untuk melihat bagaimana sistemnya berjalan, dan tampaknya nanti akan ditambahkan fitur seperti pemblokiran berdasarkan tingkat kepercayaan
    • Bisa saja ditambahkan nanti. Awalnya saya ingin menguji apa yang dikatakan @yorickpeterse, lalu setelah itu ingin memberi pengguna pilihan untuk menentukan “reaksi” terhadap pengguna yang dicela
      Misalnya, bisa dengan memblokir atau menurunkan prioritas
  • Adakah mekanisme yang mencegah orang membuat banyak domain, lalu di masing-masing membuat sejuta pengguna dan membuat mereka saling menjamin? Dengan begitu orang lain bisa membeli dariku paket reputasi yang sulit dibedakan
    Model pohon undangan milik lobste.rs justru terlihat lebih baik. Jika seseorang mulai menyalahgunakan sistem, seluruh subtree di bawahnya mudah dipotong, dan pertumbuhannya juga lebih lambat, yang justru menjadi kelebihan

    • Saya suka model human.json: https://codeberg.org/robida/human.json terutama cara visualisasinya di ekstensi. Ia mencari jalur terpendek ke situs yang dipercaya, memberi warna pada jarak, dan juga menampilkan jalurnya
      Di human.json, mungkin tidak ada yang akan menjamin node-node dari jaringan seperti itu, atau koneksi masuknya terlalu sedikit sehingga jaraknya akan terlihat besar. Bukan berarti situs itu tidak bisa dimasukkan ke jaringan, tetapi penjaminan dan ketidakpercayaan bisa cepat menyingkirkannya. Bagaimana ini benar-benar bekerja masih harus dilihat
    • Pelabelan bersifat per pengguna. Jika saya hanya menjamin orang yang tidak akan menjamin jutaan akun acak, maka aktivitas bergaya serangan Sybil sama sekali tidak memengaruhi penjaminan saya
      Akan bagus jika ada lapisan UI mirip petnames yang memungkinkan melihat “X, Y, Z menjaminnya” secara inline atau lewat mouseover
    • Akan menarik jika ada model yang memberi skor pada tingkat penjaminan yang berbeda. Dengan memanfaatkan pohon undangan ala lobste.rs, jika 100 orang menjamin tetapi semuanya punya leluhur yang sama, sedangkan 5 orang menjamin lewat jalur yang sangat berbeda, maka 5 yang terakhir itu dihitung lebih besar
      Saya penasaran seberapa jauh pendekatan seperti ini bisa mencegah “bertani reputasi”
    • Yang mungkin dilakukan hanya membuat lingkaran penjaminan mereka sendiri di antara bot. Selama bagian jaringan lain tidak mulai menjamin akun-akun bot itu, mereka tidak akan melihat keputusan dari lingkaran tersebut
      Pada akhirnya semua data bersifat publik, jadi seseorang bisa saja membuat tangled2.org dan membangun graf global, tetapi di UI memang sengaja dibuat agar penjaminan melemah di luar lingkaran sendiri
  • Idenya bagus, tetapi saya juga merasa, kenapa tidak berkomunikasi secara alami saja. Bahkan komunikasi kecil pun terasa terlalu rapi dan konsisten
    Kalau membiarkan typo tetap ada di tulisan yang diketik, itu malah memberi sidik jari yang terasa seperti manusia sungguhan

  • Saya suka ide ini. Ini mengingatkan pada tree of trust yang dipakai lobste.rs sendiri

    • Atau ada juga human.json. Di situs saya, saya malah terpikir mengganti namanya menjadi meat.json
  • Rasanya seperti kita sedang cepat-cepat mengulang trust metric research yang berlangsung hampir bersamaan dengan lahirnya open source. Saya penasaran bagaimana @raph akan melihat ini

    • Senang melihat nama yang dulu sering saya lihat. Sistem meta-moderasi tiga tingkat milik Slashdot juga layak diakui
      Memang tidak sempurna, tetapi jelas jauh lebih baik daripada tidak ada apa-apa
  • Rasanya sudah ada sekitar enam hal seperti ini, jadi kenapa tidak bergabung dengan yang sudah ada, kenapa harus membuat satu lagi?