1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Tangled, kullanıcıların etkileşim kurdukları diğer kullanıcılar için kefil olabilmesini veya onları kınayabilmesini sağlayan vouching özelliğini yerleşik olarak destekliyor ve bunu LLM tabanlı gönderilerin artışına karşı bir güven sinyali olarak kullanıyor
  • Kefil olunan kullanıcıların profil fotoğrafının yanında yeşil kalkan simgesi, kınanan kullanıcıların yanında ise kırmızı kalkan simgesi gösteriliyor; bu da onlarla etkileşime girip girmeme konusunda bir ipucu sağlıyor
  • LLM tabanlı araçlarla projelere kod gönderme eşiği düştükçe, görünüşte doğru ama ince biçimde hatalı “uncanny valley” tarzı gönderiler artabiliyor ve bakımcılar bu araçları kötüye kullanarak bakım yükü oluşturan katkıcılar için kefil olabilir veya onları kınayabilir
  • Kefalet ve kınama kayıtlarında metin tabanlı bir gerekçe alanı bulunuyor ve zayıflatma uygulanıyor; böylece kullanıcılar yalnızca kendilerinin ve kendi çevrelerinin verdiği kararları görebiliyor
  • Tangled’da birine kefil olunca veya birini kınayınca, kullanıcının PDS üzerinde herkese açık bir kayıt oluşturuluyor; appview bunu toplayıp issue, yorum, pull request ve pull request yorumlarındaki profillerin üstünde bir kefalet “şapkası” gösteriyor

Tangled’ın güven sinyalleri

  • Tangled, kullanıcıların etkileşim kurdukları diğer kullanıcılar için kefil olabilmesini veya onları kınayabilmesini sağlayan vouching özelliğini yerleşik olarak destekliyor
  • Kefil olunan kullanıcıların profil fotoğrafının yanında yeşil kalkan simgesi, kınanan kullanıcıların yanında ise kırmızı kalkan simgesi gösteriliyor
  • Kullanıcılar, kendi çevrelerinin verdiği kefalet ve kınama kararlarını da görebiliyor ve bunu etkileşime girip girmeme konusunda bir sinyal olarak kullanabiliyor
  • LLM tabanlı araçlarla projelere kod gönderme eşiği düştükçe, görünüşte doğru ama ince biçimde hatalı “uncanny valley” tarzı gönderiler artabiliyor
  • Tangled ağındaki bakımcılar, bu araçları kötüye kullanarak bakım yükü oluşturan katkıcılar için kefil olabilir veya onları kınayabilir

Nasıl çalışıyor ve tasarım kısıtları

  • Dikkatli tasarım

    • Kefalet ve kınama kayıtlarında metin tabanlı bir gerekçe alanı bulunuyor
    • Zayıflatma (attenuation) uygulanıyor; böylece kullanıcılar yalnızca kendilerinin ve kendi çevrelerinin verdiği kararları görebiliyor
    • Şu anda kınanan kullanıcılar projeden engellenmiyor; yalnızca arayüzün bazı bölümlerinde kırmızı bir uyarı etiketi gösteriliyor
  • Planlanan ek özellikler

    • Zaman içinde bakımcılar ve katkıcılar projeden ayrılabileceği için, kefalet zamanla zayıflayacak ve ara sıra yenilenmesi gerekecek
    • Bir PR birleştirildikten hemen sonra kullanıcı için kefil olunursa, ilgili PR’nin kefalet kaydına kanıt olarak eklenmesini sağlayan kanıt takibi özelliği eklenebilir
  • Herkese açık kayıtlar ve gösterim yerleri

    • Tangled’da birine kefil olunca veya birini kınayınca, kullanıcının PDS üzerinde herkese açık bir kayıt oluşturuluyor
    • Bu kayıt, bunun bir kefalet mi yoksa kınama mı olduğunu ve isteğe bağlı gerekçeyi içeriyor
    • Tangled appview, ağ genelindeki kefalet verilerini topluyor ve etkileşim noktalarındaki profillerin üstünde bir kefalet “şapkası” gösteriyor
    • Gösterim yerleri issue’lar, issue yorumları, pull request’ler ve pull request yorumları
  • Çevre tabanlı görünürlük

    • Yalnızca kullanıcının doğrudan kefil olduğu ya da kınadığı kişilerde veya kullanıcının kefil olduğu birinin daha sonra kefil olduğu ya da kınadığı kişilerde bu şapka gösteriliyor
    • Şapkaya tıklandığında, kullanıcının kendi çevresi içinde bu kişiye kimin kefil olduğu veya onu kınadığı görülebiliyor
    • Şu anda kınamanın sonucu yalnızca bu şapkanın gösterilmesi; ileride sonuçlar değişebilir, ancak şimdilik karar vermeye yardımcı olan bir sinyal olarak kullanılıyor

