s@ : statik site tabanlı merkeziyetsiz sosyal ağ

 (satproto.org)
9 puan yazan GN⁺ 2026-03-13 | 1 yorum | WhatsApp'ta paylaş
  • Statik web sitelerini kullanan merkeziyetsiz bir sosyal ağ protokolü olup, her kullanıcının kendi verisini doğrudan sahiplenip yönettiği bir yapı sunar
  • Tüm veriler şifrelenmiş JSON deposunda tutulur ve tarayıcı istemcisi akışı birleştirip gönderileri yayımlar
  • Sunucu veya relay olmadan, arkadaşlar arasında web siteleri ile tarayıcılar arasında doğrudan iletişimle çalışır
  • Kullanıcının alan adı doğrudan kimliğidir ve HTTPS/TLS ile doğrulanır
  • Basit bir yapıyla öz egemen sosyal ağ kurmayı amaçlar ve kişiler arası güvene dayalı etkileşime odaklanır

sAT Protocol genel bakış

  • s@, statik site tabanlı merkeziyetsiz bir sosyal ağ protokolüdür ve her kullanıcı verisini kendi web sitesinde saklar
    • Tüm veriler şifrelenmiş JSON dosyaları biçiminde saklanır; tarayıcı istemcisi bunları okuyarak gönderi yayımlama ve akış toplama işlemlerini yürütür
    • Merkezi sunucu veya relay olmadan çalışır; veriler kullanıcının sitesinden arkadaşının tarayıcısına doğrudan gider
  • Gönderi alışverişi için karşılıklı takip ilişkisi gerekir; influencer merkezli yapı özellikle dışlanır
  • Protokol, GitHub Pages gibi belirli bir barındırma hizmetine bağımlı değildir

Kimlik (Identity)

  • Kullanıcının alan adı kimlik işlevi görür
  • HTTPS/TLS, alan adı sahibinin içeriği yayımladığını doğrular

Keşif (Discovery)

  • https://{domain}/satellite/profile.json yolunda protokol sürümü ve açık anahtar sunulur 
    {
  "satproto_version": "0.1.0",
  "public_key": "<base64-encoded X25519 public key>"
}
  • Varsayılan /satellite/ yolu dışında başka bir yol kullanılacaksa, gerçek depo konumu .well-known/satproto.json dosyasıyla belirtilebilir

Şifreleme modeli (Encryption Model)

  • Tüm kullanıcı verileri şifrelenmiş JSON deposunda saklanır ve yalnızca kullanıcı ile takipçileri tarafından çözülebilir
  • X25519 anahtar çifti kullanılır; açık anahtar profile.json içinde yayımlanır, özel anahtar ise tarayıcı localStorage alanında saklanır
  • Gönderi verileri XChaCha20-Poly1305 ile şifrelenir; içerik anahtarı ise her takipçi için libsodium içindeki crypto_box_seal ile şifrelenir
  • keys/_self.json dosyası kullanıcının içerik anahtarını ve yayımlama sırlarını içerir; bunu yalnızca kullanıcı çözebilir

Anahtar döndürme ve takibi bırakma

  • Takip bırakıldığında yeni bir içerik anahtarı üretilir ve tüm gönderiler yeniden şifrelenir
  • Kalan takipçiler için yeni anahtar zarfları oluşturulur ve keys/_self.json güncellenir
  • Takibi bırakılan kullanıcı artık gönderileri çözemez

Çözme akışı

  • Bir ziyaretçi arkadaşının sitesini açtığında, kendi özel anahtarıyla keys/{follower-domain}.json dosyasını çözerek içerik anahtarını elde eder
  • Ardından posts/index.json ve tekil gönderileri (posts/{id}.json.enc) alıp çözer

Veri yapısı (Data Schema)

  • Her gönderi ayrı ayrı şifrelenmiş bir dosyada saklanır ve posts/index.json gönderi ID'lerini yeniden eskiye sıralar
  • Gönderi nesnesi örneği: 
    {
  "id": "20260309T141500Z-a1b2",
  "author": "alice.com",
  "created_at": "2026-03-09T14:15:00Z",
  "text": "Hello, decentralized world!",
  "reply_to": null,
  "reply_to_author": null
}
  • Gönderi ID'si, ISO8601 UTC zaman damgası ile 4 haneli rastgele bir hash'ten oluşur

