BlueSky nasıl çalışır?

 (steveklabnik.com)
2 puan yazan GN⁺ 2024-02-26 | 1 yorum | WhatsApp'ta paylaş
  • BlueSky, Twitter ve Mastodon’a benzeyen bir mikroblog uygulamasıdır; ancak daha büyük amacı, AT Protocol(atproto) üzerinde büyük ölçekli dağıtık sosyal uygulamaların mümkün olup olmadığını doğrulamaktır
  • atproto; blockchain, DAO veya NFT değil, kriptografi ve Merkle tree gibi tekniklerden yararlanarak kullanıcıların imzaladığı kayıtları PDS, Relay ve App View arasında paylaştıran federe bir protokoldür
  • Ölçeklenebilirlik, kullanıcının Personal Data Server(PDS) sunucusunun gönderileri tüm takipçilere doğrudan göndermemesi; bunun yerine Relay’in ağ verilerini toplayıp firehose olarak sunması yapısından gelir
  • Moderasyon “speech vs reach” modeliyle ikiye ayrılır; içerik çoğaltma ile görünürlük kontrolünü ayırarak labeler, feed generator ve App View filtreleme ve engellemeyi uygular
  • Kararlı DID ve alan adı tabanlı handle, hesap taşınabilirliği sağlar; ancak BlueSky’nin işlettiği did:plc çözümleme servisi merkeziyetçilik tartışması olarak kalır

BlueSky ile atproto arasındaki ilişki

  • BlueSky şu anda bir mikroblog uygulaması olarak çalışıyor; ancak genel tasarımda Authenticated Transfer Protocol, yani atproto’nun olanaklarını kanıtlayan ilk uygulamadır
  • BlueSky web sitesi, “sosyal medyanın birkaç şirketin kontrol etmesi için fazla önemli olduğunu ve herkesin geleceği inşa edebileceği sosyal internet için açık bir temel oluşturduklarını” belirtir
  • BlueSky bir şirket olduğu için “şirketlerin kontrol etmemesi gereken bir şeyi bir şirket inşa ediyor” şeklinde şüpheci bir bakış olabilir; ancak tasarımın özü uygulamadan çok atproto’dadır
  • atproto, büyük ölçekli dağıtık sosyal uygulamalar için federe bir protokoldür

Kripto para değil, dağıtık protokol

  • atproto, “dağıtık ağ” ve “protokol” ifadeleri nedeniyle kripto para gibi görünebilir; ancak kripto para değildir
  • Blockchain, DAO veya NFT değildir; yalnızca bazı kriptografi ve Merkle tree gibi teknikleri kullanır

atproto’nun temel yapısı

  • atproto, birden çok aktörün sistemin farklı parçalarını işlettiği ve birbirleriyle iletişim kurduğu federe bir yapı benimser
  • Büyük ölçekli bir kullanıcı tabanı düşünülerek, yükü kaldırabilecek aktörlere daha fazla rol verip bunu yapamayan aktörlerin yükünü azaltacak şekilde tasarlanmıştır
  • BlueSky, yazının yazıldığı hafta itibarıyla 5 milyon kullanıcıyı aşmıştı ve erken dönem Twitter’dan çok daha kararlı olduğu değerlendiriliyordu
  • Mevcut atproto %100 açık temellidir; özel mesajlar gibi özellikler yoktur
    • Federe bir sistemde özel özellikleri doğru şekilde uygulamak zor olduğundan, ciddi kusurları olan bir özellik yayımlamak yerine doğru uygulamayı tercih etmişlerdir
    • Şimdilik yalnızca herkese açık olması sorun olmayan içerikler için kullanılması uygundur

