- Açık kaynak, yazılım altyapısının standardı haline geldiği gibi, sosyal uygulamalarda da 'açık sosyal' paradigması ortaya çıkıyor
- AT Protocol, kullanıcıların sosyal verilerini doğrudan sahiplenip kontrol etmesini sağlayarak mevcut sosyal platformlardan ayrışan bir yaklaşım sunuyor
- Sosyal veriler artık belirli bir hizmetin içine hapsedilmek yerine, kullanıcının doğrudan yönettiği kişisel depolarda saklanıyor
- Bu sayede uygulamalar arasında verinin yeniden kullanımı ve remikslenmesi mümkün oluyor; bir hizmet kapansa bile veriler kaybolmuyor ve varlığını sürdürüyor
- Açık sosyalin yaygınlaşmasıyla kullanıcı odaklı veri sahipliği ve esnek genişleyebilirlik temel değerler olarak öne çıkacak
Giriş: Açık kaynağın başarısı ve yeni akım
- Açık kaynak, geçmişte büyük direnç görmesine rağmen bugün ortak altyapının temeli haline geldi
- Geçmişten farklı olarak artık açık kaynağı seçmek sorun sayılmıyor; önemli yazılım alanlarında açık kaynak varsayılan seçenek haline geldi
- Şimdi ise sosyal uygulamalar alanında, açık kaynağın 35 yıl önce yaşadığına benzer bir dönüm noktasıyla karşı karşıyayız
- Yeni akım olan 'açık sosyal' ortaya çıktı ve Bluesky'nin AT Protocol'ü bunun en ikna edici uygulaması olarak değerlendiriliyor
Web'in temel yapısı ve kişisel veri sahipliği
- Geçmişte web'de
alice.com, bob.com gibi kişisel adresler vardı; her kullanıcı kendi alanına sahip olur ve üzerinde istediği içeriği özgürce yayınlardı
- Barındırma hizmetinden memnun kalmazsanız başka bir yere geçseniz bile adres aynı kalır, mevcut bağlantılar da bozulmazdı
- Bu nedenle kullanıcılar belirli bir barındırma şirketine bağımlı kalmaz, şirketler de rekabet etmek zorunda olurdu
- Yani web'in merkeziyetsiz tasarımı sayesinde veri kullanıcının elindeydi, şirketler ise yalnızca sağlayıcı rolündeydi
Modern sosyal ağlar: Veri sahipliğinin kaybı
- Günümüzde insanlar kendi sitelerini işletmek yerine, şirketlerin verdiği
@alice, @bob gibi kimliklerle sosyal medya uygulamalarında paylaşım yapmayı tercih ediyor
- Gönderi, yorum, beğeni gibi veriler belirli bir sosyal şirketin veritabanında saklanıyor
- Bu yapı sayesinde arama, akış, öneri, bildirim gibi sosyal toplulaştırma işlevleri ortaya çıkıyor
- Ancak bunun sonucu olarak çekirdek veriler artık bize ait olmuyor
- Kullanıcılar, oluşturdukları veri ve ilişkileri özgürce yanlarında götüremedikleri bir duruma düşüyor
Sorun: Platforma hapsolmuş kullanıcılar
- Kullanıcı ayrıldığında kendi kurduğu bağlantıların tamamını geride bırakmak zorunda kalıyor
- Barındırma sağlayıcısını kolayca değiştiremiyor; platformdan ayrılınca bağlantılarını ve verilerini de kaybetme sorunu ortaya çıkıyor
- Platformlar bunun farkında olduğu için kullanıcılar aleyhlerine yapılan değişikliklere (aşırı reklam, algoritmanın bozulması, özellik kaldırılması vb.) katlanmak zorunda kalıyor
- Veri yedekleme ya da dışa aktarma yapılsa bile bu, sosyal bağlamını yitirmiş 'ölü veri' olmaktan öteye gidemiyor ve başka yerde yeniden canlandırılması zor oluyor
Açık sosyal: Veri sahipliğinin ve ağın geri kazanılması
- Açık sosyalde @alice.com gibi alan adı tabanlı handle'lar üzerinden kullanıcılara sosyal verileri üzerinde fiilî sahiplik veriliyor
- İsim,
@alice.com gibi sahip olduğum alan adıyla ilişkilendiriliyor
- Kullanıcılar kişisel depo (repository) aracılığıyla ürettikleri tüm sosyal verileri doğrudan yönetiyor
- Yazılar, yorumlar, takipler gibi etkinlikler kişisel depoya (repo) kaydediliyor
- Depo basit bir web sunucusu ve JSON formatındaki kayıtları saklıyor
- Adresler
at://alice.com/... biçiminde olduğu için birbirine bağlanabiliyor
- AT Protocol tabanlı depolar DNS, HTTP ve JSON üzerinde çalışıyor; her veri parçası hyperlink verilmiş JSON biçiminde saklanıyor
- Teknik bilgisi olmayan kişiler için bile uygulamaya kayıt sırasında depo otomatik olarak oluşturuluyor; böylece veri uygulamadan bağımsız biçimde kullanıcının mülkü olarak kalıyor
- Veri, kullanıcının deposunda sahipleniliyor; hizmet sağlayıcısı değişse bile veri sahipliği ve bağlantılılık korunuyor
Açık sosyal uygulamaların yapısı ve kullanım alanları
- Her açık sosyal uygulama, bir CMS gibi, kullanıcının sosyal deposunun bir bölümünü yönetiyor; uygulama artık yalnızca kullanıcının deposuna yazıp okuyan bir araç haline geliyor
- Örneğin Bluesky, Tangled, Leaflet gibi farklı uygulamaların verileri tek bir kullanıcının deposunda bir arada bulunabiliyor
- Bluesky'de bir şey yazdığımda kayıt depoma ekleniyor; Tangled'da bir projeye yıldız verdiğimde o da depoma giriyor
- Veri formatları, çakışmayı önlemek için namespace'lerle ayrılıyor (ör. app.bsky.post, sh.tangled.star)
- Zamanla depom, birçok uygulamadan gelen verilerin bir koleksiyonu haline geliyor
Verinin açılmasıyla ekosistemde yaşanan değişim
- Veri açık biçimde saklandığı için uygulamalar arası entegrasyon, yeni hizmet geliştirme, birbirinin verisini serbestçe referans alma, yeniden kullanma ve remiksleme kolaylaşıyor
- Bir uygulama kapansa bile veri kullanıcının deposunda kalıyor ve başka hizmetlerde yeniden kullanılabiliyor
- Yeni uygulamalar, mevcut ağ ilişkilerini/verilerini kullanarak 'cold start' (başlangıç ağı kurma sorunu) problemini aşabiliyor
- Bu veri herkes tarafından okunabildiği için başka uygulamalar bunu alıp profil fotoğrafını yükleyebiliyor veya mevcut takip ilişkilerini aynen kullanabiliyor
- Uygulama kapanmış olsa bile veri kullanıcının deposunda kaldığından başka bir uygulama onu yeniden çıkarıp kullanabiliyor
Toplulaştırma (aggregation) ve teknik zorluklar
- Kullanıcı verileri farklı depolara dağılmış olsa da, WebSocket abonelikleri üzerinden veri değişim olay akışı alınarak yerel veritabanına işleniyor
- Büyük relay'ler (aktarım sunucuları) üzerinden tüm ağın olayları alınıyor ve yalnızca gerekli olaylar filtreleniyor
- Veri kayıtları kriptografik olarak imzalanıyor; böylece güvenilirlik ve tutarlılık sağlanıyor
- Örneğin Graze, Slices gibi altyapılar açık sosyal toplulaştırmayı destekliyor
Toplulaştırma işlevi nasıl çalışıyor?
- Her kullanıcının deposu ayrı olsa da uygulamalar, kullanıcı depolarından çıkan gerçek zamanlı olay akışını alıp kendi veritabanlarına kaydediyor
- Bluesky gibi relay sunucuları tüm akışı toplayıp iletiyor, uygulamalar da yalnızca ilgilendikleri olayları seçerek saklıyor
- Bu şekilde oluşturulan veritabanı, arama, akış ve öneri gibi işlevleri hızlı şekilde sunabiliyor
- Veri kayıtları kriptografik olarak imzalanıyor; böylece güvenilirlik ve tutarlılık sağlanıyor: aktarıma güvenmeseniz bile verinin doğruluğunu doğrulayabiliyorsunuz
- Graze, Slices gibi altyapılar açık sosyal toplulaştırmayı destekliyor
Büyük resim
- Geçmişteki web: Kullanıcı kendi içeriği ve adresi üzerinde söz sahibiydi
- Günümüz sosyal uygulamaları: Toplulaştırma işlevleri var ama veri şirketin sahip olduğu veritabanına kilitlenmiş durumda
- Açık sosyal: Toplulaştırma işlevlerini korurken veriyi kullanıcının elinde bırakıyor
- Uygulamalar artık yalnızca kullanıcının verisini toplayıp gösteren bir pencereye dönüşüyor
- Hizmet ortadan kalksa bile veri kalıyor; başka uygulamalar onu yeni bağlamlarda yeniden sunabiliyor
Sonuç
- Açık sosyalin özü, kişisel web'in avantajlarını (veri sahipliği, barındırma özgürlüğü, bağlantıların korunması) kapalı sosyal ağların güçlü yönleriyle (toplulaştırma, ölçeklenebilirlik) birleştirmektir
- Açık sosyal, kullanıcı odaklı veri sahipliği, uygulamalar arasında serbest veri taşınabilirliği ve hizmet sürekliliği sağlar
- Açık kaynak nasıl “kod kullanıcıya ait olmalı” diyorsa, burada da “veri kullanıcıya ait olmalı” anlayışı geçerlidir
- Kapalı platformlarda kullanıcıların veri ve bağlantılılığı kaybetmesi sorununu çözer
- Daha fazla açık sosyal ürün ortaya çıktıkça, uygulamalar arasındaki sınırlar silikleşecek ve verinin doğal biçimde aktığı bir ekosistem gelişecek
- Sonunda kullanıcıların veri ve ağ üzerinde fiilen kontrol sahibi olduğu bir gelecek mümkün olabilir
- İlk aşamada bunu az sayıda tutkulu geliştirici ve kullanıcı sürükleyecek olsa da, ortak temel biriktikçe bir gün açık yaklaşımın kazanma ihtimali yüksek
- Merkeziyetsizlik ya da federasyon gibi teknik kavramlar bilinmese bile somut faydalar (veri birlikte çalışabilirliği, kolay taşıma, süreklilik) hissedilebilir
- Açık sosyal, tutkulu toplulukların uzun vadeli çabası ve birikimli etkisiyle giderek yaygınlaşacak
3 yorum
Instagram’ın da anıları saklayan bir yer olduğu doğru, ama oradan istediğiniz gibi çıkmak pek kolay görünmüyor.
Veriyi paylaşma ve kullanma açısından, bir noktada taviz verilmesi gereken taraflar olduğunu da düşünüyorum.
KakaoTalk... s
Hacker News görüşleri
AT Protocol, Bluesky’nin sistemi olduğu için ilk başta ActivityPub’ın kurumsal bir sürümü gibi görünmüştü; ama bu yazıyı okuyunca verinin benim seçtiğim bir "depo (repository)"da saklanma biçimi oldukça hoşuma gitti. Bu, genel prensibimle de örtüşüyor; filtreleme gibi işlemlerin yazma aşamasında değil okuma tarafında yapılmasının daha iyi olduğuna inanıyorum. Yani istediğim her şeyi kendi depoma koyup, başkalarının onu okuyup kullanabilmesi iyi bir yapı. Oklar, yorumlar benim depoma giriyormuş gibi görünüyor ama bu, fikri anlatırken ortaya çıkmış küçük bir isabetsizlik gibi. Genel olarak çok havalı ve dağıtık bir yapı gibi hissettiriyor. Ancak AT’de ayrı bir PDS’yi gerçekten kendim çalıştırmaya kalkınca, oldukça pürüzsüz ve iyi paketlenmiş olsa da bazı önkoşullar olduğunu fark ettim:
İki tür ok kullanarak kafa karıştırmış olabilirim. Düz çizgili ok (@alice.com’dan aşağı inen), sahipliği gösteriyor. Renk gruplamasıyla aynı şey. Mavi olanların hepsi Alice’e ait demek. Kesik çizgili oklar ise kayıtlar arasındaki bağlantılar. Bunlar, <a href> ile aynı şekilde, hangi depoda olursa olsun herhangi bir kaydı başka bir kayda serbestçe bağlayabiliyor. Biri benim gönderime yorum yaptığında, o yorum yorumu yapan kişinin deposuna gidiyor ve asıl gönderiyle bir bağlantı oluşuyor. Veri modelini böyle tasarlamamın nedeni, indeksleme yapan kişinin iki kayda da sahipse ilişkiyi kolayca yeniden kurabilmesi. Örneğin Bob, Alice’in yazısına yorum yaparsa, Bob’un yorumu Bob’un deposunda, Alice’in yazısı Alice’in deposunda olur. Biri benim gönderime yorum yazarsa, o yorum her zaman o kişinin deposunda kalır. Başkasının deposunda kayıt oluşturamamak temel varsayım.
Varsayılan PDS paketlemesi SSL işlemlerini otomatik destekliyor ama bu zorunlu değil; geliştiricinin kolayca uygulayabilmesi için böyle yapılmış. at:// URI’leri at://DID/... biçiminde ve insanlarca okunabilen handle’lar DNS TXT kaydı (_atproto.roshangeorge.dev) üzerinden DID’ye eşleniyor. DID, sunucunun konumunu belirten bir belgeye bağlanıyor; dolayısıyla HTTPS/WSS rotaları herhangi bir yerde olabilir. Ayrıca gönderilerime gelen beğeniler, yanıtlar vb. o eylemi yapan kişinin deposuna yazılıyor, benim depoma değil. Bu konudaki sezgin doğruydu.
ActivityPub’ın daha iyi bir protokol, AT’nin ise sadece ucuz bir taklit olduğunu düşünüyordum; ama bu yazıyı görünce AT’nin çok daha iyi olduğunu fark ettim. Asıl kilit nokta, birden fazla programın aynı kimliği paylaşabilmesi. Bu gerçekten müthiş bir özellik ve ufuk açıcıydı.
ATProto hakkındaki açıklamaların çoğu veri sahipliğine odaklanıyor ama aslında veri işleme tarafında ActivityPub daha güçlü. ATProto, dünyaya herkese açık bakan bir yapıda; bu yüzden tüm olaylar güvenilen küresel bir AppServer tarafından görülüyor ve doğrudan değerlendirilmek zorunda kalıyor, dolayısıyla feed üretimi, erişim izinleri vb. için güvenilir aracılara bağımlı olunuyor. ActivityPub ise daha çok RSS ya da e-posta gibi; sunucum yalnızca benim abone olduğum feed’leri yönetiyor ve inbox, erişebildiğim gönderilerden doğrudan oluşuyor. Bluesky’de Twitter’daki gibi "özel beğeni" yapılamamasının nedeni de bu. Her AppView’in ağdaki tüm gönderilerin beğeni sayılarını bizzat takip etmesi gerekiyor, bu da çok zahmetli. Uzun vadede ActivityPub yapısının daha avantajlı olacağını düşünüyorum. Ayrıca “birden fazla programın aynı kimliği paylaşması” meselesi aslında ActivityPub’ın ilk tasarımlarında da vardı. Sadece en popüler ilk uygulamalar, mevcut yapılara uydurmak için bunu çıkardı.
AT ile AP tartışması o kadar karmaşık ki. Bizim toplulukta da defalarca konuşuldu; bakmaya değer bir başlık bırakıyorum: https://github.com/bevyengine/bevy/discussions/18302
Bu tarafının sana hitap etmesine sevindim. Sürekli AP ile kıyaslanması yorucu, çünkü kapsamları baştan farklı.
Benzer bir bakışı dağıtık sistem mühendisi perspektifinden ele alan bu yazı da ilginç olabilir: https://atproto.com/articles/atproto-for-distsys-engineers
O zaman merkezi bir kimlik hizmeti mi var diye merak ediyorum.
Hangi dağıtık protokol kazanırsa kazansın fark etmez ama ATProtocol teoride iyi görünse de pratikte ActivityPub bana giderek daha çekici geliyor. Ben Lemmy’yi sık kullanıyorum ve oldukça canlı, eğlenceli.
Mastodon’dan farklı olarak AT’de instance kavramı baştan farklı. Bluesky altyapısı içinde de birden fazla PDS var ve yapı olarak hiyerarşik biçimde farklı çalışıyorlar (ilgili yazıya bakın). Buna tek bir baskın instance demek doğru değil. Elbette bir şirketin protokolü keyfine göre yönlendirme riski gerçek bir endişe. Ama şu ana kadar iyi bir steward oldukları söylenebilir. Ekosistem büyüdükçe bunun giderek çözüleceğini düşünüyorum. Ayrıca Bluesky’nin kapanıp taşınmanın imkânsız hâle gelmesi ihtimali de var, ama Protocol’ün içinde yedekleme ve taşıma yerleşik geliyor. Elinizde CAR dosyası varsa istediğiniz zaman başka bir host’a geçebilirsiniz. Mastodon’da hesap taşırken çok şey kayboluyor ama atproto’da geçiş %100 şeffaf yapılabiliyor.
Sonuçta ister Bluesky ister Mastodon olsun, girince hep Amerikan siyaseti konuşuluyor. Haftalık siyasi dramaları pek sevmediğim için Tumblr, Pinterest ya da TikTok gibi daha çeşitli platformlar bana daha uygun galiba.
Mastodon, ActivityPub ile tamamen aynı şey değil ama yanıtların bir anda kaybolabilmesi yüzünden güven vermiyor. Bazı gönderiler duruyor, sonra yine kayboluyor; Mastodon’dan ayrılmamın iki nedeninden biri buydu.
Her uygulamanın kendi koleksiyon tiplerini kullanması ve aralarında koleksiyon paylaşımı mümkün olsa bile, uygulamaların gerçekten birbiriyle uyumlu çalışıp çalışmayacağının net olmaması biraz hayal kırıklığı. ActivityPub’ın güzel taraflarından biri, Mastodon kullanıcısının Pixelfed kullanıcısını özel olarak düşünmek zorunda kalmadan takip edebilmesi. Sanki Twitter, Instagram, Reddit, YouTube ve Substack hiçbir ek ayar gerektirmeden otomatik bağlanıyormuş gibi.
AP’de temelde Status ve Question tiplerinde hizmetler arası iyi bir birlikte çalışma var. Mastodon, Pixelfed, Misskey, Pleroma vb. hep bu sistem etrafında dönüyor. Ama bunun dışındaki tip desteği çok sınırlı, dolayısıyla başka içerik türleri gerçekten iyi desteklenmiyor. Sorun, standart dışı genişletmeler için topluluğun yeterince organize olmaması. ATproto ise veri koleksiyonlarının lexicon/schema tanımlarına mutlaka uymayı gerektiriyor ve referans ile üçüncü taraf uygulamalar şema doğrulaması sağlıyor. Bu yüzden temel uyumluluk daha net ve yapısal biçimde tanımlanmış durumda; ama bence bazı ek alanlar gibi şeyler için isteğe bağlı desteğe de izin vererek biraz daha esnek olması gerek. Bridgy Fed’in APub’dan gelen veriye kaynak URL, metin gibi metadata eklemesi buna bir örnek. (https://fed.brid.gy/docs#bluesky-fields bkz.)
Ortak lexicon’ları iyileştirmeye yönelik çalışmalar sürüyor: https://github.com/lexicon-community
"Yeni nesil Twitter" olmayı vaat eden projelerin sorunları çözme biçiminin biraz ıskaladığını düşünmeye başladım. Twitter işlevlerini kusursuz kopyaladıktan sonra kullanıcı ve içerik eksikliği, yani tavuk-yumurta problemine takılıyorlar. Sonuçta insanlar insanın olduğu yere gidiyor ve o yer hâlâ Twitter. Buna karşılık, OpenAI’nin yakın zamanda çıkardığı timeline gibi, önce arka planda veri toplayıp sonra bunu kullanıcıya sunan yön bana daha doğru görünüyor. Somut uygulama farklı olabilir ama yön duygusu doğru gibi. Kullanıcıların çoğu tweet yazma özelliğine büyük değer vermiyor; asıl değer veri tüketiminde, yani içerik tedarikinde. Bu açıdan çoklu sosyal RSS okuyucu + P2P seçeneği bana daha iyi bir yön gibi geliyor. Kişisel görüşüm.
Yazıda anlatıldığı gibi, ilk çerçevede mikroblog kullanılıyor ama gerçekte Twitter benzeri şeylerin ötesinde çok farklı biçimler mümkün. Örneğin Tangled, "Github on atproto"; Leaflet ise "Medium on atproto". İstemci tarafı P2P yaklaşımının sınırı, büyük ölçekli aggregation ve tutarlılığı garanti etmenin zor olması; oysa bunlar çoğu sıradan kullanıcının sosyal uygulamalardan beklediği temel şeyler. OpenAI örneği de atproto’nun güçlü olduğu alanlardan biri. Veriler zaten ağda bulunduğu için crawling, indexing ve automation araçlarını kolayca ekleyebilirsiniz. Erken bir örnek olarak https://github.com/graze-social/iftta incelenebilir.
Sosyal ağlar, “aynısının biraz fazlası!” modeliyle değil, önceki platformlarda mümkün olmayan yeni kullanım biçimleri çıktığında büyür.
İşte bu yüzden Nostr farklı! Blog, Twitter benzeri hizmet, streaming service, messenger, ne istersen yapılabilir. Örnekler: https://nostrapps.com
Ücretsiz bir üst düzey alan adı (TLD) mümkün olur mu diye merak ediyorum. Gerçekten alan adı kaydının maliyeti ne? Let’s Encrypt’in sertifikaları ücretsiz vermesi gibi, neden bir kâr amacı gütmeyen kuruluş alan adlarını da ücretsiz veremesin? Güzel görünmesi şart değil. Birkaç UUID v7’yi peş peşe dizmek de sorun değil; yeter ki dünya çapında benzersiz ve ücretsiz olsun. Tarayıcı bağlandıktan sonra zaten hatırlayacaktır, o yüzden uzun adresler de sorun değil. Bu fikir gerçekten bu kadar mı kötü?
atproto’da bunu did:plc üstleniyor. https://web.plc.directory/ üzerinden ücretsiz kimlik alınabiliyor. Örneğin benim kimliğim https://plc.directory/did:plc:3danwc67lo7obz2fmdg6jxcr. Alan adının TXT kaydıyla bunu ilgili did:plc’ye bağlayabilirsiniz.
Ücretsiz TLD pratikte gerçekleştirmesi zor bir şey. TLD’ler ve public suffix list için çeşitli kurallar, maliyetler ve yönetsel özellikler var; bkz. https://github.com/publicsuffix/list. Ama TLD değil de normal alan adları oldukça serbest kullanılabilir ve ücretsiz alt alan adları dağıtmak da mümkün. Yalnız böyle bir hizmeti gerçekten işletmeye kalkınca kısa sürede spam/phishing ve internetin karanlık tarafının saldırılarıyla uğraşıp buna giriştiğinize pişman olursunuz. Herkesin bir URL yönlendirici yapabilmesi ama onu işletmenin bambaşka bir mesele olması gibi; düzgün işletmeye başlayınca hemen sorunlar çıkıyor. Ne yazık ki gerçek bu.
Bu, fiilen IPv6 adresi dağıtımına benzer bir fikir. Bugün çoğu ev interneti /64 ölçeğinde public IPv6 alıyor ama ISP’ler çoğunlukla port firewall uyguladığı için pratik kullanım sınırlı kalıyor. Üstelik ISP değiştirince adresi kaybetmek de kolay. Bunu gerçekten kalıcı ve taşınabilir bir IPv6 adresine dönüştürmek için birey ölçeğinde provider-independent adres alanını ücretsiz dağıtmak ve bunu BGP ile küresel yönlendirmeye bağlamak gerekir. Teoride mümkün ama henüz yapılmadı; Let’s Encrypt öncesi sertifika dünyasına benziyor. DNS tabanlı adlandırmanın neden gerekli olduğundan emin değilim ama kısa ve akılda kalıcı olmayacaksa DNS çok uygun da sayılmaz. Yine de ngrok benzeri şekilde kendi gTLD’niz altında alan adı dağıtmak denenebilir. Nitekim .me ccTLD bir dönem bunu ücretsiz yapmış ve karşılığında tüm trafiğe aradaki proxy sunucular üzerinden reklam enjekte etmişti.
.tk ücretsizdi ve kayıt sayısına göre dünyanın en büyük ccTLD’siydi. Ama çoğunlukla kötüye kullanım için kullanıldı. Facebook, işletmecisi olan Hollandalı Freenom’u phishing’e göz yummakla suçlayıp dava açınca artık ücretsiz değil.
Geçmişte .FREE TLD girişimi vardı ama uygulama sorunları ve sürelerin kaçırılması gibi nedenlerle şimdi sönümlenmiş durumda: https://icannwiki.org/.free
Dan’in yazısını görünce tıklıyorum. Açık web’in ilk giren avantajı sayesinde başarılı olmuş olmasından biraz endişeliyim. Öte yandan açık kaynağın başarılı olduğunu görünce umutlanıyorum. atproto gibi bir şeyin başarılı olduğu bir dünya görmek isterim. Daha iyi uygulamaların sırf ağ etkisi yüzünden başarılı olamaması gerçekten üzücü.
HTML başarılı oldu çünkü “ücretsiz”di. O dönemde pek çok ücretli hypermedia standardı vardı ama HTML onlara kıyasla çok daha erişilebilirdi. İnsanlar kolayca tarayıcı ya da sunucu yazabiliyordu.
ATProto’nun ağ etkilerinin sınırlarını kıracak şekilde tasarlanmış olması da büyük avantaj. Herkes atproto tabanlı sisteme geçtiğinde, sosyal ağı “son bir kez daha” taşımak yeterli oluyor. Nihayetinde bu, merkezsiz ve serbest rekabetin mümkün olduğu bir ortam sunuyor.
Gerçekte böyle bir sistemin geniş kitlelere yayılabileceğini hayal etmek zor. Geleneksel sosyal medya hedef kitlesi ile merkezsizlik odaklı kullanıcı kitlesi bambaşka. Çoğu insan platformu sadece bir araç olarak görüyor, sistemin kendisiyle ilgilenmiyor. Sonunda herkes sadece bir bluesky hesabı açarsa, yine birkaç büyük hizmette toplanılmış olur ve anlamı kalmaz.
Herkes bsky.social’da toplansa bile bugüne kıyasla muazzam bir ilerleme olur. Nasıl ki çok sayıda sunucunun AWS’de olması web’in merkezileştiği anlamına gelmiyorsa, burada da gerektiğinde taşınmak mümkün.
Gerçekte bluesky’de federation hâlâ tam uygulanmış değil. Tüm trafik tek bir "BGS" router sunucusuna bağlı.
Ne yazık ki, sonunda problemin kaynağı yine 'insan'.
Bu konuda duygularım karışık. Bir yandan fikir tam bana göre. Herkesin kendi sahip olduğu içeriğe sahip olması, Indie web hareketiyle aynı çizgide ve bu sayfa ile yazıların kalitesi gerçekten etkileyici. Öte yandan bu standartları kişisel bloglarında ya da açık kaynak projelerinde gerçekten uygulayan geliştirici çok az; vlog/blog sahipleri ve sıradan kullanıcılar arasında da benimsenme düşük. İnsanların veri sahipliği, açıklık ve birlikte çalışabilirlik konularına kayıtsız olması beni düşündürüyor. Sanki herkes sadece TikTok ya da Instagram Reels tarzı feed’ler istiyor. Vizyona ve emeğe saygı duyuyorum ama bunun niş bir hobi olarak kalmayıp ana akıma dönüşüp dönüşemeyeceğini sorguluyorum.
Geliştirici deneyimini daha kolay hâle getirme konusunda yapılacak işler var. Ama bu alanın ilerleme hızı çok yüksek, bu yüzden önümüzdeki 6-12 ayı özellikle heyecan verici buluyorum. Çoğu insan ATProto’nun sadece Bluesky’den ibaret olmadığını, çok daha geniş alanlara uygulanabildiğini henüz kavramış değil; piyasanın bunu daha somut biçimde görmesi biraz zaman alacak.
'Veri sahipliği' fikrinin neden bu kadar önemli olduğu ve halkın bunu umursamamasının neden gerçekten kaygı verici sayılması gerektiği konusunda meraklıyım. Geçmişte insanlar televizyon, kitap, radyo gibi şeylerde de sahiplik olmadan içerik tüketiyordu. Şimdi sadece kendi bir şeyler paylaşma ve çevresinin bunu görmesi imkânı var; bu durumda bir Instagram gönderisinin gerçekten kime "ait" olduğunun bu kadar önemli olup olmadığını sorguluyorum.
Sana katılıyorum. Sonuçta bu teknolojiyi aktif biçimde yaymak ve ana akıma taşımak için bizim çaba göstermemiz gerekiyor; ancak o zaman başarılı olabilir. Bir gün açık sosyal fikrine hayran bir kurucu/CTO gerçekten kitlesel başarıya ulaşan bir uygulama çıkarabilir ve hiçbir şey yapmazsak zaten asla başarılı olamaz.