at://’nin yeri neresi

• AT protokolü, merkeziyetsiz sosyal ağların temelini oluşturan bir protokoldür ve tüm veriler at:// URI ile tanımlanır
• at:// URI, verinin oluşturucusunu (kullanıcıyı) authority olarak belirtir; bu verinin gerçekte barındırıldığı konum ise ayrıca bulunmalıdır
• URI çözümleme süreci şu sırayla ilerler: handle’ı kimliğe (DID) dönüştürme, DID belgesi üzerinden barındırma sunucusunu bulma ve ardından o sunucudan JSON verisini isteme
• İki tür DID yöntemi (did:web, did:plc) desteklenir ve her birinin artıları, eksileri ve veri koruma biçimi farklıdır
• Bu yaklaşım, veri sahipliğinin kullanıcıda olduğunu vurgular ve handle ile barındırma değişse bile bağlantının korunmasını sağlayan kalıcılığı garanti eder

---

AT protokolü, at:// URI ve sosyal verilerin kimlik çözümleme süreci

# AT protokolü ve at:// URI’nin temel yapısı

• AT protokolü, dağıtık birçok sunucunun belirli bir standarda göre iletişim kurmasını sağlar ve bunların bütününe 'atmosphere' adı verilir
• atmosphere içindeki her veriye, at:// ile başlayan benzersiz bir URI atanır; bu URI bir bakıma JSON verisine giden bağlantı işlevi görür
• Geleneksel URI yapılarının aksine, AT protokolünde verinin oluşturucusu (kullanıcı) URI’nin authority alanı olarak belirlenir
  • Örneğin at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z biçiminde, ruuuuu.de bu verinin sahibini gösterir
• Verinin gerçekten barındırıldığı fiziksel sunucu URI içinde doğrudan yer almaz; bunu bulmak için ek bir çözümleme süreci gerekir

# at:// URI çözümleme sürecinin üç adımı