Record, repository, App View, Relay

  • Kullanıcı, kriptografik olarak imzalanmış bir record oluşturur ve bu imza yazarın kimliğini kanıtlar
  • record, Lexicon adlı bir şemayı izler
  • record, repository içinde saklanır; bu depolama alanı HTTP ve WebSocket sunan bir servis olarak çalışır
    • Bu tür servisler genellikle PDS(Personal Data Server) olarak adlandırılır
    • Kullanıcı kendi PDS’ini çalıştırabilir veya başkasının barındırdığı bir PDS’i kullanabilir
  • Uygulamalar, ağda saklanan record’ları okur ve bunların üzerinde özellikler oluşturur
    • Bu tür servisler belirli bir bilgi görünümü sunduğu için App View olarak adlandırılır
    • Uygulama yapmak; bir Lexicon tanımlamak, o Lexicon’u kullanan record’ları okumak ve geri kalanını yok saymak anlamına gelir
  • PDS’lerin birbirine doğrudan bildirim göndermesi ciddi ölçeklenebilirlik sorunları doğurur
    • Her yeni gönderi yayınlandığında tüm takipçilerin repository’lerine doğrudan gönderilmesi gerekseydi bu verimsiz olurdu ve popüler repository’lerin işletme maliyeti artardı
  • Relay, bu sorunu azaltmak için ağ bilgisini toplayıp firehose olarak sunar
    • Gerçek App View, repository’ye doğrudan bakmak yerine Relay’e bakar
    • Yayıncı bir gönderi paylaştığında repository Relay’e haber verir; takipçiler ise App View’ın Relay çıktısını filtrelemesiyle oluşan sonucu görür
    • Relay büyük ve işletme maliyeti yüksek olabilir; ancak yalnızca belirli bir kullanıcı alt kümesini yayan daha küçük Relay’ler de düşünülebilir

“Speech vs reach” moderasyon modeli

  • atproto sosyal uygulamalar için bir protokol olduğundan, insanları bağlama biçimini olduğu kadar bağları koparma biçimini de dikkate alır
  • BlueSky’nin moderasyon modeli speech vs reach olarak ikiye ayrılır
    • speech katmanı, içeriği anlamından bağımsız olarak ağda çoğaltma rolünü üstlenir
    • reach katmanı, kullanıcının görmek istemediği şeylerin erişimini sınırlayan araçlar sağlar
  • BlueSky’nin “moderasyon yapmadığı” veya “yalnızca ifade özgürlüğünü önemsediği” söylemi doğru değildir
    • Moderasyon araçları protokolün kendisine dahildir ve BlueSky dışındaki uygulamaların içeriklerinde de çalışabilir
    • Kullanıcı, başkalarının moderasyon tercihlerine veya moderasyon eksikliğine bağlı kalmadan kendi moderatörünü seçebilir

Feed generator

  • atproto’da feed, ayrı bir servis olan feed generator olarak ayrılır
  • feed generator, Relay’in oluşturduğu firehose’u alır; içeriği istenen ölçütlere göre filtreleyip sıralayarak bir liste gösterir
  • Kullanıcı, oluşturduğu feed’i diğer kullanıcılarla paylaşabilir
  • Örnek feed’ler:
    • Quiet Posters: sık gönderi paylaşmayan kişilerin gönderilerini gösterir
    • the ‘Gram: yalnızca fotoğraf eklenmiş gönderileri gösterir
    • My Bangers: kişinin kendi popüler gönderilerini gösterir
  • BlueSky’nin güçlü yanlarından biri, kullanıcıların kendilerine ait algoritmik feed’ler oluşturup kolayca paylaşabilmesidir
  • Feed, atproto’ya nispeten yakın zamanda eklenen bir özellik olduğundan henüz tam olgunlaşmamış olabilir ve ileride değişebilir

Labeler ve ağ düzeyi moderasyon

  • Labeler, içeriklere veya hesaplara label ekleyen bir servistir
  • Kullanıcı belirli bir labeler’a abone olabilir ve gönderilerin label’larına göre deneyiminin değişmesini sağlayabilir
  • labeler, işletmecisinin istediği şekilde çalışabilir
    • Gönderiler üzerinde otomatik algoritmalar çalıştırabilir
    • İnsan tarafından onaylama veya reddetme yapılabilir
    • Engelleme listesi veya NSFW filtresi olarak kullanılabilir
  • label özelliği mevcut olsa da, yazının yazıldığı sırada kullanıcıların kendi labeler’larını çalıştırıp çalıştıramadığı belirsizdir
    • BlueSky kendi labeler’ını işletir
    • Harici bir sürüm henüz bilinmemektedir
  • feed, App View ve labeler bir araya getirildiğinde kullanıcı, uygulama içinde ve dışında moderasyon deneyimini seçebilir
    • Bir feed’de yalnızca SFW görüp başka bir yerde NSFW içeriğe izin verebilir
    • Engelleme listesi oluşturup paylaşabilir
  • Moderasyon araçları uygulama değil protokol düzeyinde çalıştığından, atproto üzerindeki diğer uygulamalarda da aynı labeler kullanılabilir
    • atproto üzerinde bir Instagram klonu yapılsa bile aynı engelleme listesi labeler’ı kullanılabilir
    • Bir yerde engellediğiniz kullanıcıyı isterseniz her yerde engelleyebilirsiniz

