atproto'da instance yok
(overreacted.io)- “Bluesky instance'ı” arama sorusu, Mastodon'un instance modelini olduğu gibi atproto'ya uygulamaktan kaynaklanıyor; oysa atproto, hosting ile uygulama agregasyonunu ayıracak şekilde tasarlandı
- RSS ve Google Reader'da olduğu gibi veriler uygulamanın içinde kilitli değil, host edilen depolarda bulunuyor; birden fazla uygulama bu verileri alıp gösteriyor
- Mastodon instance'ları hosting, uygulama, kimlik ve federasyon ilişkilerini tek bir kutuda birleştiren bir yapıya sahip; bu yüzden yönetici kararları ya da instance arızaları kullanıcı deneyimini doğrudan etkiliyor
- atproto'da kullanıcılar hosting'i taşıyabiliyor, yeni uygulamalar yapıp deneyebiliyor; Tangled, Semble ve Sidetrail gibi uygulamalar Bluesky'dan ayrı çalışıyor
- atproto'nun dağıtık yapısını görmek için “Bluesky instance sayısı”ndan çok alternatif hosting'e geçişin ve yeni uygulama ekosisteminin gerçekten çalışıp çalışmadığına bakmak gerekiyor
RSS ve Google Reader'a daha yakın bir model
- RSS döneminde kullanıcılar yazılarını kendi bloglarında yayımlıyor, Google Reader veya Feedly gibi uygulamalar ise birden fazla blogdaki yazıları agrega ediyordu
- Yazılar Google Reader'ın içinde “yaşamıyor”, herkesin kendi blogunda veya kendi hosting konumunda kalıyordu
- Buradaki temel fikir hosting ile agregasyonun ayrılması
- Hosting, içeriğin gerçekten bulunduğu yerdir
- Agregasyon uygulaması ise birden fazla kaynaktaki içeriği gösteren bir projeksiyona daha yakındır
Merkezî sosyal medya ve Mastodon'un buna yanıtı
- Geleneksel sosyal medya, tüm kullanıcıları tek bir uygulama ve tek bir alan içinde toplama biçiminde çalışır
- Bu yapıda merkezîleşme ve güçlü ağ etkileri ortaya çıkar; dağıtık sosyal ağ tartışması da bu sorunun nasıl bölüneceği sorusundan başlar
- Mastodon tarzı yaklaşım, her topluluğun kendi “küçük Facebook”unu veya “küçük Twitter”ını işletmesidir; bu kutuya instance denir
Mastodon instance'ının bir araya getirdiği şeyler
- Kullanıcılar belirli bir instance'ın “içinde” yer alır
- Mastodon giriş biçiminin
[email protected]olmasının nedeni de kimliğin instance'ı içermesidir - Kullanıcı soyut bir “Alice” değil, “instance #1'deki Alice” olur
- Mastodon giriş biçiminin
- Farklı instance'lardaki kullanıcıların iletişim kurabilmesi için instance'ların birbirine mesaj göndermesi gerekir
- Alice instance #1'de ve Bree instance #2'deyse, Alice Bree'yi takip ettiğinde Bree'nin yazıları instance #1'e iletilir
- Bu iletim ilişkisine federasyon denir
- Hosting ile uygulama birlikte bağlandığı için kullanıcı instance'a güçlü biçimde bağımlı hâle gelir
Instance birleşiminin yarattığı kısıtlar
- Instance yöneticileri arasında çatışma çıkarsa birbirleriyle federasyonu kesebilirler
- Bu durumda kullanıcılar artık arkadaşlarının yazılarını göremeyebilir
- Kullanıcının instance'ı kapanırsa o instance'a bağlı kimliği de kaybolur
- Çünkü takipçilerin takip ettiği şey “o instance'taki kullanıcı”dır
- Instance'lar arasındaki bağlantı okları O(n²) olarak artar
- Şu anda büyük bir sorun olmayabilir ama bu tür bir sosyal ağ popülerleşirse önemli hâle gelebilir
atproto'nun temel farkı
- atproto, Mastodon tarzı instance kavramını temel almaz; bunun yerine RSS ve Google Reader modeline geri döner
- Ağ düzeyinde hosting ile agregasyonu ayırır
- Veri hosting'dedir
- Uygulamalar, birçok kişinin hosting'inden veriyi agrega eder
- Bu yüzden atproto'da instance yoktur
- Hosting değiştirilebilir
- Uygulamalar birden fazla hosting'deki veriyi agrega eder
- Bu yapı, “tek bir uygulamayı birden çok kopya hâlinde çalıştırmak”tan daha zengin bir dağıtık mimari olarak görülebilir
Kullanıcının doğrudan yapabildiği dağıtım
- Kullanıcılar hosting'i değiştirebilir
- Yazar, kendi atproto verilerini Eurosky'ye taşıdığını ve birkaç UX sorunu dışında sürecin otomatik ilerlediğini söylüyor
- Daha ileri gitmek isteyenler Cloudflare üzerinde ücretsiz olarak kendi hosting'ini kurabilir
- Yeni uygulamalar denenebilir ya da doğrudan yapılabilir
- Tangled ve Semble, Bluesky ile ilgisiz atproto uygulamalarına örnek
- Yazar Sidetrail adlı bir uygulama yaptı; bu uygulama açık kaynak
- atproto'da uygulama geliştirmek için Statusphere tutorial da var
Neden “Bluesky instance sayısı” isabetli bir ölçü değil
- Mastodon'da dağıtıklığı instance sayısıyla ölçmek doğaldır
- Çünkü Mastodon'da başlıca dağıtım biçimi, hosting ile uygulamanın birleşik olduğu daha fazla kutu işletmek ve bunları birbirleriyle konuşturmaktır
- atproto'da tüm uygulamalar, bütün Atmosphere'in bir projeksiyonuna daha yakındır
- Bu, Feedly ve Google Reader'ın tüm Blogosphere'i göstermesine benzer bir yapıdır
- Bluesky veritabanı sunucusunun tam kopyasını birden fazla kez çalıştırmak mümkün olsa da, bu genelde Google Reader kopyalarını çoğaltmak kadar faydalı değildir
- Bazı kopyalar belirli ihtiyaçlar için vardır
- Blacksky, farklı bir moderasyon felsefesi gibi özel ihtiyaçlara yönelik bir örnektir
- reddwarf.app istemcisi, özel bir veritabanı olmadan topluluğun işlettiği ücretsiz önbellek constellation'ı kullanır
- Relay gibi paylaşılan ağ altyapılarının bir yıldır düşük maliyetle işletildiği belirtiliyor
atproto'da bakılması gereken ölçüt
- atproto'nun dağıtıklığını görmek için “Bluesky instance sayısı”na değil, şunlara bakmak gerekir
- İnsanlar alternatif hosting'e geçiyor mu
- İnsanlar yeni uygulamalar yapıyor ve kullanıyor mu
- Hosting ile uygulamayı ayırmak, hem kapalı sosyal ağlarda hem de federasyonlu sosyal ağlarda bozulmuş teşvikleri düzeltebilir
- Kullanıcı verisini uygulamanın dışında tutup uygulamaların bu veri üzerinde agregasyon yapması, atproto'nun özünü oluşturur
1 yorum
Hacker News görüşleri
“Bluesky instance’ı nerede” sorusunu kasıtlı olarak yanlış anlayıp ATProto’yu parlatırken ActivityPub’ı küçümseyen bir yaklaşım gibi görünüyor
Bu, ATProto’nun relay yapısı ve artı-eksileri ya da ActivityPub’ın hesap taşıma özellikleri ve artı-eksileri gibi ilginç teknik gerçeklerin atlanmasına veya çarpıtılmasına yol açıyor ve benzer sorunları çözen iki platform arasında gereksiz bir gerilim yaratıyor
“Instance” kelimesini sunucu, çalışan yazılım, sanal makine ya da konteyner gibi genel anlamlarda kullanan insanlar da olabilir; neden bunu özellikle Mastodon tarzı bir kavram olarak almak gerektiğini anlamıyorum
Diyagramlar ve açıklama iyiydi ama ActivityPub’a yönelik o ince dokundurmalar, bilgi vermekten çok düşmanlıktan çıkmış gibi hissettirdi ve bu hayal kırıklığı yarattı
“Google Reader instance’ı nerede” ile karşılaştırınca bu sorunun ne kadar tuhaf olduğu daha net ortaya çıkıyor diye düşündüm ve yazının sonundaki iki görselin, atproto/ActivityPub hakkındaki ilk dönem tartışmalarda sıkça gözden kaçan noktaları oldukça iyi açıkladığını düşünüyorum
Relay’i neden dahil etmediğimi burada yazdım: https://news.ycombinator.com/item?id=48600963
Relay, modelin çekirdeğinden çok bir performans optimizasyonu olduğu için yazıda modelin kendisine odaklanmak istedim
Kelime belirli bir kavram ve yapıyla özdeşleşmeye başlayınca, “ademi merkeziyetçi sosyal medya” denince birçok kişi ActivityPub tarzı federasyon yapısını düşünüyor ve ATProto’ya bakıp “insanların kaydolduğu neden sadece bir Bluesky instance’ı var?” diye soruyor
Tamamen yeni bir bakış olmasa da, bu yerleşik çağrışımların zihninde kemikleştiği insanlara daha sonra yeniden bağlantı verilebilecek faydalı bir yazı gibi görünüyor
“filioque” fermanı yerine “federasyon” tanımı üzerine iki tarafın birbirinden farklı şeyler söylediği blog yazıları dolaşıyor denebilir
Fediverse modeli mevcut sosyal ağ bakış açısından anlaması kolay ama ATProto, kullanıcıya veri egemenliği verirken merkezi sosyal ağların ölçeklenebilirliğini de elde etmeyi amaçlayan yeni bir kavram
Buradaki benzetmenin bozuk olduğunu düşünüyorum
RSS, Google Reader’a hiç bağımlı değildi; en güçlü döneminde bile bugünkü e-postanın Gmail’e bağımlılığından daha az bağımlıydı
ATProto’da ise AppView’in faydalı hale gelmesi için relay’e büyük ölçüde dayanması gerekiyor ve relay işletme maliyeti de epey yüksek
Ayrıca RSS diyagramındaki sarı daire blogları temsil ederken, Facebook gönderilerini temsil eden daireler aynı türden değil. Bloglar kendi başına bağımsızdır
Bunun anlamı ATProto kötü demek değil ama bu yazı netleştirmekten çok daha fazla kafa karıştırıyor gibi
Eskiden tüm trafiği sakladığı için biraz daha pahalıydı ama sync 1.1 ile o kısım çıkarıldı ve şimdi aylık 20 dolarlık bir sanal makinede bile oldukça rahat çalıştırılabiliyor
Gerçekten pahalı ve zor olan şey ise merkezi ya da ademi merkeziyetçi fark etmeksizin değişmeyen moderasyon
Bu yazının yazarı 9 ay önce relay hakkındaki yaygın yanlış anlamaları ele almıştı: https://news.ycombinator.com/item?id=45077291#45078223
Bana göre relay, ATProto’nun yüksek performansla çalışmasını sağlayan yapıştırıcı
İçeriğe bakmadan veriyi taşıyor ve her AppView’in bilmesi gereken servis sayısını azaltıyor gibi görünüyor
Yazıda da dendiği gibi Mastodon’a kıyasla büyük iyileşme, relay, AppView ve PDS’nin farklı ölçeklenme gereksinimlerine sahip ayrı servisler olması ve bu, sistem tasarımı sorununa oldukça zarif bir çözüm
[1] https://atproto.com/guides/glossary
Ama görünmeyen bir optimizasyon ve başka stratejiler de olduğu için yazıda büyük ölçüde atlandı
Örneğin bugün birçok küçük uygulama kendi veritabanı indeksini oluşturmuyor ve hiç relay kullanmadan Constellation’a dayanıyor (https://constellation.microcosm.blue/)
Yalnızca barındırılması yasa dışı olan içeriklerin kaldırıldığını iddia ediyorlar ama bunun ne kadar doğru olduğunu bilmiyorum ve ileride değişme riski de her zaman var
https://docs.bsky.app/blog/blueskys-moderation-architecture#...
İki yaklaşım arasındaki farkı açıklaması iyiydi
Ancak “instance’ların çözdüğü sorunu ATProto nasıl çözüyor?” sorusunu yanıtlamadığı için eksik kalmıştı
Örneğin gönderi defederasyonu, arkadaşların gönderilerini görememeye yol açan bilinmez sebeplerden biri gibi ele alınırsa, “peki atproto defederasyonun çözdüğü sorunu nasıl çözüyor?” sorusuna cevap verilemez
Bu çerçevede doğal temel cevap “çözmüyor” olur
Barındırma düzeyinde, blogspot.com ya da Cloudflare’ın belli durumlarda engelleme yapması gibi, açıkça yasa dışı şeyler nedeniyle hosting sağlayıcısı hesabı kapatabilir
Uygulama düzeyinde ise uygulama yöneticileri ve moderatörler, kullanıcı tarafından üretilen içeriği ele alan diğer web servislerinde olduğu gibi müdahale eder
Bu, uygulama geliştiricisinin tercih edeceği bir konudur; Reddit’te olduğu gibi kullanıcı alanı moderasyonu için temel bileşenler sunulabilir ya da Bluesky’de olduğu gibi ayrı bir moderasyon servisi takılabilir
Birbirleriyle kavga edebilen “topluluk instance’ları”na karşılık gelen bir şey olmadığı için defederasyon da yoktur. Yalnızca hosting, uygulama ve uygulama geliştiricisinin tercihine bağlı uygulama düzeyi moderasyon vardır
Bu, özünde Microsoft’un e-postada yaptığı şeye çok benziyor. En büyük sağlayıcılar dışındakilerden gelen mesajları çöpe atıyor ve pratikte sistemi öyle bir biçimde federatif kılıyor ki kullanıcıların mesaj iletebilmek için Microsoft’u ya da başka büyük yerleşik sağlayıcıları kullanması gerekiyor
Böyle olunca yeni instance’lar mesaj iletemiyor ve kullanıcı kazanamıyor. Büyük yerleşik sağlayıcılar için yeni instance’larla federasyon kurmamak yönünde çarpık bir teşvik oluşuyor
Bu mimari tercih, uzun vadede oligopolü pekiştirme etkisi yaratıyor
Bunun spam önleme için gerekli olduğu söyleniyor ama DKIM ve reverse DNS gibi ayarlar düzgün yapıldığında Gmail’e genelde teslimat yapılabildiği gibi, bunu yapmayan sağlayıcılar da var ve onların daha fazla spam sorunu yaşadığı da söylenemez
Bariz alternatif, filtrelemeyi istemci tarafında yapmaktır. Microsoft gibi operatörler yerine uBlock benzeri filtre listesi sağlayıcıları filtre sağlarsa, belirli bir instance işletmedikleri için herkesi kendi instance’larına çekmeye yönelik teşvikleri de olmaz
Belki tüm firehose’u tüketebilen çok sayıda AppView’un olduğu, bunlar arasında özgürce seçim yapılabildiği ve kişinin bunları kendisinin ucuza çalıştırabildiği alternatif bir evrende çözebilirdi
ATProto, masaüstü ya da mobil RSS okuyucuları olmadan RSS’i yalnızca Google Reader veya onun ölçeğinde bir klon hizmet üzerinden okuyabildiğiniz bir dünyadaki RSS’e daha yakın
Eğer ördek gibi vaklıyorsa ördektir
Hesabın tek bir PDS’si vardır ve DID, kullanıcının kanonik veri akışı ve yazma hedefi olan PDS’yi işaret eder
Veriler kopyalanabilir ama PDS yetkili kaynak olarak kabul edilir
Bu, dağıtık bir mimariden çok istemci/sunucu mimarisine daha yakındır
Ortada bir P2P veritabanı da yoktur; DHT’ye ya da eşlere yazılmaz. PDS’ye yazılır ve bu yazma işlemi seçmeli olarak aynalanır
Keşif de DNS ile yapılır; yani veriyi eşlerden sormazsınız
Relay’e de eş olarak değil, kanonik olarak PDS’de barındırılan verinin kopyasını isteyen bir istemci olarak bağlanırsınız
PDS’ye instance, relay’e de ayna demeyi zorlamalı bulmuyorum
Ancak Mastodon’dan söz edenlerin “instance” derken genelde kastettiği şey bu değil
Mastodon’da instance, veri barındırma, uygulama, topluluk ve moderasyonun birleştiği ayrılmaz bir pakettir
ATproto'nun tutarlılık uğruna gerçek merkeziyetsizleşmeden, Mastodon ve ActivityPub'un ise daha erişilebilir bir merkeziyetsizlik uğruna gerçek tutarlılıktan ödün verdiğini düşünüyorum
Çünkü bir ActivityPub düğümü işletmek, sıradan bir self-hosting kullanıcısı için AT'de içerik relay'i işletmekten çok daha erişilebilir
AT'de “merkeziyetsizleştirilebilen” şey sonuçta yalnızca kendi veriniz; ağın bir parçasına ortak sahip olmaktan ziyade kendi verinize sahip olma fikrine daha yakın
Bu, HN'de zaten defalarca tekrarlanmış bir konu
ActivityPub'da bir instance işletmek; veriyi, uygulamayı ve sonrasındaki genişleme sorunlarını da tamamen üstlenmek anlamına geliyor, yani ya işletme sorumluluğunu bizzat alıyorsunuz ya da başkasının instance'ına bağlı kalıyorsunuz
Seçtiğiniz instance'tan memnun kalmayıp taşınmak isteseniz bile, durum hâlâ değişmediyse neredeyse sıfırdan başlamanız gerekiyor
AtProto'da aynı kimliği koruyarak başka bir uygulama platformuna geçmek kolay, ayrıca platformdan verinizi dışa aktarıp self-hosting yapmak da kullanıcı deneyimi açısından zor olsa bile en azından mümkün
Örneğin yakın zamanda Tangled'ı ilk kez denedim ve mevcut bsky tabanlı alan adımla (h14h.com) giriş yapabildim. Yeni bir hesap ya da yeni bir kullanıcı adı oluşturmam gerekmedi; sanki zaten oradaymışım gibiydi
Bir VPS üzerinde bir git deposunu self-hosting edecek yapılandırmayı yapmak en fazla yarım günlük işti ve neredeyse hiç ilgi gerektirmeyen bir arka uç hizmeti olarak çalışıyor
En kötü senaryoda tangled.org üzerinde “depo eski olabilir ve en güncel Tangled ile uyumlu olmayabilir” gibi bir banner çıkar; siz de Docker image'ını yeniden derleyip en güncel sürümü dağıtırsınız, sorun çözülür
Mimari olarak AtProto'yu kafaya yerleştirmek kesinlikle daha zor, ama onu gerçek kullanıcılarla buluşturmak bence çok daha basit
Benim kafamda bu tek bir slider'dan çok ödünleşimlerden oluşan bir açık büfe gibi
Bu arada AP dünyasında da bireyler ve küçük ekipler relay, mirror, cache ve AppView işletiyor. Yalnız ölçek büyüdükçe bunun daha pahalı hâle gelebildiği doğru
AT yalnızca tutarlılık değil, uygulamalar genelinde paylaşılan bir veri modeli de sunuyor
Bu sayede uygulamalar diğer uygulamaların içeriğine referans verip onu render edebiliyor. Bu, typed JSON'dan oluşan bir web gibi; farklı uygulamalar da aynı ağı gören farklı lens'ler
Herkes mevcut verinin üzerinde yeni deneyimler inşa edebilir; AP'de buna karşılık gelen bir şey neredeyse yok
AP veriyi uygulamaya bağlıyor, AT ise daha çok tüm dünyanın verisini içeren tek bir küresel veritabanını tüm uygulamaların sorgulamasına benziyor
Tartışmanın neden hep relay'lerde tıkandığını anlamıyorum. Bugünlerde isterseniz bir relay'i kabaca aylık 30 dolara çalıştırabilirsiniz; ya da Bluesky veya topluluk relay'lerini ücretsiz kullanabilirsiniz
Birçok uygulama relay bile kullanmıyor; onun yerine Constellation(https://constellation.microcosm.blue/) gibi topluluk indekslerine dayanıyor. Kendi sunucusunu ya da veritabanını bile çalıştırmayan uygulamalar var
Ama aslında tersine, ATproto'nun daha merkeziyetsiz olduğunu ya da en azından öyle olmaya çalıştığını savunmak isterim
ActivityPub dünyasında kimlik, uygulama ve hosting özünde birbirine bağlı
Lemmy kullanmak için ya o Lemmy instance'ında ikinci, kalıcı ve ayrı bir ActivityPub hesabı oluşturmanız gerekir ya da kendi Mastodon instance'ınızın Lemmy'nin anlayacağı mesajları gönderebildiği ölçüde Lemmy kullanabilirsiniz
Her yeni ActivityPub uygulaması yeni birlikte çalışabilirlik sorunları yaratıyor. Çünkü her uygulama kendi kimliğine ve hosting'ine sahip
Self-host ettiğim Mastodon instance'ımın bir Lemmy sunucusuna kimlik sağlamasının ve o Lemmy sunucusunun da benim adıma içerik barındırması için benim instance'ıma talimat vermesinin bir yolu yok
ATProto'nun iddia ettiği seviyeye yaklaşmak için en azından bunun olması gerekir. Ama bunun gerçekten var olan ATProto için ne kadar geçerli olduğunu bilmiyorum; ayrıca gerçekten var olan ActivityPub da savunucularının anlattığı kadar birlikte çalışabilir değil
Bu blog mimariyi iyi açıklıyor
Ama pratikte “sorun”un, Bluesky şirketinin ana uygulamayı işletmesi ve kullanıcı verilerinin çoğunu host etmesi olduğunu düşünmüştüm
Protokol düzeyinde merkeziyetsiz olsa da, fiilî sistem kontrolü elinde tutan özne açısından bakınca sistem hâlâ çok merkezi
Bunun ille de Bluesky'nin suçu olduğunu söylemiyorum, ama şimdiye kadar gidişatın böyle olduğu da ortada değil mi
Bu sorun Bluesky'ye ya da ATProto'ya özgü değil; ister kâr amaçlı bir kuruluş, ister kâr amacı gütmeyen bir yapı, ister gönüllü bir grup olsun, birileri her zaman sorun edecek bir şey bulur
Bluesky ile çıkar çatışmam da yok; yatırımcı değilim, yalnızca erken kullanıcıydım. Kendi sınırlarım içinde protokolü, şirketi ve web sitesini de anlıyorum
Site ve uygulama iyi çalışıyor. İnsanlar daha büyük ve daha iyi çözümler üretmektense sorun bulmaya fazla odaklanıyor
Çoğunluk Lemmy ya da Mastodon gibi geçici P2P çözümler istemiyor. İçeriğin tek bir yerde olmasını ve o varlığa hesap sorabilmeyi istiyorlar
Bu yüzden P2P sosyal ağların hiçbir zaman kitleselleşmeyeceğini düşünüyorum. Lemmy ve Mastodon çevresindeki drama, Twitter, Reddit ve Facebook'un toplamından daha fazlaydı
Benim iki kuruşluk görüşüm bu; eşimle arkadaşlarım da aynı fikirde gibi görünüyor
Hem teoride hem pratikte merkeziyetsiz
Yine de Bluesky en büyük parçayı işlettiği için, topluluk ya da mindshare düzeyinde merkeziyetsiz olmadığını söyleyebilirsiniz; ama bu da değişiyor
Sadece “instance yok” diyor, ama bu mimarinin kimlik doğrulama, senkronizasyon ve keşif gibi sorunları nasıl aştığını açıklamıyor
Google Reader benzetmesinin seçilmesi bana uğursuz geliyor
RSS, Google Reader kapandıktan sonra da yaşamayı sürdürdü ama RSS kullanan bütün topluluklar hayatta kalmadı; bunların çoğu bugün hâlâ RSS'nin ne olduğunu bile bilmiyor
Merkezsiz olduğunu iddia ederken, merkezsiz ekosistemdeki devasa toplumsal merkezileşmeyi iyi bir örnekmiş gibi durmadan işaret etmek neredeyse Freudyen hissettiriyor
Özellikle de sonunun nasıl bittiğini zaten biliyoruz
Google Reader, birçok RSS adasını tek bir yerde topladı ve sosyal grafik ile yorumlar gibi değerler ekledi, ama Google yöneticilerinin kaprisiyle çökerek RSS'yi neredeyse öldürdü ve etkileyici sosyal grafiği yok etti
Böyle bir benzetme ATProto'ya fazla güven vermiyor
uygulamalar ise bunu yalnızca indeksliyor
Dolayısıyla bu benzetmede herkes aynı grafiği kullanarak Google Reader'ı yeniden hayata döndürebilir ya da onunla rekabet edebilir
Merak ediyorsanız, şu anda http://leaflet.pub gerçekten tam olarak böyle çalışıyor
Masaüstü ya da mobil RSS okuyucuları kullanamadığınızı ve RSS'yi yalnızca Google Reader veya benzer ölçekte bir klon hizmet üzerinden okuyabildiğinizi hayal edin
Yakın zamanda biri yine NetNewsWire'dan bahsetmişti
Önemli fark şu: blogların kendi web siteleri vardır ve tam yazıyı RSS akışına koymak zorunda değildirler
Bluesky genelde böyle çalışmaz. PDS içindeki her şey kopyalanır
Ayrıca kolay kopyalama için tam blog yazılarının PDS'ye konması teşvik ediliyor
Böyle olunca indekslemek isteyen herkes bir kopya alır ve onunla ne yaptıklarını kontrol edemezsiniz
Bunun böyle olması şart değil. Blogunuzu kendi sitenizde yayımlayıp Bluesky'ye yalnızca bağlantı da koyabilirsiniz
atproto hesabının üzerine bir HTTP frontend koymak önerilen bir yöntem ve pratikte de birçok kişi bunu yapıyor
Ben de pfrazee.com'da bunu yapıyorum ve asıl kopyası atproto'da olan leaflet blog yazılarım da blogumda render ediliyor
RSS karşılaştırması yanıltıcı
Atproto uygulamaları, kullanıcının bilgisayarında çalışıp doğrudan içeriğin kaynağına bağlanan RSS okuyucularından farklı
Atproto uygulamaları, okuyucuya sunulacak içeriği kontrol eden, filtreleyen ve biçimlendiren sunuculardır
Atproto uygulamaları istedikleri gibi sansür uygulayabilir, shadowban yapabilir, reklam gösterebilir ve akışı algoritmik hale getirebilir
Kullanıcılar güçsüz kalır ve üreticiler de feryat etmekten başka bir şey yapamayan mağdurlara dönüşür
Verinizi istediğiniz yerde barındırabilmeniz, eğer o veriyi dağıtmanın bir yolu yoksa tamamen anlamsızdır
Öncelikle böyle şeyler yapmayan başka AppView'lar kullanabilirsiniz
Akışlar kullanıcının istediği şekilde algoritmik hale getirilebilir ve birden fazla uygulama varsa tek bir merkezi yapımcının istediği algoritmaya mahkûm olmazsınız