- Dosya merkezli kişisel bilişim kavramını sosyal bilişime genişleterek, kullanıcıların ürettiği tüm içeriğin uygulamalara değil bizzat kullanıcının kendisine ait olduğu bir yapı olarak açıklıyor
- AT Protokolü temelinde, uygulamalar arası veri birlikte çalışabilirliğini mümkün kılan dağıtık bir sosyal dosya sistemi kavramı ortaya koyuyor
- Her kullanıcı kendi ‘everything folder’ına veya deposuna (repository) sahip oluyor ve gönderiler, beğeniler, takipler gibi veriler JSON tabanlı dosyalar (record) olarak saklanıyor
- DID (Decentralized Identifier) ve
at:// URI düzeni sayesinde, hosting değişse veya handle değiştirilse bile kalıcı olarak tanımlanabilen bağlantılar korunuyor
- Bu yapı, uygulama değil veri merkezli bir sosyal ekosistem oluşturarak herkesin mevcut veriler üzerinde çalışan yeni uygulamalar geliştirebilmesini sağlıyor
Dosya paradigması ve sosyal genişleme
- Dosyalar aslında uygulamaların içinde değil, kullanıcının kontrol ettiği bir alanda bulunur; uygulamalar ise yalnızca dosya okuma ve yazma araçlarıdır
.svg gibi açık dosya formatları, birden fazla uygulamanın aynı veriyi paylaşmasına olanak tanır- “Dosya formatı API’dir” ilkesi altında, uygulamalar arası birlikte çalışabilirlik mümkündür
- Bu kavram sosyal uygulamalara uygulandığında, gönderi, takip ve beğeni gibi eylemler de dosya gibi ele alınabilir
- Kullanıcının tüm çevrimiçi etkinliğini içeren bir ‘everything folder’ bulunur
- Uygulamalar bu klasördeki veriyi yansıtır ve klasör tek gerçek kaynak (source of truth) işlevi görür
AT Protokolü ve sosyal dosya sistemi
- AT Protokolü, bu yapıyı fiilen hayata geçiren teknoloji olup Bluesky, Leaflet, Tangled, Semble ve Wisp bunun üzerinde çalışır
- Uygulamalar kullanıcı verisine sahip olmaz; dosya düzeyinde ayrılmış veri depolama sayesinde yeni uygulamalar mevcut veriyi yeniden kullanabilir
- Tüm kullanıcı klasörleri birleşerek dağıtık bir sosyal dosya sistemi oluşturur
Record ve collection yapısı
- Her gönderi bir JSON dosyası (record) olarak ifade edilir ve yazar bilgisi ya da türetilmiş verileri (beğeni sayısı gibi) içermez
- Örnek:
{ text: 'no', createdAt: '2008-09-15T17:25:00.000Z' }
- Dosya adı, çakışmaları önlemek için zaman damgası tabanlı bir anahtar (record key) ile oluşturulur
- Dosya yapısı, lexicon adı verilen bir şema ile tanımlanır ve her uygulama kendi lexicon’unu tasarlayabilir
- Örnek:
com.twitter.post, fm.last.scrobble, io.letterboxd.review
- Aynı kavram için bile uygulamadan uygulamaya farklı lexicon’lar olabilir; çakışmalar alan adı tabanlı namespace ile önlenir
Doğrulama ve güven
- Bir Lexicon Police yoktur — hiçbir uygulama başka bir uygulamanın verisini dayatamaz
- Uygulamalar gelen veriyi okuma sırasında doğrular (validate on read) ve geçerli değilse yok sayar
- Lexicon değiştirildiğinde geriye dönük uyumluluğun korunması zorunludur; kırıcı değişiklikler yeni bir lexicon’a ayrılır
- Lexicon’lar herkese açık biçimde dağıtılabilir ve DNS üzerinden alan adı sahipliği kanıtı sağlanabilir
Bağlantılar ve kimlik (Identity)
- Kullanıcıların oluşturduğu beğeni veya yanıtlar başka record’lara referans vermek zorunda olduğundan, kalıcı bir bağlantı düzeni gerekir
- Birden fazla denemenin ardından kimlik için DID (Decentralized Identifier) kullanılmıştır
did:plc:6wpkkitfdkgthatfvspcfmjo gibi tanımlayıcılar değiştirilemez- Her DID, güncel hosting, handle ve açık anahtar bilgisini taşıyan bir belgeye çözümlenir
at:// URI’leri, DID, collection ve record key’i birleştirerek hosting değişse bile kırılmayan bağlantılar sağlar
- Örnek:
at://did:plc:6wpkkitfdkgthatfvspcfmjo/com.twitter.post/34qye3wows2c5
JSON hiperbağlantıları ve ilişkilerin ifadesi
- Her beğeni, repost ve yanıt, başka bir record’a referans veren hiperbağlantı türünde JSON yapısıdır
- Örnek:
parent alanı, başka bir gönderinin at:// URI’sine referans verir
- Arayüzde görülen tüm bilgiler (yazar, metin, beğeni sayısı vb.) bu dosyalar arasındaki bağlantılardan hesaplanabilir
Depo (Repository) ve veri akışı
- Kullanıcının ‘everything folder’ı depo (repository) olarak adlandırılır ve DID ile tanımlanır
- İçinde birden fazla collection ve record bulunur
- Depo herhangi bir yerde barındırılabilir ve taşınsa bile bağlantılar korunur
- Uygulamalar depoyu bir dosya sistemi gibi okuyabilir veya akışa (WebSocket) abone olarak gerçek zamanlı senkronizasyon yapabilir
- Her commit, imzalı bir hash ağacı (Merkle tree) ile doğrulanır ve veri sahteciliği önlenir
- Relay sunucuları yalnızca olayları yeniden iletir; doğrulanabilir yapı sayesinde güven sağlanır
Atmosphere keşfi ve gerçek örnekler
- pdsls.dev, bir DID veya handle girildiğinde sosyal dosya sistemi gezgini gibi çalışır
- Her collection ve record doğrudan incelenebilir
- Örnek uygulama Sidetrail, kullanıcının record değişikliklerini gerçek zamanlı yansıtarak verinin uygulamada değil depoda bulunduğunu gösterir
- teal.fm Relay demosu, gerçek bir API olmadan bile
fm.teal.alpha.feed.play record’larını indeksleyerek müzik dinleme geçmişini (scrobble) görselleştirir
- lex-gql aracıyla lexicon tabanlı GraphQL sorguları çalıştırılabilir
- Bluesky içinde kullanıcılar kendi oluşturdukları özel feed algoritmalarını yayımlayabilir
- Örnek olarak
@spacecowboy17.bsky.social hesabının “For You” feed’i bağımsız çalışır ve paylaşılan veri üzerinde üçüncü tarafların işlevleri geliştirebilmesini sağlar
Sonuç
- Sosyal dosya sistemi, uygulama merkezli değil veri merkezli bir internet yapısı önerir
- Kullanıcılar kendi veri depolarına sahip olur ve uygulamalar bunun üzerinde tepkisel biçimde çalışır
- Hedef, “her şeyi yapan bir uygulama” değil, “her şeyin mümkün olduğu bir ekosistem” oluşturmaktır
1 yorum
Hacker News görüşleri
Uygulamalar ortadan kaybolabilir ama dosyalar kalır
swyx'in yazısı, uzun ömürlü işlerin eninde sonunda dosya/veri biçiminde var olduğunu vurguluyor
Veri, izin gerektirmeden ayrıştırılabilir ve kısmen bozulsa bile hâlâ işe yarar; ancak ekonomik teşvikler hâlâ kod etrafında dönüyor
Standartlar ortaya çıkıp kodun veri alıp vermesini sağladığında, bunun tüm medeniyet için büyük bir değeri olur
Geliştirici ekosisteminin, Google, Microsoft, OpenAI ve Anthropic gibi şirketleri veri standardizasyonuna gönüllü olarak katılmaya yönlendirmesinin elimizdeki en güçlü kaldıraçlardan biri olduğunu düşünüyorum
Ama bugünün uygulamaları reklam geliriyle yaşayan web siteleri biçiminde, bu yüzden böyle bir yapıyla çalışmaları için hiçbir teşvik yok
Sadece Apple'a bakmak bile standartların her zaman dünyayı değiştirmediğini göstermeye yeter
Eğer
createdAtalanı keyfi bir değerse, istediğim gibi kayıtları geriye dönük olarak değiştirebilir miyim?İmzalama (
signing) yoluyla oluşturulma zamanını ve sonradan değiştirilip değiştirilmediğini doğrulamanın bir yolu olup olmadığını merak ediyorumPOSSE ve AT Protocol, birlikte çalışabilen pazar yerleri olarak anlaşılabilir
Reddit ya da Instagram'da olduğu gibi kullanıcı içeriği üründür, dikkat para birimidir ve platform reklam ya da davranış verisinden gelir elde eder
Ama bu yapı kaçınılmaz değil
Kullanıcı kendi sosyal verisinin sahipliğine sahip olursa, uygulama veriyi okuyan bir arayüze dönüşür
Ben de benzer bir modeli ticarete uyguluyorum — satıcı kendi sipariş ve ödeme mantığını doğrudan barındırıyor, pazar yeri de satıcının API'siyle doğrudan entegre oluyor
Böylece platform komisyonları azalıyor ve sahiplik değeri üreten tarafa geri veriliyor
Yazı fazla detaylıydı; ana fikri aktarmak için biraz ağır geldi
Yine de benzetme çok başarılı. PDS için bir dosya tarayıcısı olsaydı doğrudan deneyimlenebilirdi
Bluesky'nin PDS'si temelde herkese açık bir dosya sistemi ve Git'te olduğu gibi çoğaltma (
replication) tasarımın bir parçasıÇoğaltma kontrol edilemez ama otomatik yedekleme avantajı da getiriyor
Sonuçta PDS'ye yüklenen şey kalıcı kayıt gibi kaldığı için dikkatli olmak gerekir
Faydalı ama uzunsa, başkaları ihtiyaç duyduğu kısmı alabilir
Yazının sonundaki demo bölümü gerçek bir dosya yöneticisi örneği gösteriyor
“Herkesin scraper olduğu bir dünya” ifadesi özünü anlatıyor
“Dosya” kavramının zaten eski kaldığını düşünüyorum
Her şeyi hash tabanlı blob veri olarak ele almak birçok sorunu ortadan kaldırır
Kullanıcının istediği şey uygulama değil, yetenek (capability)
Örneğin istediği şey YouTube ya da Bluesky'nin kendisi değil, “yoga videosu izleyebilme” ya da “tanıdıklarla güncel durumunu paylaşabilme” yeteneğidir
Uygulamalar sadece bu yeteneklerin paketlenmiş hâlidir
Mesajlaşma uygulamasında bir kelimeyi arayıp sonucu doğrudan sohbet penceresinde paylaşabildiğiniz türden özelleştirilmiş iş akışları gerekiyor
PerKeep'ten ilham aldım
Bunu “uygulamalarla dosya formatları arasındaki çoktan çoğa ilişkiyi” anlatmak için kullandım
ATProto'nun repository yapı açıklamasına bakarsanız, bunun Merkle-tree tabanlı içerik adreslemeli bir yapı olduğunu görürsünüz
Lexicon uygulamalarla 1:1 ilişkili değil, dolayısıyla AT zaten uygulama sonrası (post-app) döneme yöneliyor
Ben kapalı platformların (walled garden) tüketici tercihinin sonucu olduğunu düşünüyorum
İnternet her şeyi açınca insanlar belirli kültürler ya da fikirler etrafında küçük alanlar istemeye başladı
IG ya da Snap böyle ayrışmış grup sohbetleri gibi
IG gönderimin HN ya da Truth Social'da otomatik paylaşılmaması bana daha iyi geliyor
Veri taşınabilirliğinin değeri bana çok anlamlı gelmiyor. Bağlamı farklı platformlar arasında geçiş yapmak anlamsız hissettiriyor
Benim yaptığım Anisota, hem Bluesky hem Leaflet dosyalarını destekleyecek şekilde tasarlandı
Örnek olarak aynı gönderiyi Bluesky ve Anisota üzerinde ayrı ayrı görebilirsiniz
Ayrıca Aturi adlı projeyle ATProto tabanlı içerik için genel bağlantılar sağlıyorum
ATProto'da aynı Lexicon'u kullanan uygulamalar arasında kimliğin ve verinin tamamen taşınması mümkün
Orijinal görseller zaten yerelde bende duruyor, her platform sadece farklı bir sunum biçimi
Platformlar arasında anlamsız entegrasyonlar istemiyorum
AT sadece birlikte çalışabilirliği mümkün kılıyor, her şeyi birleştirmiyor
Örneğin Leaflet, Bluesky gönderilerini alıntı takibi için içe aktarıp gösteriyor
Bu yapı sayesinde ürünü fork'lasanız bile ağla tamamen uyumlu kalıyor ve rekabet canlanıyor
Nitekim Blacksky, Bluesky'yi fork'layıp farklı moderasyon politikaları uygulayan bir örnek
Dan'in yazıları her zaman ilgi çekici. Okurken sonunda yazanın o olduğunu anlıyorsunuz
Kendini tanımlayan veri modeli (self-describing data model) konusunda şüpheliyim
ATProto'nun “sadece Lexicon eklenince istemci oluşur” iddiası abartılı geliyor
Gerçekte bir UI yapmak için verinin ne anlama geldiğini bilmek gerekiyor ve Lexicon tek başına yeterli değil
Sonuçta belgeye bakıp kendin uygulamaktan çok da farklı değil
Standardizasyon iyi ama bunun küresel ölçekte kopyalanan bir veritabanı düzeyinde ele alınması şart değil
Yine de lock-in etkisini azaltma çabasını takdir ediyorum
Ama Twitter'ın yaşadığı asıl sorun, siyasi içerik ya da spam gibi toplumsal etkenlerdi
Ama Bento gibi sevilen bir hizmet ortadan kalkarsa, biri o veriyi geri getirmeye çalışacaktır
Örneğin Blento, ATProto tabanlı bir Bento alternatifi ve açık kaynak olduğu için herkes yeniden ayağa kaldırabilir
Böyle bir yapı, kullanıcı içeriğinin kalıcılığını güvence altına alma açısından anlamlı bir ilerleme
“The Unix Programming Environment”i okurken, basit araçlar ve metin dosyalarıyla bile çok şey yapılabildiğini fark ettim
Slack, dosya merkezli UNIX tarzında yapılmış olsaydı nasıl olurdu diye düşündürüyor
Basit ve birleştirilebilir sistemlere geri dönmek istiyorum
İnsan tarafından okunabilir serileştirme iyi ama her seferinde ayrıştırıp yeniden biçimlendirmek acı veriyor
Yeni sosyal platformların dağıtık/federe ortamda ortak protokoller ve veri formatları paylaşması fikri ilgi çekici
Ama mevcut ticari platformları buna ikna etmek zor görünüyor
Böyle standartlar yerleşirse sosyal pazarlama araçları birden fazla ağı birlikte yönetmeyi daha kolay yapabilir
Ancak gerçeklikte hâlâ Facebook, Instagram ve TikTok gibi kapalı ekosistemler baskın