Mastodon tarzı instance modeliyle farkı

  • atproto modeli, Mastodon’daki gibi belirli bir “instance” üzerinde “hesap” bulunması modelinden farklıdır
  • “Benim instance’ım defederate edilirse ne olur?” gibi sorular aynı şekilde uygulanması zor sorulardır
  • Belirli bir PDS’den gelen gönderileri beğenmeyip yok saymak gibi yollarla benzer bir hedefe ulaşılabilir
  • Ancak bu tercih, sunucu sahibinin kullanıcının hesabı adına verdiği bir karar değil, kullanıcının kendi tercihidir

DID, handle, hesap taşınabilirliği

  • atproto’nun kimlikteki temel unsuru DID(Decentralized Identifier)’dır
    • Örnek DID şu biçimdedir: did:plc:3danwc67lo7obz2fmdg6jxcr
  • Kullanıcının fiilen gördüğü kimlikte handle da kullanılır; handle bir alan adıdır
    • Örnek: @steveklabnik.com
    • BlueSky’ye katılanlar @username.bsky.social biçiminde bir handle alabilir
  • DID kararlı olduğu için handle’ı @steveklabnik.bsky.social’dan @steveklabnik.com’a değiştirmek takipçiler açısından kesinti yaratmaz; arayüzde yalnızca handle değişir
  • Bir alan adını handle olarak kullanmak için PDS’nin oluşturduğu DID alınır ve ilgili alan adının DNS’ine bir TXT record eklenir
  • DNS bilmeyen kullanıcılar da BlueSky ile NameCheap iş birliği sayesinde teknik bilgiye ihtiyaç duymadan alan adı kaydedip bunu handle olarak ayarlayabilir
  • Hesap taşınabilirliği DID ve kriptografik imzalara dayanır
    • Belirli bir DID’yi kullanan kişinin oluşturduğu içerik imzalanır ve ağda çoğaltılır
    • Bir “hesabı” sonlandırmak için kullanıcının sahip olduğu anahtarın kullanımı zorla engellenmelidir; ancak ağ tasarımı gereği başka aktörler bu anahtara erişmez
    • PDS kapansa bile ağdaki içerik backfill edilerek yeni PDS’ye taşınıldığı bildirilebilir

did:web ve did:plc tartışması

  • BlueSky iki tür DID yöntemini destekler
    • did:web: alan adı tabanlı yöntem
    • did:plc: BlueSky’nin uyguladığı kendi yöntemi
  • did:plc içindeki plc, “placeholder” anlamına gelir ve BlueSky bunu desteklemeyi sürdürmeyi planlar
  • did:plc’nin zayıf yanı, doğru bilgiyi çözümlemek için BlueSky’nin işlettiği bir servise ihtiyaç duymasıdır
    • Örnek sorgu plc.directory üzerinden yapılabilir
    • Bu yapı nedeniyle BlueSky’nin, ağ tasarımında aslında mümkün olandan daha güçlü biçimde kullanıcıları banlayabileceği eleştirisi vardır
  • Bu sorunu ölümcül görmeyen nedenler de vardır
    • İstemeyenler did:web kullanabilir
    • Daha iyi bir sistem ortaya çıkarsa geçiş yapılabilecek şekilde tasarlanmıştır
    • Gelecekte did:plc yönetişiminin bir uzlaşı modeline taşınması olasılığı vardır
    • Başka aktörler did:plc servisi işletip onu kullanabilir