Takip listesi (Follow List)

  • https://{domain}/satellite/follows/index.json yolunda düz metin JSON olarak saklanır 
    { "follows": ["bob.example.com", "carol.example.com"] }
  • Şifrelenmez; çünkü takip ilişkisi zaten anahtar zarfları üzerinden açığa çıkar

Akış toplama (Feed Aggregation)

  • İstemci takip listesini okur, her takip edilenin gönderilerini çözer ve zaman sıralı bir akış oluşturur
  • Gönderiler created_at alanına göre azalan sırada dizilir

Yanıtlar (Reply)

  • Yanıtlar, reply_to ve reply_to_author alanları ayarlanmış gönderilerdir
  • İç içe yanıtlar desteklenmez; yalnızca en üst düzey gönderilere doğrudan yanıt verilebilir
  • Orijinal gönderi görülemiyorsa (takip etmeme durumu vb.) yanıt da gösterilmez

Yayımlama (Publishing)

  • Yeni gönderi oluşturma → içerik anahtarıyla şifreleme → statik siteye yükleme → posts/index.json güncelleme
  • Yükleme için GitHub Contents API gibi araçlar kullanılabilir
  • Yayımlama sırları keys/_self.json içinde şifrelenmiş olarak saklanır

Statik site yapısı örneği

{domain}/satellite/
  profile.json              # açık anahtar ve profil
  posts/
    index.json              # gönderi ID listesi
    {id}.json.enc           # şifrelenmiş gönderi
  follows/
    index.json              # takip listesi
  keys/
    _self.json              # içerik anahtarı ve kimlik bilgileri
    {domain}.json           # takipçi başına içerik anahtarı

SSS

  • “RSS + şifreleme mi?” → Evet
  • “AT Protocol'ün firehose olmayan sürümü mü?” → Evet
  • “Ölçeklenebilir mi?” → Hayır (“dostluk da ölçeklenmez”)
  • “s, slow/shitty anlamına mı geliyor?” → Evet
  • “Self-hosting mümkün mü?” → Evet, ancak CORS etkin olmalı

İlgili okumalar