1 yorum

 
GN⁺ 1 시간 전
Lobste.rs görüşleri
  • Daha iyi ve daha basit yöntem, güçlü bir LLM karşıtı politika oluşturup bunu düzgün şekilde uygulamak. GitHub gibi LLM kullanımını teşvik eden veya AI yanlısı platformlardan da uzak durmak gerekir
    %100 etkili olmaz ama LLM kullanımını gizlemeye çalışanlar da çoğu zaman ortaya çıkar; o noktada hemen yasaklamak yeterlidir. Şirketler LLM spam'ini zorlarsa şirketin tamamını engelleyin; kendi barındırdığınız forge ise güvenlik duvarında o şirketin ağını kapatın
    İş ispatı gibi yarım yamalak sistemler ilk kez katkı yapanları ve yoldan geçen katkıcıları cezalandırır; güven kefaleti de sonuçta bir iş ispatıdır. Zayıf olanları hırpalamak yerine kötü aktörleri hızlıca vurmak daha etkilidir

    • Tangled'ın hedefi LLM'nin kendisinden kaçınmaktan çok spam'den kaçınmak gibi görünüyor
      Alıntıda da “bu aracı kötüye kullanarak bakım yükü yaratan katkıcıları” kefil göstermek ya da kınamak için kullanıldığı söyleniyor
    • Bunun için tamamen yeni bir platform gerekir ve etkisi de büyük olmayacak gibi. Birçok proje LLM ile gönderilen katkıları kabul ediyor ve birçok geliştirici de bunu proje bazında değiştirmenin normal olduğunu düşünüyor
      Sırf biri LLM cadı avı yapıyor diye insanları platform düzeyinde yasağı kabullenmeye zorlamak ters teper. Burada ya da HN'de de bazen bir yazının LLM ile yazıldığına dair yanlış şüpheler görüyoruz; bunu PR'lerde yönetmek zorunda kalmak gerçekten yorucu olurdu
    • Burada açıkça belirtilen hedef “LLM” değil, spam'den kaçınmak
      Bu sistem, araçları kötüye kullanıp bakım yükü oluşturan katkıcıları dışlamaya çalışıyor; eski usul yöntemlerle bakım yükü yaratan katkıcılara karşı da kullanılabilir. Daha gelişmiş bir commit yetkisi modeli gibi duruyor
    • Bu, hangi somut politikanın ihlal edildiğiyle ilgili değil; biri politikayı ihlal ettiğinde kullanılacak bir yanıt gibi
      LLM karşıtı bir politikanız varsa bununla uygulayabilirsiniz; taciz karşıtı politikanız varsa onu da bununla uygulayabilirsiniz
  • PR gönderimiyle doğrudan bağlantılı değilse bu, iyimser bakınca işe yaramaz; kötü ihtimalle ise zararlı bir moderasyon sistemi olur. Birileri geçmişte LLM kullanmış kullanıcıları topluca kınamaya başlar; sonra başka gerekçelerle de sürü halinde saldırılar gelebilir
    Web of trust fikri başlı başına güzel ama bu proje teknik yönü ele alıp toplumsal yönü ele almıyor. Bir moderasyon sistemi kurarken “bunu suistimal olmadan nasıl ölçekleriz” sorusunu sistem çıktısına işleyen büyük bir bölüm yoksa sürprizlerle karşılaşılır

    • Kefaletler yalnızca benim verdiğim ya da benim kefil olduğum hesapların verdiği kefaletler olarak göründüğünden, tanımadığınız kullanıcılara yönelik toplu kınama görünmez olacak şekilde tasarlanmış
    • Böyle bir şey olur mu diye ben de endişeliyim ama pratikte ne olacağını anlamak için ilk büyük cancel vakası patlayana kadar beklemek gerekecek gibi
    • Sönümleme kavramının eklenmiş olması doğru yönde bir adım. Şu an politikayı doğrudan kontrol etmiyor bile
      Toplumsal bir sorunu çözmek için önce toplumsal motivasyon eklenmiş bir deney olması açısından epey ilginç ve tasarımı da akıllıca görünüyor
  • “Kınanan kullanıcı için hiçbir sonuç yok. Sadece şapka alıyorlar” ise bunun anlamı ne? Sonuçta PR işleme yükü yine aynı kalıyor

    • Bu, sistemin nasıl çalıştığını görmek için bir başlangıç noktası; ileride güven seviyesi tabanlı engelleme gibi özellikler eklenir gibi duruyor
    • Sonradan eklenebilir. Başlangıçta @yorickpeterse'nin dediğini test etmek istiyorum; sonrasında da kullanıcıların kınanan kullanıcılara nasıl bir “tepki” vereceğini seçebilmesini isterim
      Örneğin engelleme ya da önceliği düşürme gibi seçenekler mümkün olabilir
  • Birden fazla alan adı açıp her birinde bir milyon kullanıcı oluşturup bunların birbirine kefil olmasını engelleyen bir mekanizma var mı? O zaman başkaları benden ayırması zor itibar paketleri satın alabilir
    Açıkçası lobste.rs'in davet ağacı modeli daha iyi görünüyor. Biri suistimale başlarsa tüm alt ağacı kesmek kolay olur ve daha yavaş büyümesi de aslında avantajdır

    • human.json modeli hoşuma gidiyor: https://codeberg.org/robida/human.json özellikle uzantıda görselleştirilme biçimi güzel. Güvendiğiniz sitelere en kısa yolu buluyor, mesafeyi renkle gösteriyor ve yolu da gösteriyor
      human.json'da muhtemelen kimse böyle bir ağdaki düğümlere kefil olmaz ya da içeri gelen bağlantı çok az olacağı için mesafe büyük çıkar. Bu, sitelerin ağa giremeyeceği anlamına gelmez ama kefalet ve güvensizlik onları hızla dışarı itebilir. Pratikte nasıl işleyeceğini görmek gerek
    • Etiketleme kullanıcıya özel. Ben milyonlarca rastgele hesaba kefil olmayacak kişilere kefil oluyorsam, Sybil saldırısı tarzı faaliyetler benim kefaletlerimi hiç etkilemez
      “X, Y, Z kefil oldu” bilgisini satır içinde ya da mouseover ile gösteren, petnames benzeri bir UI katmanı güzel olurdu
    • Farklı kefalet derecelerini puanlayan bir model ilginç olabilir. lobste.rs tarzı davet ağacı kullanılıp, 100 kişinin kefil olduğu ama hepsinin aynı atayı paylaştığı bir durum ile 5 kişinin çok farklı yollardan kefil olduğu bir durum karşılaştırıldığında, ikinci durumdaki 5 kefaleti daha ağır saymak gibi
      Bunun “itibar çiftçiliğini” ne kadar önleyebileceğini merak ediyorum
    • Muhtemelen ancak botların kendi aralarında kefalet çemberleri kurmasına yol açar. Ağın geri kalanı bu bot hesaplara kefil olmaya başlamadıkça, o çemberin kararlarını göremez
      Sonuçta tüm veriler açık; biri tangled2.org kurup küresel bir grafik de oluşturabilir. Ama UI tasarımı, kişinin kendi çemberinin dışına çıkıldıkça kefaletin bilinçli olarak zayıflaması üzerine kurulu
  • Fikir güzel ama belki de sadece doğal biçimde iletişim kurmak yeterlidir. En ufak iletişim bile fazla derli toplu ve tutarlı
    Yazarken birkaç yazım hatası bırakmak gerçek insana özgü bir parmak izi oluşturur

  • Bu fikir hoşuma gitti. lobste.rs'in kendi kullandığı tree of trust modelini hatırlatıyor

    • Ya da human.json var. Kendi sitemde adını meat.json olarak değiştirmeyi düşünüyorum
  • Açık kaynağın doğuşuyla neredeyse aynı dönemde yürütülen trust metric research çalışmalarını hızla yeniden yapıyor gibiyiz. @raph buna nasıl bakar merak ediyorum

    • Eski günlerden tanıdık bir isim görmek güzel. Slashdot'un üç katmanlı meta moderasyon sistemi de takdiri hak ediyor
      Kusursuz değildi ama hiçbir şey olmamasından kesinlikle çok daha iyiydi
  • Sanki bundan zaten altı tane var gibi; neden mevcut olanlardan birine katılmak yerine bir tane daha yapılıyor?