BlueSky’nin atproto üzerinde çalışma biçimi

  • BlueSky, atproto ağı üzerinde inşa edilmiş bir uygulamadır
  • BlueSky, App View ve bunu kullanan web uygulamasını işletir
  • Web uygulaması üzerinden kaydolan kullanıcılar için PDS de işletir ve bu PDS’lerin iletişim kurduğu Relay’i de çalıştırır
  • BlueSky iki tür Lexicon yayımlar
    • com.atproto.*: ağdaki herhangi bir uygulamanın ihtiyaç duyduğu düşük düzey işlemler
    • app.bsky.*: BlueSky’ye özgü işlemler
  • BlueSky’nin ürün hedefi, kullanıcıların bu teknik ayrıntıları bilmeden kullanabilmesini sağlamaktır
    • Instance olmadığı için hesap oluştururken instance seçme akışı yoktur
    • Host kapansa bile taşınmak mümkündür ve takipçilerin bunun farkında olması gerekmez

atproto üzerinde yeni uygulama yapmak

  • atproto uygulaması, bir Lexicon oluşturmakla başlar
  • Ardından ağdaki veriler içinde ilgili Lexicon ile ilişkili verileri işleyen bir App View işletilir
  • Uygulama, kullanıcının kendi PDS’ine bu Lexicon’u kullanarak veri yazabilmesini sağlamalıdır

Tasarımdaki temel ayrım

  • atproto ile BlueSky’nin rollerinin ayrılması önemli bir tasarım unsurudur
  • BlueSky gibi bir “killer app”, ağı kullanmak için bir neden sunar
  • BlueSky’nin kendisi de atproto üzerinde gerçek bir uygulama yapılabilir mi diye doğrulayan bir dogfooding rolü üstlenir

İlgili okumalar