• at:// URI’yi gerçek veriye (JSON) eşlemek için üç adım gerekir
  1. Handle’ı (ruuuuu.de gibi) kimliğe (DID: Decentralized Identifier) dönüştürme
     • Handle, kullanıcıyı tanımlayan bir takma addır ve değişebilir
     • Bu nedenle değişmeyen küresel kimlik olan DID’ye dönüştürülmesi gerekir
     • Dönüştürme yöntemleri:
       • DNS TXT kaydında _atproto.<handle> sorgulanır → did=... değeri kontrol edilir
       • veya https://<handle>/.well-known/atproto-did adresine erişilir
  2. DID belgesini (DID Document) sorgulayarak veri barındırma bilgisini bulma
     • DID belgesinde ilgili kimliğin açık anahtarı, servis endpoint’i (sunucu) gibi bilgiler bulunur
     • did:web:~ için alan adı tabanlı erişim kullanılır (https://alanadi/.well-known/did.json)
     • did:plc:~ için PLC dizininden sorgulama yapılır (https://plc.directory/DID)
     • serviceEndpoint, verinin gerçekten barındırıldığı sunucudur
  3. Barındırma sunucusunun API’si üzerinden JSON verisini isteme
     • com.atproto.repo.getRecord endpoint’ine at:// URI’nin her parçası parametre olarak geçirilerek veri istenir
     • Dönen JSON, at:// URI ile eşleşen gerçek veridir

# Bir örnekle çözümleme süreci

• Örnek: at://ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z
  • 1. adım: ruuuuu.de → did:web:iam.ruuuuu.de (DNS TXT record veya .well-known ile doğrulanır)
  • 2. adım: https://iam.ruuuuu.de/.well-known/did.json üzerinden DID Document alınır → serviceEndpoint değeri https://blacksky.app
  • 3. adım: https://blacksky.app/xrpc/com.atproto.repo.getRecord?... adresine istek atılır → gerçek JSON döner

    {
      "uri": "at://did:web:iam.ruuuuu.de/app.bsky.feed.post/3lzy2ji4nms2z",
      "cid": "...",
      "value": {
        "text": "posting from did:web, like a boss",
        "$type": "app.bsky.feed.post",
        ...
      }
    }
    

• Handle değişse bile, DID tabanlı at:// URI (permalink) kullanılırsa hesap ile veri arasındaki bağ korunur

# DID yöntemleri: did:web ve did:plc arasındaki fark

• did:web:
  • Kendi alan adınızı yönetebilir ve doğrulayabilirsiniz
  • Alan adı üzerindeki kontrol kaybedilirse tüm kimliği kaybetme riski doğabilir
• did:plc:
  • Kimliğin işletim otoritesi PLC’dir (Public Ledger of Credentials)
  • Alan adına bağlı değildir, ancak PLC operatörünün güncellemeleri reddetmesi gibi sınırlı kontrol olasılıkları vardır
  • Tüm değişiklik geçmişi hash ile doğrulanabilir ve izlenebilir

# Kimlik, barındırma ve verinin ayrılması ile kalıcılık

• at://, kimlik ile veri barındırmayı birbirinden ayırarak kullanıcı verisinin taşınabilir olmasını ve kalıcı bağlantılar üretilebilmesini sağlar
• Handle (takma ad) istenildiği zaman değiştirilebilir, barındırma sunucusu da benzer şekilde taşınabilir
• DID (kimlik) değişmezdir; buna dayalı at:// URI kalıcı permalink olarak kullanılabilir
• DID Document içinde handle sahipliğinin kanıtı, imza doğrulama anahtarları ve barındırma bilgileri birlikte yer alır; bu da güvenilirlik ve esneklik sağlar

# Gerçek kullanım ve geliştirme notları

• Pratikte çoğu AT tabanlı uygulama, verileri WebSocket vb. yöntemlerle push olarak alıp dahili bir veritabanında toplar
• Buna rağmen at:// URI çözümleme yöntemini bilmek, ağın özelliklerini anlamak ve veri taşınabilirliğini sağlamak açısından kritiktir
• at:// yapısı; HTTP, DNS ve JSON üzerinde bir sosyal ağ soyutlaması sunar ve veri sahipliğinin kullanıcıda olmasını teknik olarak hayata geçirir

# Sonuç

• AT protokolü ve at:// URI, sosyal verinin kimliği, bağlantılılığı ve kalıcılığı açısından teknik olarak bir adım ileri gider
• Geliştiricilerin handle çözümleme, DID kullanımı, DID belgesi yapısı ve gerçek veri isteme yöntemi gibi temel iş akışlarını iyi bilmesi gerekir
• Bu yapı sayesinde kişi, kendi içeriği, kimliği ve barındırma konumu arasındaki esnekliği ve sahipliği elde edebilir

[GN⁺]

Hacker News görüşleri

• Yakın zamanda ATProto ile ilgili yazılardan ilham alıp bsky'a katıldım, ama karşıma çıkan tek şey bitmek bilmeyen Amerikan siyaseti oldu, "böyle gönderileri daha az göster"e sürekli bassam da pek etkisi olmadı, bunun bu platformun özü olup olmadığını merak ediyorum, yabancı ülkelerdeki tuhaf tartışmalar hakkında klişe görüşleri durmadan görmek zihinsel olarak pek iyi gelmiyor

  • Yeni hesaplarda "Discover" akışı pek iyi değil, beğeni ve takip verisi biriktikçe zamanla iyileşiyor ama yine de en iyisi denemez, ben şahsen "For You" akışını öneririm, bu akış beğenileri hızlı yansıtıyor ve rastgele içeriği daha az öne çıkarıyor, "Dev Trending" akışı da oldukça iyi For You Feed, Dev Trending
  • Benim yaptığım şey, iyi birkaç hesap bulup takip etmek ve "Discovery" sekmesini tamamen gizlemek oldu, sonrasında takipçi/takip edilenlerden çıkan insanların etkileşimlerini görerek takip listemi doğal şekilde büyüttüm, ya da blog ve web sitelerinde hesap bulup takip ettim, bence bu sosyal medyanın gerçekten çalışması gereken yol ve otomatik önerilen içeriği zorla almak pek iyi değil
  • Neyse ki bsky'da yalnızca takip ettiklerinin gönderilerini gösteren algoritmasız bir akış var, bence akıl sağlığını korumanın tek yolu bu
  • bsky'ı bir yıldan uzun süredir kullandım ama içeriklerin çoğu Amerikan siyasetiyle ilgiliydi, bir Avrupalı olarak bana sadece gürültü gibi geldi, bu yüzden Mastodon'a geri döndüm, teknoloji dünyasından insanları takip etmek için Mastodon çok daha iyiydi, haberleri de feedly üzerinden RSS ile alıyorum, şu an Bluesky'ın neden gerekli olduğunu bile bilmiyorum, bana sadece Twitter'ın sol versiyonu gibi geliyor, teknoloji olarak Nostr'un gelişmiş bir hali olması ilginçti ama o kadar
  • Ayarlara girip Contents and Media > Your Interests > News and Politics seçeneğini kapatmanı öneririm, Amerikan siyaseti yerine başka ülkelerin haber ve siyaset içeriğini nasıl görebileceğini ise bilmiyorum

• Bu projenin kimlik ve veri sahipliği sorunlarını gerçekten anlamlı biçimde çözüp çözmediğinden hâlâ emin değilim, kimlik tarafında ya kendi alan adın var ya da başkasının alan adını kullanıyorsun (Bluesky gibi), çoğu insanın alan adı olmadığından kimlikleri sonuçta üçüncü tarafın elinde oluyor, veride de durum aynı, Bluesky ya da başka bir sunucuda hesabın engellenirse depolama da kapanıyor ve veriyi başka yere taşıma fırsatını bile kaybediyorsun, bu e-postayla aynı şey, kendi alan adın ve sunucun yoksa pratikte hiçbir şeyi gerçekten kontrol etmiyorsun

  • AT'de veriler handle ya da hosting'e değil, DID'ye (Decentralized Identifier, merkeziyetsiz kimlik) bağlıdır, yazımda bunu ayrıntılı açıkladım, "handle" alan adını kaybetsen bile olan şey sadece handle'ın geçersiz olması ve uygulamada kullanıcı adı yerine "invalid handle" görünmesi olur, gönderiler, takipçiler ve diğer veriler DID üzerinden bulunabildiği için yerinde kalır, handle sadece bir takma ad gibidir, handle değişikliği de uygulamadaki "handle değiştir" özelliğiyle yapılabilir, hosting de benzer şekilde çalışır; bazı engeller olsa da depo yedeğin varsa başka yere taşıyabilirsin, yedeklemeyi otomatikleştirmek de mümkün ve bunu zaten yapan üçüncü taraf uygulamalar çıktı, resmi Bluesky uygulaması da depoyu dışa aktarmanı sağlıyor, hosting sağlayıcısı işbirlikçiyse PDSMover gibi durumlar var, işbirliği yapmasa bile adversarial pds migration bunun mümkün olduğunu gösteriyor, şu anda biraz teknik bilgi gerektiriyor ama zamanla bunun da kolaylaşmasını bekliyorum, depoyu yeni hosta yüklersen aynı kimlikle tüm gönderilerin, takipçilerin vb. aynen geri gelir, bu açıdan e-postadan çok farklı, bugün biraz zor ama AT ekosistemi geliştikçe çok daha kullanışlı olacağını düşünüyorum
  • Alan adına sahip olsan bile bir gün onu da kaybedebilirsin, sunucudan farklı olarak alan adı bir kayıt kuruluşuna bağlı olduğu için bana daha kırılgan geliyor, bu yüzden kayıt kuruluşunu seçerken kendi ülkemin yasalarına tabi olan bir şirket seçtim, böylece bir sorun olursa bir miktar daha kurtarma umudu olur diye düşündüm
  • Alan adı olmayan çoğu kullanıcı, hosting sağlayıcısının "düşman" haline gelmesiyle oluşan risklere her zaman açık, örneğin hesabın aniden engellenmesi gibi, tam korunma sonuçta ancak tarafsız bir TLD altında alan adının doğrudan sana ait olması ve trafiği DNS ile yönlendirmenle mümkün, yine de bu gerçeklik altında — yani neredeyse kimsenin kendi alan adını kullanmayacağı bir dünyada — bu proje kısmi esneklik ve koruma ekleyerek mevcut Big Social'da (Facebook, X, Instagram vb.) verinin sonsuza kadar kilitli kalmasına kıyasla bir ilerleme sunuyor, Bluesky sanırım bu yüzden handle'ı koruyup yalnızca veri hosting'ini taşıma fikriyle ilgileniyor, sektörün bir anda mükemmele ulaşamadığını, daha çok gerçek dünyadaki sorunları adım adım iyileştirerek ilerlediğini düşünüyorum
  • Kimlik kanıtı için en iyi yaklaşımın private key sahipliği olduğunu düşünüyorum, hosting için de en sağlam seçeneğin BitTorrent olabileceğini hissediyorum, içeriği bir git deposunda tutup commit'leri imzalayarak torrent ile dağıtma modeli düşünülebilir, güncelleme bildirimleri için de NNTP ya da RSS aklıma geldi, sorun keşfedilebilirlik ve etkileşim eksikliği, yani yorum yok
  • En azından e-postada PGP/SMIME anahtarını alıp başka yere taşıyabiliyorsun, ATproto da benzer bir kavram değil mi diye merak ediyorum

• Dan'in açıklamaları her zamanki gibi harika, Bluesky'ın yakın zamanda PLC işletimini devredeceğine dair haberlerle birlikte çok zamanlı oldu, bizim ekip de fair.pm üzerinde WordPress eklentilerini dağıtık biçimde dağıtmak için aynı DID sistemini seçti (bir bakıma App Store benzeri bir paket yönetimi), Bluesky tarafı özellikle Bryan çok yardımcı oldu ve libsodium kullanabilelim diye Ed25519 anahtar desteği bile almayı başardık, bizim protokolümüz DID ve Bluesky'ın stackable moderation yapısı üzerine tasarlanıyor ama atproto'yu doğrudan kullanmıyor, asıl önemli nokta DID'nin bir W3C standardı olması ve PLC'nin atproto'ya bağlı kalmaması

  • "Biz" kim oluyoruz, ve eğer bu WordPress dramasını teknik olarak çözmeye yönelik bir girişimse biraz daha ayrıntı duymak isterim
  • PLC'nin atproto'ya bağlı olmadığını söyledin ama PLC (did method) sonuçta Bluesky ya da başka bir merkezi otoriteye bağlı değil mi? Bu kadar merkeziyken buna neden DID dendiğini merak ediyorum, did:plc taşınabilir de değil, neden did:web gibi yazıp PLC benzeri davranışı onun içine koymadınız, neden method-specific-id'yi public key hash'i gibi taşınabilir yapmadınız, neden DHT (ör. did:pkarr) gibi daha dağıtık bir yola gitmediniz, PLC sonuçta bana başka bir merkezi sistem gibi görünüyor

• at://'yi bulmak için plc.directory'ye GET isteği göndermek gerekiyor, bu noktada sistem sanki %100 merkezi bir modele dönüşüyor, en azından birkaç güvenilir dizin protokolden ayrı olsaydı iyi olurdu, DNS kökü ya da CA'ler gibi

  • Bunu bireysel yapmak istersen did:web:fqdn de kullanabilirsin, yazıda da anlatıyorum

• at:// bağlantılarını saklayan her sunucunun sonuçta kalıcı bağlantı gösterimini bulmak için DNS/HTTPS üzerinden gitmesi gerekecek gibi görünüyor, DNSSEC düzgün çalışmazsa yapı biraz zayıf duruyor, bunu henüz derinlemesine düşünmedim ama akla ilk gelen endişe, DNS poisoning gibi bir sorunla saldırganın benim adıma gönderi yayımlayabilmesi olurdu (çünkü public key, DNS'ten alınan DID'nin içinde bulunuyor)

  • DNS poisoning endişesi anlaşılır ama pratikte durum her zaman öyle değil, at://'de authority kısmına genelde handle yerine DID konur, bu yüzden istekleri handle yerine DID ile yaparsan sonunda HTTPS ve web PKI ekosistemine dayanmış olursun, handle'dan başlasan bile web PKI ve TXT kaydı devreye girer, önerilen yaklaşım handle'ların sunucu tarafında çözümlenmesi, kendin yapacaksan da güvenilir bir DoH (HTTPS DNS) sağlayıcısına sorgu göndermen, kusursuz değil ama saldırı yüzeyini ciddi biçimde azaltır, DNSSEC tabii ki bu sorunun çözümüdür ama gerçek ağ operasyonlarında DNSSEC yüzünden birkaç kez can sıkıcı sorunlar yaşadım, örneğin ABD senatörleri kimlik doğrulaması için senate.gov alan adını kullanıyor ama yakın zamanda DNSSEC yapılandırması bozulduğunda onlarca senatör Bluesky'da "invalid handle" olarak görünmüştü, bu tarz hayal kırıklığı yaratan deneyimler yüzünden şu anda DNSSEC'i zorunlu kılmak için çok bastırmıyoruz, başka büyük bir protokol DNSSEC'i başarıyla zorunlu hale getirirse bunu yeniden değerlendirmeye değer
  • Bir saldırganın senin kimliğine bürünüp gönderi yayımlayabilmesi için mutlaka private key'e sahip olması gerekir, DNS kayıtları sadece DID belgesinin nereden alınacağını söyler, bu DID belgesi de sonrasında DNS üzerinden yeniden doğrulanmalıdır, bu süreçte doğrulama mantığı vardır, DNSSEC DNS kaydının kurcalanması riskini azaltır ama DNSSEC olmaması rastgele birinin senin adına gönderi yayımlayabileceği anlamına gelmez, sunucular da bunu reddeder
  • O kısım biraz karışık ama DNS TXT method içinde de açıkça "DNSSEC gerekli değil" deniyor, sonuçta DNS sadece Handle->DID dönüşümünü yapıyor, doğrulama ise DID->Handle yönünde de giden çift yönlü bir süreç

• Yazıda DID değişim geçmişinde kullanılan anahtarlara dair yeterli bilgi yok, örneğin ben foobar.bsky.social isem bu anahtarları kendim yüklediğimi hatırlamıyorum ya da indirmem gerektiğine dair bir yönlendirme görmedim, bu anahtarlar tam olarak nerede, kimin mülkiyetinde, nasıl ve ne zaman kullanılıyor merak ediyorum, ayrıca DID plc.directory'de duruyorsa, siteyi işleten kişinin benim DID'imi keyfi biçimde değiştirip kimliğimi çalmasını engelleyen mekanizma nedir?

• at:// fikri ilginç, ama gerçekten veri sahipliğine dayalı bir sistemde ortaya çıkabilecek sorunlar da aklımı kurcalıyor, örneğin kullanıcı veriye sahip olduğu için içeriği istediği zaman değiştirebilir ya da silebilir, başta iyi niyetli bir şey yazıp sonra kötü niyetle tamamen farklı hale getirebilir, eski içerik hash'lerini saklayıp değişiklikleri engellesek bile yeni bir servis bu geçmişten habersiz olabilir, ayrıca beğeni/upvote gibi şeyleri takip etmek de zor görünüyor, herkes bunları kendi nesnesi olarak tutarsa kimin oy verdiğini bulmak zorlaşır, sahte hesap açıp kendi içeriğini durmadan öne çıkarma konusunda da sınırlama yok gibi, son olarak farklı platformlardan gelen çok sayıda hesap varsa spam ve kötüye kullanımı yönetmek imkânsız hale gelmez mi, her hesabın verisini kendisinin yönettiği bir modelde şeffaflık, hesap verebilirlik, moderasyon, spam engelleme gibi tüm unsurların sistem tasarımı gerçekten ayakta kalır mı emin değilim

  • Değişim geçmişi birlikte yayımlanabilir, veriye (json) istediğin kadar bilgi koyabildiğin için eski gönderi adreslerini at:// üzerinden bağlı liste gibi tarif etmek mümkün, DID kimlik moderasyonu açısından da iyi bir temel sunuyor; yani bunun kim olduğunu anlamak, engellemek ya da değerlendirmek için yeterli bağlamı sağlıyor, önemli nokta bunun bir blockchain olmaması ve veri sahibinin istediği zaman paylaşabileceği bir model olması, biri kötü niyetle her şeyi bozmaya çalışmadığı sürece bence epey çekici bir yapı, çünkü "bu kişinin hangi verisi nerede" sorusuna net cevap veriyor, bu tür şeffaflık senin için önemli değilse kullanmamakta özgürsün
  • Orijinal içeriğin kötü niyetli şekilde değiştirilmesini engellemek için strongRef adında hash tabanlı gerçek bir permalink var, Dan bunu yazıda ayrıntılı anlatmadı ama strongRef'i kaydedersen eski gönderi içeriği değişse bile bunu hemen fark edebilirsin, Bluesky'ın edit özelliği getirmemesinin sebeplerinden biri de kötü niyetli değişiklikler, (bkz. permalink'ler ve kayıt düzenleme hakkında permalink deneyi özeti, kayıt düzenleme geçmişi deneyi), upvote takibi ağın verisini tarayıp roaring bitmap gibi yapılarla kabaca mümkün olabilir (roaring-bitmaps örneği), moderasyon tarafında stackable moderation var ve mevcut sistemlerden çok daha havalı, labeler/feedgen için DAG (küme işlemlerine dayalı kural birleştirme sistemi) üzerine kurma fikri de konuşuluyor, verinin sahteciliğe karşı korunması her kaydın CID hash'iyle sağlanıyor, geçmiş takibi de teknik olarak mümkün

• Çeşitli kripto protokollerinin merkeziyetsizlik vaat etmesine rağmen sonuçta tek bir platform etrafında toplanmasına benziyor gibi geliyor

  • Hâlâ erken bir aşamadayız ama tangled.org (GitHub benzeri), leaflet.pub (Medium benzeri) gibi örnekler zaten aktif kullanılıyor, ayrıca ağ indekslemeyi otomatikleştiren araçlar (slices.network) sayesinde yeni uygulama geliştirmenin eşiği sürekli düşüyor, bu yüzden daha fazla uygulama geleceğini düşünüyorum, yazıda bunun nasıl çalıştığını anlattım, asıl önemli nokta şu: "genel" kullanıcı için bunların çoğu önemli değil, Bluesky kullanıcılarının büyük bölümü aslında "merkeziyetsizlik" meselesine ya kayıtsız ya da hafifçe karşı, ama bu yapı ürünün üstünde doğrudan görünmediği için — tıpkı web gezintisinde olduğu gibi — böyle bir benimsenme mümkün olabiliyor, kullanıcılar sadece "iyi çalışmasını" istiyor
  • Bana biraz Git ve GitHub'ın geçmişini hatırlatıyor (özellikler arttıkça bir miktar daha dağıtık ve esnek hale gelmişlerdi)

• "at:// URI ile JSON nasıl bulunuyor" şeklinde yapısal bir sorum var, belgeleri okusam da neden "o JSON"a ihtiyaç duyulduğunu pek kavrayamadım, bana göre bu yaklaşım pek doğal gelmiyor

  • Giriş kısmının biraz ani geldiğini kabul ediyorum, kusura bakma, at:// protokolü uygulamalar arasında verinin serbestçe gömülmesini ve dışa aktarılmasını, kullanıcı kimliğinin paylaşılmasını ve içeriğin self-host ya da taşınabilir olmasını sağlıyor, handle'a ya da sunucuya bağlı olmayan kalıcı URI'ler sunuyor, teknik gerekçesini yazının tamamında anlattım, örnek olarak leaflet.pub ve bsky.app aynı açık ağdan veri topladıkları için ayrı bir API olmadan birbirlerinin verisini kolayca entegre edip gösterebiliyorlar (demo gönderi)
  • Bunu anlamaya yardımcı olması için "https:// URI ile HTML nasıl bulunuyor?" sorusuna benzetebilirsin, aşırı basitleştirme olsa da DNS, HTTP ve TLS'yi ilk kez öğrenen birine anlatmak için uygun

• Bu protokol devasa bir herkese açık Kafka topic'i gibi mi davranıyor diye merak ediyorum, örneğin yeni bir web uygulaması yaparken veriyi kendin saklamayıp tüm kullanıcıların verisini kendi alanlarında tutmasına izin veriyorsun, sen de sadece bunu dinleyen bir listener koyuyorsun ve protokol veri yayılımını garanti ettiği için uygulama bunları dinleyip cache'liyor, yani model kabaca böyle mi, kavramsal olarak ilginç ama güncellemeleri kaçırmamak için offset, ölçek için partition gibi Kafka kavramları burada da var mı diye merak ediyorum

  • Evet, firehose neredeyse tam olarak o işi görüyor, herkes abone olabilir ya da kendi firehose'unu çalıştırabilir, ATProto dağıtık sistem mühendisleri için açıklama yazısına bak, firehose ve jetstream'de cursor var, bu yüzden geç bağlansan bile en güncel verilere kadar ilerleyebilirsin, kapsama süresi instance'a göre 1–72 saat arasında değişiyor, tüm geçmişe ihtiyacın varsa backfill ile tamamlamak mümkün