1 yorum

 
GN⁺ 2026-03-13
Hacker News görüşleri

  • Bu projenin de birçok alternatif sosyal / self-hosted ağın yaşadığı sorunları yaşadığını düşünüyorum
    Kriptografi odaklı tasarım havalı olsa da, yeni bir cihaza geçince arkadaş takiplerini geri yüklemek zor ve X25519 anahtar çifti gibi kavramları sıradan kullanıcıların anlaması da güç
    Bana göre sunucunun şifrelemeyi kullanıcı adına hallettiği basit bir kullanıcı adı / parola tabanlı yapı daha gerçekçi
    Asıl büyük teknoloji şirketlerine alternatif olabilecek, teknik olmayan kullanıcıların da kullanabileceği yönün bu olduğunu düşünüyorum

    • Ben de benzer düşünüyorum. Ama aracısız bir dünya istiyorsak, teknik olmayan kullanıcıların da eninde sonunda bazı şeyleri kendilerinin yönetmesine yönelik kültürel bir değişim gerekiyor gibi geliyor
    • İlk kurulumdan sonra özel anahtarı dışa aktarıp bir parola yöneticisinde saklamak yeterli. Protokolü bizzat uygulamayacaksan o kadar da karmaşık değil
      Yine de ailem veya arkadaşlarım için kurulumu benim yapmam gerekebilir. Ama kendi web sitelerine sahip olunca bundan epey hoşlanacaklarını düşünüyorum
    • Yazının sonundaki SSS'ye göre bu, AT Protocol(BlueSky) içindeki bazı unsurları çıkaran kavramsal bir deneye daha yakın
      Pratikte statik bir blogu BlueSky ile entegre etme fikri gibi görülebilir.
      BlueSky kimliğini kullanmak ya da kimlik bilgilerini statik site üreticisi eklentisiyle otomatik almak gibi iyileştirmeler mümkün olabilir
    • Daha önce e-postayı sosyal ağ taşıma katmanı olarak kullanma fikrini denemiştim ama başarısız oldu
      İlgili yazı
    • Hedefin büyük teknoloji şirketlerinin yerini almak olup olmadığından emin değilim. Sadece küçük topluluklar için faydalı olabiliyorsa bile bunu başarı sayarım

  • Özel anahtarın tarayıcının localStorage'ında saklanması kısmı beni şaşırttı
    Tarayıcı ayarları sıfırlanınca veya yeniden kurulunca veri kaybolabilir, yedeklemek zordur ve kötü amaçlı yazılımların erişmesi kolaydır
    Sonuçta anahtar kaybolursa akış da sonsuza kadar yok olur ve bu da kullanıcıların platformdan uzaklaşmasına yol açabilir

    • Katılıyorum. “X25519 anahtar çifti” gibi terimlerin rahatça kullanılması, bu projenin kitlesel yayılımdan çok kavramsal bir deney olduğunu düşündürüyor
    • Bence bu, tek bir “anahtarı güvenli bir konuma dışa aktar” düğmesiyle çözülebilir. URL.createObjectURL(localStorage.getItem(...)) gibi basit bir kodla dosya kaydetmeye yönlendirmek mümkün
    • Mükemmeli ararken “yeterince iyi” çözümü kaçırmamak lazım. Sadece anahtar indirme / yükleme özelliği eklense bile sorunların çoğu çözülür
      Elbette anahtar kaybolursa erişim de gider ama 2FA veya kripto cüzdanı kullanıcıları da benzer sorumluluklar üstleniyor; yani tamamen imkansız bir şey değil

  • /satellite/ yolu yerine /.well-known/ kullanılsa nasıl olur diye öneriliyor
    Well-known URI standardına atıf yapılıyor

    • Buna “.poorly-known” diye esprili bir yanıt verilmiş
    • AT Proto'nun ilk dönemlerinde kök yolun kullanılması yüzünden güvenlik açığı ortaya çıktığını hatırlayıp endişelenenler var
    • .well-knownun tüm host için geçerli olduğunu, bu yüzden akış düzeyinde uygun olmadığını; birden çok dizini ayrı tutmanın daha iyi olduğunu savunanlar da var

  • .well-known/ önerisinin ciddi biçimde değerlendirilmeye değer olduğunu düşünüyorum
    Zaten IANA kayıtlı bir standart olarak yaygın biçimde kullanılıyor ve güvenlik / keşif dosyaları burada bulunuyor
    /satellite/satproto.json yerine /.well-known/satproto.json kullanmak hem çakışmaları önler hem de bunun bir protokol uç noktası olduğunu daha açık gösterir

    • Ama .well-known host düzeyinde çalıştığı için, hesap başına birden fazla dizin isteniyorsa uygun olmayacağı yönünde itiraz geliyor

  • Sosyal ağ protokolleri, teknoloji kendi başına var olsun diye değil, kullanıcıya doğrudan fayda sağlamak için olmalı
    BitTorrent gibi, insanların sadece “ihtiyaç duyduğu için” katıldığı yapılar ağ etkisi yaratır
    Veri yönetimi ve paylaşım kolaylığından yola çıkan yaklaşımın daha gerçekçi olduğunu düşünüyorum

    • Ben çeşitli merkeziyetsiz sosyal ağları denedim; sonuçta insanlar dopamin uyarımı yoksa geri dönmüyor
      Lemmy veya Pixelfed içerik azlığından dolayı “hiçbir şeyin olmadığı yer” gibi hissettirdi
      Signal da benzer şekilde sadece mesajlaşma için, yani “kaydırıp bakmak” için bir sebep vermiyor
      Sonuçta sürekli ziyaret için içerik ve FOMO(kaçırma korkusu) gerekiyor
    • Yine de iyi protokol tasarımı önemli. Fazla karmaşıksa veya geleceğe hazırlıksızsa, ne kadar iyi fikir olursa olsun çabucak kaybolabilir

  • Gerçekten merkeziyetsiz sosyal / E2EE mesajlaşma yapmak istiyorsak, Discord benzeri şekilde her sunucunun gerçekten bağımsız biçimde barındırıldığı bir yapı gerekiyor
    Hesaplar Nostr benzeri bir protokolle yönetilmeli ve IPv4/6 ile DNS bağımlılığını azaltmak için Yggdrasil Network üzerinde çalışmalı
    Trafiği HTTPS ile sarmalayıp NAT aşmayı otomatikleştirirsen herkes sunucu çalıştırabilir
    Ancak böyle bir yapıyla büyük teknoloji şirketleri ve devlet kontrolünden çıkılabilir

    • Ama sadece teknoloji yetmez. Kitleler sonunda pazarlama sermayesi güçlü platformlara akacaktır
    • Bana göre BitTorrent, IPFS gibi önbellek tabanlı dağıtık ağ yaklaşımı daha iyi
      Sunucu ortadan kalksa bile veri uçlarda kalır ve kullanıcı tarayıcısı host görevi görebilir
      ephemeral-p2p-project
    • Bu yapı zaten geogram.radio üzerinde deneysel olarak uygulanıyor
      Her cihaz sunucu gibi çalışıyor ve WebRTC ile tam P2P mesajlaşma gerçekleştiriyor
      İnternet olmasa bile radyo bağlantısıyla veri alışverişi mümkün
    • Ben de Mikoto Platforms'ta benzer bir şey geliştiriyorum. “Spaces” fiziksel düğümlerden herhangi birinde var olabiliyor ve DM'ler birden çok düğüm üzerinden E2EE yönlendirmesiyle taşınıyor

  • Geçmişte FOAF veya Pingback gibi tamamen merkeziyetsiz sosyal girişimler vardı

    • Bunun modern versiyonu Webmention
      IndieWeb wiki'si, kişisel web tabanlı sosyal teknolojileri keşfetmek için iyi bir kaynak olarak öneriliyor
    • Bir diğer örnek olarak XFN'i de unutmamak gerek

  • “sAT Protocol, statik siteler tabanlı merkeziyetsiz bir sosyal ağdır” açıklamasını okurken giderek yükselen kaş grafiği çizmek istedim

    • Yine de hedef kapsamı dar olduğu için makul bir sistem gibi geliyor
      Ancak şifreli metinlerin herkesçe listelenebilir olması, kuantum bilgisayar çağında risk yaratabilir
    • Bu, PGP + RSS birleşimine benziyor. Her akış şifreleniyor ve yalnızca ilgili kişi çözebiliyor
      Küçük ağlar için uygun ama anahtar dağıtımı ve rotasyonu sorunları yüzünden büyük ölçekte genişlemesi zor
    • Bunu “veritabanını aktarıp istemcinin statik siteyi derlemesi” fikri olarak anlıyorum
    • “Key Rotation (Unfollow)” bölümü ASCII art ile şaka gibi anlatılmış

  • Kullanıcı açısından bunun ne işe yarayan bir hizmet olduğu baştan anlatılmalı gibi geliyor
    Fork, yol, JSON, şifreleme gibi teknik terimler çok fazla; gerçek kullanım senaryosu görünmüyor

    • Yine de teknolojiye meraklı epey arkadaşım var; “paranoyak güvenlik zevki” olanlarla bunu denemeyi düşünüyorum
      Mastodon veya Signal'in karşılamadığı bir alan var ve bununla denemeye değer

  • Bu tür merkeziyetsiz ağ deneylerini görmek gerçekten ilginç
    Yapısal olarak pek çok sorun olsa bile yeni kombinasyonlar öğrenmek keyifli
    Ama takip / takipten çıkma olduğunda tüm siteyi yeniden şifreleyip yeniden derlemek zorunda olmak fazla zahmetli
    Ayrıca takip etmiyorsan yorumları görememe yapısı ölçeklenebilirliği ciddi biçimde sınırlıyor
    Yine de RSS, ActivityPub ve statik sitelerin karışımı olması çekici
    Statik siteyle dinamik arkadaş listesi erişim kontrolü uygulamaya çalışmak çelişkili ama ilginç
    Sonuçta hem sevgi hem nefret uyandıran bir yapı. Yine de böyle denemeler görmek güzel ve buna minnettarım