1 yorum

 
GN⁺ 2024-02-26
Hacker News görüşleri

  • Çok iyi tasarlanmış gibi görünüyor ve ActivityPub’ın büyük sorunlarının bir kısmını çözüyor gibi
    Eskiden Bluesky ile ilgilenmiyordum, ama artık bir hesap açmayı düşünüyorum

    • Bluesky ve AT Protocol’ün temel sorunu, teknik üstünlüklerinden çok güçlü NIH (Not invented here) tavrında
      Herkesin kullandığı user@host ve WebFinger gibi mevcut protokoller yerine “kimlik olarak alan adını kullanmayı” seçtiler; sertifikalarda ACME’nin zaten çözdüğü yaklaşımdan da yararlanmadıkları için birinin Bluesky’de s3.amazon.com alan adını alması gibi şeyler de yaşandı https://www.reddit.com/r/programming/comments/138hlf2/s3_dom...
      Ayrıca yeni bir uzak çağrı protokolü olan XRPCyi oluşturdular ve protobuf ya da jsonld’den daha yeni olması dışında avantajı belirsiz olan, kod üretimine dayalı veri şeması Lexiconu da kullanıyorlar
      Diğer ekosistemlere saygı göstermeye ya da onlarla konuşmaya sürekli yanaşmayan bir “açık ağa” güvenmek zor; ortak bilgiyi reddederken tasarıma daha kaç yaygın hatanın girmiş olabileceğinden de şüpheleniyorum
    • AT Protocol teknik olarak daha iyi görünüyor, ama sosyal açıdan kolayca başarısız olabilecek bir yapı gibi
      Gerçek topluluklardan kopuk röle ve moderasyon hizmetlerini birilerinin kurup sürdürmesi için sosyal bir teşvik yok; geriye yalnızca ücretli hizmetler, reklam ekleme, veri madenciliği ve bilgi manipülasyonu gibi parasal teşvikler kalıyor
      Veri dağıtımı ve moderasyon merkezileştiğinde hem barındırma maliyeti hem insan maliyeti büyük bir işe dönüşüyor; bu da Bluesky dışındaki birinin kendi rölesini ya da moderasyon hizmetini işletmesini fiilen engelleyen bir yöne gidiyor
      ActivityPub’ın dezavantajlarına rağmen “kapılı topluluklar” gibi bir yaklaşım, kullanıcıların sunucuya aidiyet hissetmesini; operatörlerin ve moderatörlerin de kullanıcılara hizmet sunmaktan gurur duymasını sağlıyor
      AT Protocol teknik olarak birden çok röleye ve moderasyon hizmetine izin veriyor, ama pratikte bunlardan kaç tane ortaya çıkacağı şüpheli
      Bir sosyal ağ protokolünü yalnızca saf teknik ve hasmane bir bakışla değerlendirmek bana göre hata. Bir sunucuya bağımlı olmamak karşılığında sıkı topluluklardan da kopuyorsunuz ve artık ortada kaybedecek bir şey kalmıyor
      Veri, kimlik ve topluluk açısından kaybedecek bir şey olmaması iki ucu keskin bir kılıç

  • Bildiğim kadarıyla şu anda yalnızca tek bir röle var
    Birden fazla röle ortaya çıkarsa her biri ağı farklı görecek ve daha fazla gönderi içeren röle daha iyi röle olacak
    Tek bir baskın röle yerine röle çeşitliliği sağlamak epey zor olabilir; bu da alternatif DNS sistemlerinin traction elde etmeye çalışmasına benziyor. O zaman gönderim baskın röle tarafından yakalanmazsa yapacak bir şey yok gibi görünüyor
    Henüz çok erken aşamada, böyle olmayabilir; baskın bir röle olsa bile GitHub da o kadar kötü değil ve alternatifler de var

    • Eskiden Bluesky bana oldukça kafa karıştırıcı geliyordu, ama son zamanlarda bunun esas olarak terminolojiden kaynaklandığını fark ettim
      Sisteme [mikroblog] -> [indeksleyici] -> [istemci] derseniz anlaması daha kolay
      Gerçekte daha fazla unsur var, ama Bluesky’nin temel işleyişi kabaca böyle; yalnızca adlandırmalar beklenenden farklı yapılmış gibi
      İndeksleyiciye ihtiyaç duyulmasının nedeni, kullanıcı ID’sinin sistemde statik kalmaması. DID:PLC, hash’in bir alt dizgesiyle başlayıp “anahtar rotasyonu” nedeniyle zaman içinde kullanıcı farkında bile olmadan kullanıcı ID’sinin değiştiği tuhaf bir kriptografik yeniden düzenleme yaşıyor
      LiveJournal benzeri bir sistem düşünün; handle’lar sürekli değişiyor ve bu değişimi takip edecek yetkili bir otoriteye ihtiyaç var. Elbette başlık ya da Markdown desteği olmadan yalnızca kısa mesajlar gönderilebiliyor
      Kişisel olarak statik bir açık anahtar alıp mesajları özel anahtarla imzalayan yeni DID:PLCyi bekliyorum. Takip edilmesi gereken şeyler çok daha azalacak; kendi kendine barındırma ve local-first geliştirme çok daha kolaylaşacak gibi
    • Gerekirse istemci olan App View’un birden çok röleyi paralel kullanabileceğini düşünüyorum
      Birbirinden farklı ama örtüşebilecek depo kümelerini barındıran birden fazla GitHub instance’ından veri çeken yerel bir GitHub UI’ı gibi bir yapı
      Birden fazla NNTP sunucusundan haber gruplarını toplayıp gösteren Usenet istemcisine de benziyor
    • Yasa dışı içerik konusundaki değerlendirme farkları dışında tüm rölelerin verinin tamamına sahip olduğu bir yapı olacağını tahmin ediyorum
      Rölelerin ağı neden birbirinden farklı göreceğini düşündüğünüzü merak ediyorum

  • Merak ettiğim şey, BlueSky’ın protokolün yalnızca açık kısımlarını kullanacağına güvenilir biçimde nasıl söz verebileceği
    BlueSky fiilen oldukça merkezi göründüğü için, birinci taraf istemcinin mutlaka ATProto istemcisi olması için teknik bir neden yok gibi
    Kısa ya da orta vadede bunu yapmak kullanıcı güvenine büyük bir ihanet olurdu, ama ActivityPub’ın fiilen dağıtık yapısı burada daha güçlü bir güvence gibi görünüyor

    • Birinci taraf BlueSky istemcisiyle ne kastedildiğini bilmiyorum
      Birinci taraf röle ile PDS’nin başka bir protokolle iletişim kurabileceği kastediliyorsa, neden endişe edildiğini pek anlamıyorum
      İki ActivityPub istemcisi de ActivityPub olmayan bir protokolle birbiriyle konuşabilir
    • Tüm kod açık kaynak olduğu için güvenilebilir
      Zaten pratikte böyle yapıyorlar; eğer yapmamaya doğru değişmeye başlarlarsa insanlar bunu çok hızlı fark eder

  • “İfade etme ve erişim kapsamı” ayrımına kadar gitmesi iyi, ancak uzun vadede sadeliği nedeniyle Mastodon daha akıllıca bir tercih gibi geliyor
    Kısa vadede Mastodon’da akış kürasyonu kesinlikle daha zor olduğu için daha az eğlenceli ya da daha az kullanışlı olabilir
    Temel soru şu: varsayımsal, muhtemelen zengin ya da güçlü kötü niyetli bir aktör burada oyunu bozmak isterse bunu nasıl yapabilir?
    Yazının “akışın nasıl çalıştığını pek bilmiyorum” der gibi bu kısmı fazla geçiştirmesi çok şüpheli. Akışın nasıl çalışacağını gayet iyi biliyorlar ve gücün ve paranın o noktada olduğunu da bildikleri için oraya tutunmaya çalışıyorlar gibi görünüyor

    • “Akışın nasıl çalıştığını pek bilmiyorum” şeklindeki özet pek yerinde görünmüyor
      Yazar şöyle diyor: “Akışlar atproto’ya yakın zamanda eklenen bir özellik; yani varlar ama henüz işlevleri tamamlanmamış olabilir ve ileride değişebilirler. Bakıp göreceğiz. Benim bakış açımdan iyi çalışıyorlar, ancak düşük seviyeli teknik ayrıntılarını takip etmiyorum.”
      Hemen üstteki paragrafta şu bağlam da var: “Diğer mikroblog araçlarına kıyasla BlueSky’nin öldürücü özelliklerinden biri, kullanıcıya tam seçim hakkı vermesidir. Kendi akış algoritmamı yapmak istersem yapabilirim ve başkalarıyla kolayca paylaşabilirim.”
    • Hangi kısımdan akışın çalışma biçimini bilmediği anlamının çıktığını bilmiyorum
      Akış açık kaynaklı, şu anda mevcut ve kendiniz de çalıştırabilirsiniz
      “Oyunu bozmak” derken hangi oyundan ve hangi anlamda söz edildiği de net değil. Burada çok fazla hareketli parça var

  • Kullanıcının barındırma sağlayıcısından bağımsız bir moderasyon sağlayıcısı seçmesi sayesinde instance seçimi konusunda daha az endişelenmesi fikri güzel görünüyor
    Yine de instance’ların, yerelde yasa dışı olan içerikleri barındırmamak için moderasyon yapması gerekecek gibi
    Sonuçta bu, instance işleten kişiler için epey zor bir işe dönüşür ve oldukça büyük bir karmaşaya yol açabilir. Ben yanlış anlamış da olabilirim

    • İçeriği barındıran kişi, barındırdığı içeriğin hukuki sonuçlarıyla ilgilenmek zorunda; bundan nihayetinde kaçış yok
      Ancak hangi protokol kullanılırsa kullanılsın durum aynı
    • Yanlış anlamamışsın. Bluesky’nin merkezsizleşmesinin sahteye yakın olduğunu düşünüyorum
      PDS için makul bir Ubuntu makinesi yeterli, ancak bu yazı bile relay’in pahalı ve devasa bir merkezi kontrol noktası olduğunu kabul ediyor
      Bluesky’nin spam’e karşı planı ne? Muhtemelen relay’de engellemek gibi bir şey olacaktır
      DID sunucusu da başka bir merkezi kontrol noktası
      Yine de PDS’i istediğiniz gibi çalıştırabilirsiniz

  • Bluesky hakkında eğlenceli bir bilgi: bir süre önceki yazıyla bağlarsak, bu da bir kişinin adından türemiş sayılır
    CEO’nun adı Çince’de kelimenin tam anlamıyla blue sky demek

    • İlginçtir, Twitter ben katılmadan önce projeye zaten bluesky adını vermişti
      Tesadüf. Yine de ikinci adım Çince’de bluesky anlamına geliyor

  • Bu kısa çizgi roman da güzel: https://bsky.social/about/welcome-to-bluesky-comic

  • Bluesky did:plc desteğini bırakırsa mevcut tüm PLC kimlikleri bozulur mu?
    PLC o servise ping gönderen bir yapıda olduğu için merak ediyorum

    • https://plc.directory yansıtılabilir; böyle bir şey olursa yeni bir mirror yetkili sunucu haline gelebilir

  • Üçüncü taraf labeler’lar konusunda şüpheciyim
    Kötüye kullanım nasıl engellenebilir?

    • Kullanıcı hangi üçüncü taraf labeler’a abone olacağını seçer
      Labeler servisi konumunu kötüye kullanmaya başlarsa kullanıcı aboneliği kesebilir
      Bluesky’nin labeler’ları ekosisteme nasıl oturtmak istediğine dair ayrıntılı açıklama https://github.com/bluesky-social/proposals/tree/main/0002-l... adresinde var
    • Ne tür bir kötüye kullanımdan bahsettiğine göre yanıt değişir
      Görüşümü söyleyebilirim, ama soru çok geniş olduğu için nereden başlayacağımı bilmiyorum
    • Yakında moderasyon hakkında çok daha fazla şey yayımlayacağız, ancak labeler’ların temeli şöyle
      Ağdaki herkes, diğer labeler’lar dahil olmak üzere her şeyi etiketleyebilir
      Uygulamalar, şu anda Bluesky’nin özel akışlarında olduğu gibi kullanıcının abone olacağı labeler’ları öne çıkarabilir
      Uygulamalar, şu anda beğeni ve kaydetme ile ifade edilen popülerliğe göre özel akışları öne çıkarıp sıraladığı gibi, labeler’ların nasıl öne çıkarılıp sıralanacağını da kürate edebilir

  • “Aracılık araçları erişim katmanına aittir. Tüm ifadeleri alır, ama görmek istemediklerimin erişimini sınırlamam için bir yol sunar” yaklaşımı, sonuçta “görmek istemiyorsan gözlerini kapat” tarzı bir aracılık gibi görünüyor.
    Bunun Silicon Valley’de sevilen bir felsefe olduğunu biliyorum, ama temelden kusurlu olduğunu düşünüyorum.
    Belirli bir konuda ilgisiz başka kişilerin konuşmasını ya da belirli içerikleri elde etmesini engellemenin meşru olduğu durumlar var.
    Tipik örnekler siber zorbalık, doxxing ve intikam pornosu. İki veya daha fazla kişinin üçüncü bir kişiye zarar verme yollarını konuşması ya da özel, aşağılayıcı veya yanlış bilgileri ifşa etmesi gibi.
    Bu bilgiyi mağdurun akışından kaldırmak tamamen işe yaramaz; zaten büyük olasılıkla mağdurun akışında görünmeyecektir. Zarar, diğer insanların o içeriği görmesinden veya tartışmaya katılmasından kaynaklanır; ama bu zarar gerçektir.
    Geleneksel aracılık sistemlerinde moderatör, gönderiyi herkes için silebilir ya da saldırganı engelleyerek bu davranışı durdurabilir. “İçeriği sadece gizleyen” bir sistemde bu mümkün değildir.
    Paylaşılan engelleme listeleri veya “etiketler” de işe yaramaz. İçerik tüketicilerinin bunu engellemek için bir motivasyonu yoktur; aksine intikam pornosunu görmek isterler.
    Engellemek isteyen mağdurdur, ama mağdurun herkesi belirli bir engelleme listesini kullanmaya zorlama gücü yoktur. Çünkü bu sistemin özü, kimsenin başka birine engelleme listesi dayatamamasıdır.

    • Bu alanda ileride daha fazlası olacak. Bu yazıda normal durumlara odaklandım, kötü durumları ele almadım.
      Ekip bu sorunları inceledi ve “uzmanlarla da görüştü”, ancak hâlâ devam eden bir çalışma olduğu için konuşmaya yetkili olduğumu düşünmüyorum.
      “İnsanlar bunu engellemektense görmek istedikleri için etiketler işe yaramaz” kısmı, ekibin açıkça kabul ettiği sorun alanının içinde yer alıyor.
      Ek olarak buraya bakın: https://lobste.rs/s/shseqz/how_does_bluesky_work#c_vjvmei