ActivityPub’u uygulamanın neden zor olduğu ve neden buna gerek olmadığı

 (hackers.pub)
2 puan yazan GN⁺ 5 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • ActivityPub sunucusunu doğrudan geliştirirseniz, ilk Follow isteğinde bile açıklamasız bir 401 Unauthorized hatasına takılmanız kolaydır; Fedify ise imza, JSON-LD, dağıtım ve güvenlik yükünü uygulama kodunun dışına taşıyan bir TypeScript framework’üdür
  • Fediverse kimlik doğrulamasında süresi dolmuş draft-cavage-http-signatures-12 taslağı ile standart RFC 9421 birlikte kullanılır; buna belge imzaları da eklendiğinde dört farklı imza mekanizması ile RSA ve Ed25519 anahtarlarını yönetmek gerekir
  • Aynı ActivityPub etkinliği JSON-LD içinde string, dizi, satır içi nesne veya URI referansı gibi farklı biçimlerde gelebilir; bu yüzden doğrudan uyguladıkça savunmacı kod tüm kod tabanına yayılır
  • Dağıtık iletimde, Delete etkinliğinin Create etkinliğinden önce ulaşmasıyla ortaya çıkan “zombi gönderi” gibi sorunlar yaşanır; kuyruk, yeniden deneme, idempotency, sıra garantisi ve circuit breaker gerekir
  • Fedify; 13 web framework entegrasyonu, KV ve mesaj kuyruğu adaptörleri, CLI, linter, debugger ve OpenTelemetry sunarak ActivityPub ayrıntı bilgisi olmadan federasyonlu uygulama geliştirmeye başlamayı mümkün kılar

ActivityPub’u doğrudan uygularken karşılaşılan sorunlar

  • İlk Follow etkinliğini Mastodon’a göndermek için JSON oluşturma, HTTP isteğini imzalama ve POST işlemini yapma gerekir; ancak başarısız olursa geri yalnızca tek satırlık 401 Unauthorized dönebilir
    • Bunun nedeni Date başlığındaki saat kayması, Digest hash hatası, (request-target) büyük/küçük harf farkı veya açık anahtarın ifade edilme biçimi olabilir
    • Uzak sunucu sebebi açıklamıyorsa, hata ayıklamak için diğer sunucuların kodlarını okuyarak ilerlemek gerekir
  • Fedify, tek kullanıcılı mikroblog sunucusu Hollo geliştirilirken ortaya çıktı
    • ActivityPub’u uygulama yükü ürün geliştirmeyi yutmaya başlayınca, uygulamadan önce gerekli olan bir framework olarak geliştirildi
  • Zorluklar büyük ölçüde imza standartları, JSON-LD belge biçimleri, dağıtık iletim, uygulamaya özel teamüller ve varsayılan güvenlik ayarlarında yoğunlaşır

İmza standardı tek değil

  • Sunucular arası kimlik doğrulamada HTTP imzaları kullanılır, ancak gerçek fediverse’te süresi dolmuş draft-cavage-http-signatures-12 taslağı ile standart RFC 9421 birlikte bulunur
  • Hangi sunucunun hangi imzayı kabul ettiğini denemeden önce bilmek mümkün değildir; bu nedenle bir yöntemle imzalayıp reddedilirse diğer yöntemle yeniden imzalamak ve başarılı olan yöntemi sunucu bazında hatırlamak gerekir
  • HTTP imzaları yalnızca isteği gönderen tarafı doğrular; bu yüzden alınan etkinliğin üçüncü taraflara iletildiği inbox forwarding gibi durumlarda, belgenin kendisine eklenen imzalar da gerekir

JSON-LD belge biçimi sürekli değişir

  • ActivityPub’un aktarım biçimi JSON-LD’dir ve aynı anlama gelen bir Create etkinliği bile birden fazla biçimde ifade edilebilir
    • actor, URI string’i de olabilir, satır içi bir Person nesnesi de olabilir
    • to, tek bir string de olabilir, bir dizi de olabilir
    • object, satır içi bir nesne de olabilir, bir URI da olabilir
  • Herkese açık hedefi ifade eden adresler için https://www.w3.org/ns/activitystreams#Public, as:Public ve Public olmak üzere üç gösterim de geçerlidir
  • Spesifikasyona uygun işlemek için JSON-LD processor ile expansion yapıp ardından compaction uygulayarak normalize etmek gerekir
    • Pek çok uygulama bunu “sadece JSON” gibi ele alır ve belirli bir sunucunun dışa aktardığı biçimde sessizce bozulur
  • Doğrudan uygulamada, değerin string mi, dizi mi, nesne mi ya da getirilmesi gereken bir URI mı olduğunu kontrol eden savunmacı kod her yere yayılır

Dağıtık iletim ve “zombi gönderi”

  • Kullanıcı bir gönderi paylaştıktan hemen sonra yazım hatasını fark edip silerse, sunucu Create ardından Delete gönderir; ancak ağ koşullarına bağlı olarak alıcı sunucu Delete etkinliğini önce alabilir
    • Henüz var olmayan bir gönderinin silinmesini yok sayıp daha sonra Create etkinliğini işlerse, yazarın silindiğini sandığı gönderi o sunucuda kalmaya devam eder
  • 5 bin takipçi varsa, tek bir gönderi binlerce HTTP iletimi üretir; bunu istek işleyicisinin içinde yapmak, paylaşım düğmesinin yanıtını geciktirebilir veya sunucuyu çökertir
  • Kuyruk kullanılsa bile, başarısız iletimlerin yeniden deneme takvimi, exponential backoff, yeniden deneme sayısı, 500 Internal Server Error ile 410 Gone arasındaki fark, ortadan kaybolmuş sunucuların takipçilerini temizleme ve uzun süreli arızalı host’ları ele alma gibi kararlar verilmelidir
  • Bu alan, basit bir protokol uygulamasından çok dağıtık sistem mühendisliğine yakındır

Yalnızca spesifikasyon, birlikte çalışabilirliği tamamlamaz

  • Spesifikasyona eksiksiz uysanız bile, gerçek fediverse uygulamalarıyla birlikte çalışabilirlik sorunları devam eder
  • Mastodon’un secure mode’u, GET isteklerinde bile HTTP imzası isteyen authorized fetch kullanır
    • Her iki sunucu da secure mode kullanıyorsa, karşı tarafın açık anahtarını almak için imza gerekir; imzayı doğrulamak için de karşı tarafın önce sizin açık anahtarınızı alması gerekir ve bir kilitlenme durumu doğar
    • Topluluk bunu, sunucunun kendisini temsil eden instance actor ile imzalayarak aşar; ancak bu spesifikasyonda yer almaz
  • Threads, actor alanı satır içi nesne olan etkinlikleri parse edemez; bu nedenle Threads’e gönderirken actor alanını URI olarak göndermek gerekir
  • Lemmy, Mastodon’un istemediği Group actor alanları yoksa sessizce reddeder
    • Buna attributedTo ile bağlanan moderators collection ve featured collection örnek verilebilir
  • Misskey kendi sözlük genişletmelerine sahiptir ve yalnızca quote post için bile uygulamaya göre üç farklı özellik adı kullanılır
  • Birlikte çalışabilirlik, bir kez uyum sağlayıp biten bir iş değil, sürekli korunması gereken bir alandır

Doğrudan uygulamanın varsayılan durumu güvenli değildir

  • Gelen etkinliklerin imza doğrulamasını atlarsanız, herkes sahte Follow veya Delete enjekte edebilir
  • Belge yükleyicisini kısıtlamazsanız, kötü niyetli bir etkinlik http://169.254.169.254/ ya da iç ağı işaret ederek sunucunuzu bir SSRF proxy’sine dönüştürebilir
  • Gömülü nesnelerin kaynak denetimini atlarsanız, herhangi bir sunucu belirli bir kişinin söylemiş gibi göründüğü belgeler yayımlayabilir
  • Bu tür tuzaklar hemen fark edilmez; kötüye kullanılana kadar her şey çalışıyormuş gibi görünebilir

Fedify’nin üstlendiği alanlar

  • Fedify, ActivityPub ve ilgili standartlarla federasyonlu sunucu uygulamaları oluşturmak için kullanılan bir TypeScript kütüphanesidir
  • Deno, Node.js ve Bun üzerinde çalışır; Cloudflare Workers gibi edge runtime’ları da destekler
  • Tasarım hedefi; imza, JSON-LD, teslimat, uygulamaya özgü farklılıklar ve güvenlik ayrıntılarını uygulama kodundan çıkarmaktır

  • İmza işleme

    • actor dispatcher ve key pair dispatcher kaydedilirse bir actor fediverse’e yayınlanabilir
    • Giden tüm isteklere imza eklenir
    • RSA anahtarlarında HTTP Signatures ve Linked Data Signatures üretilir
    • Ed25519 anahtarı eklenirse Object Integrity Proofs da eklenir
    • Bu dört mekanizma tek bir etkinlikte bir arada bulunabilir ve alıcı kendi anlayabildiği en güçlü yöntemle doğrulama yapar
    • Fedify, double-knocking işlemini doğrudan yönetir
      • İlk temas RFC 9421 ile yapılır, reddedilirse draft-cavage ile yeniden denenir
      • Başarılı olan yöntem sunucu bazında önbelleğe alınır
      • Ret yanıtında Accept-Signature challenge varsa, sunucunun istediği bileşenlerle yeniden imzalanır
    • Gelen imzalar, uygulama kodu görmeden önce doğrulanır; doğrulama başarısız olan etkinlikler listener’a ulaşmaz
    • Yalnızca actor dispatcher kaydıyla bir WebFinger RFC 7033 sunucusu da oluşur; böylece actor, Mastodon arama kutusunda @alice@example.com biçiminde bulunabilir

  • JSON-LD yerine tiplerle çalışma

    • Fedify, Activity Vocabulary bütününü ve başlıca üretici uzantılarını kapsayan yaklaşık 80 sınıf sağlar
    • Sınıflar tipli ve değiştirilemezdir; accessor’lar ise JSON-LD’nin izin verdiği belge biçimi farklılıklarını soğurur
    • lookupObject(), bir handle alıp WebFinger discovery dahil tüm arama sürecini yürütür
    • getFollowers() gibi accessor’lar, değer bir URI referansı da olsa inline nesne de olsa aynı şekilde çalışır ve alınan değerler önbelleğe alınır
    • Üreticiye özgü farklar da API’nin arkasına gizlenir
      • Üç ayrı quote özelliği olan quoteUri, _misskey_quote, quoteUrl, yeni ortaya çıkan FEP-044f içindeki quote ile birlikte tek bir API arkasında birleştirilir
      • Misskey’nin isCat özelliği de tip olarak bulunur, böylece tip güvenli şekilde işlenebilir

  • Teslimat altyapısı ve sıra garantisi

    • createFederation() içine bir mesaj kuyruğu bağlanırsa teslimat arka plana taşınır ve başarısızlık durumunda varsayılan olarak en fazla 10 kez, üstel backoff ile otomatik yeniden denenir
    • Tek bir gönderi binlerce takipçiye iletileceğinde two-stage fan-out devreye girer
      • Kuyruğa tek bir birleşik mesaj girer
      • Arka plan worker’ı bunu sunucu bazlı teslimat işlerine böler
      • Yayınla düğmesi anında yanıt verir
    • Yeniden denemeler nedeniyle aynı etkinlik iki kez gelebileceğinden, Fedify işlenmiş etkinlikleri 24 saat saklayan bir idempotency cache ile tekrarları handler’dan önce atlar
    • sendActivity() çağrısında { orderingKey: post.id } belirtilirse, aynı orderingKey değerini paylaşan etkinlikler her alıcı sunucuya gönderildikleri sırayla teslim edilir
      • Delete, Create’in önüne geçemez
      • Farklı anahtarlara sahip etkinlikler ise verimi korumak için paralel gönderilir
    • 404 Not Found veya 410 Gone durumlarında yeniden deneme durur ve kayıtlı kalıcı teslimat hatası işleyicisi çağrılır
    • Shared inbox’a gönderilmişse, arkasındaki takipçi listesi de alınarak ortadan kaybolan hesaplar temizlenebilir
    • Sürekli başarısız olan host’larda varsayılan olarak etkin circuit breaker, teslimatı askıya alır ve düzenli aralıklarla toparlanmayı kontrol eder

Uygulamaya özgü pratikler ve güvenlik varsayılanları

  • Fedify, authorized fetch için .authorize() metodunu dispatcher’a bağlayarak doğrulanmış istekçi kimliğini callback’e iletir
    • Engelleme listeleri, özel koleksiyonlar gibi işlemler uygulama mantığı olarak yazılabilir
    • Instance actor kilitlenmesi sorununa yönelik desteklenen kalıplar da vardır
  • Threads’in inline actor sorunu, varsayılan olarak etkin olan activity transformer sayesinde giden etkinliklerdeki inline actor’ları URI’ye dönüştürerek çözülür
  • Lemmy’nin gerektirdiği moderators collection, custom collection API ile birkaç satırda açığa çıkarılabilir ve Lemmy’nin JSON-LD context’i önceden dahil edilmiştir
  • Yeni bir birlikte çalışabilirlik sorunu bulunduğunda düzeltme her uygulamaya değil, Fedify’ye eklenir
  • Güvenlik varsayılanları güvenli tarafta kalacak şekilde ayarlanmıştır
    • İmza doğrulama açılması gereken bir özellik değil, test için kapatılabilen bir özelliktir
    • Belge yükleyici, private address range ve loopback’i varsayılan olarak engeller; DNS rebinding’i de dikkate alır
    • SSRF’ye açık hale gelmek için, test amaçlı olduğunu belli eden isimli bir seçeneğin açıkça etkinleştirilmesi gerekir
    • Gömülü nesnenin kaynağı üst belgeyle farklıysa, accessor buna güvenmez ve nesneyi kaynağından yeniden getirir
    • Bu kaynağa dayalı güvenlik modeli FEP-fe34 temellidir

Mevcut yığın ve geliştirme araçları

  • Fedify, mevcut web yığınına uyacak şekilde tasarlandı ve 13 web framework entegrasyonu sunuyor
    • Express, Hono, Fastify, Koa, NestJS, Elysia
    • Next.js, Nuxt, SvelteKit, Astro, SolidStart, Fresh
  • Middleware içerik pazarlığını işler; böylece aynı URL tarayıcıya HTML, fediverse'e ise JSON-LD sunabilir
  • Fedify'nin kendi deposu yalnızca tek bir anahtar-değer arayüzü gerektirir
    • Redis, PostgreSQL, MySQL/MariaDB, SQLite, Deno KV, Cloudflare Workers KV ve in-memory adaptörler mevcut
  • Mesaj kuyruğu için PostgreSQL, Redis, AMQP/RabbitMQ vb. dahil 8 seçenek sunuluyor; uygun olan yoksa arayüzü doğrudan kendiniz uygulayabilirsiniz
  • Alan verileri mevcut veritabanı ve ORM içinde olduğu gibi bırakılabilir
  • Zaten başka bir kütüphane ile federation çalıştırıyorsanız, migration kılavuzu ve veri migration script'leri sayesinde activitypub-express vb. sistemlerden mevcut takipçileri kaybetmeden geçiş yapabilirsiniz
  • Üst seviye paketler de sunuluyor
    • @fedify/relay, tek bir fonksiyon çağrısıyla tam bir ActivityPub relay sunucusu sağlar
    • @fedify/backfill, fediverse'i takip ederek eksik konuşma dizilerini geri yükler

  • Geliştirme döngüsü için araçlar

    • fedify init, projeyi tek satırla scaffold eder
    • fedify tunnel, yerel sunucuyu HTTPS üzerinden açığa çıkararak gerçek Mastodon ile test etmeyi sağlar
    • fedify inbox, sunucunun gönderdiği aktiviteleri alacak geçici bir inbox sunucusu başlatır
    • fedify lookup, diğer sunucuların yayımladığı nesneleri incelemenizi sağlar
    • fedify lookup --authorized-fetch, tek kullanımlık bir anahtar çifti oluşturur ve geçici bir ActivityPub sunucusu ayağa kaldırarak secure mode arkasındaki nesnelere imzalı istekler gönderir
    • @fedify/lint, actor üzerinde inbox bulunmaması gibi 20 tür birlikte çalışabilirlik hatasını yakalayan ActivityPub odaklı bir linter'dır
    • @fedify/testing içindeki mock'larla ağ olmadan test çalıştırabilirsiniz
    • @fedify/debugger, tek satırla bir debug dashboard ekleyerek aktiviteleri ve imza doğrulama sonuçlarını tarayıcıda gerçek zamanlı görmenizi sağlar
    • Üretim ortamı için OpenTelemetry enstrümantasyonu yerleşik olarak gelir ve 28 span type ile 37 metric sunar
    • Monitoring kılavuzu ve ActivityPub için yük testi aracı fedify bench de sağlanır
    • Resmî dokümantasyon 30 bölümlük bir kılavuz ve 5 eğitimden oluşur; kuyruk backlog'unu görmek için PromQL sorguları ve uyarı kuralları, Mastodon'da avatarın görünmesini sağlayan özellikler gibi pratikleri ele alır

Hâlihazırda kullanılan örnekler ve başlama yöntemi

  • Fedify gerçek servislerde kullanılıyor
    • Ghost'un ActivityPub servisi
    • ORCID araştırmacı kayıtlarını fediverse'e bağlayan Encyclia
    • Cloudflare Workers üzerinde serverless çalışan SiliconBeest
    • Kore blog platformu Typo Blue
    • Tek kullanıcılı mikroblog platformu Hollo
    • Topluluk tarafından işletilen Hackers' Pub
  • Eğitimler ölçeğe göre örnekler sunuyor
  • Fedify'nin amacı daha fazla ActivityPub uzmanı yetiştirmek değil, geliştiricilerin ActivityPub ayrıntılarını bilmeden federasyonlu uygulamalar geliştirebilmesini sağlamak
  • Başlangıç komutu npm init @fedify
  • Yardıma ihtiyacınız varsa Matrix room veya GitHub Discussions kullanılabilir

İlgili okumalar

1 yorum

 
GN⁺ 5 시간 전
Lobste.rs yorumları

  • ActivityPub projelerinde birbirinin bu kadar çok fork’u olmasının nedeni bu: her şeyi baştan sona kendin uygulamaktansa başkasının yaklaşımını anlamak daha kolay.
    Yazarın önerdiği şey de pratikte sık görülen Misskey ya da Pleroma fork’larından pek farklı görünmüyor. Kütüphanenin de kendine özgü bir bakış açısı ve yaklaşımı var; çok fazla kontrol alanı bırakmıyor gibi. Yine de bütün bir sunucuyu fork’ladığınızda olduğu gibi UI’ı da dayatmaması bir avantaj.
    AP uygulayan biri olarak en zor kısım, JSON-LD’yi düzgün kullanmanın iyi bir yolu olmaması. Nesneleri standart bir gösterime kolayca dönüştürebilsek etkileşimler doğal olarak ardından gelir; ama onu gerçekten bağlantılı belge gibi kullanmak fazla verimsiz, ham JSON belgesi gibi kullanınca da sayısız uç durumun altında eziliyorsunuz. Şimdiye kadar ikinci yaklaşımı seçip ezildim.

    • Özellikle imzaları düşününce “nesnenin standart gösterimi” meselesi daha da önemli hale geliyor. Eski XML normalleştirmesi tam da bu imza sorunu için vardı: alıcının bayt serileştirmesinin göndericininkiyle eşleşmesini garanti etmek için.
      Bu, JSON-LD dünyasındaki sorunla birebir aynı değil ama tamamen alakasız da değil.
      Ancak JSON’a komşu teknolojilerin epey çoğunun benzer sorunlardan muzdarip olduğunu düşünüyorum. Aynı mantıksal şemayı ifade etmenin çok fazla JSON Schema yolu var ve bu yüzden JSON Schema çevresindeki teknolojilerle etkileşime girmek gülünç derecede berbat hale geliyor. Özellikle OpenAPI şemaları benzer ama aynı olmayan ayrı bir korku filmi; şema taslak sürümlerinin sayısını hesaba katmasak bile durum zaten yeterince kötü.
    • Bir AP sunucusu uygulamayı düşünüyordum ama henüz başlamadım; o yüzden söylediklerimi ciddi bir süzgeçten geçirmek gerekir. Yardımcı olabilecek bir şey, uygulamayı daha küçük servislere bölmek ve bunu “birleşik” bir arayüz gibi göstermek için aktör modeline daha fazla yaslanmak. Örneğin e-posta sunucularındaki MTA ve MUA ayrımından öğrenilecek şeyler var.
      AP’nin “MTA” servisi, giden kutusundan mesaj göndermek ve gelen kutusuna mesaj almakla ilgilenir. JSON-LD belgeleri bu servisin gözünden neredeyse yığın veri gibidir. Göndereni ve alıcıyı bulmak için biraz ayrıştırma gerekir ama fazlası pek yoktur. Depolama da dosya tabanlı olabilir; yanlış hatırlamıyorsam go-ap bunu böyle yapıyor.
      AP’nin “MUA”sı ise gerçek uygulamadır. JSON-LD anlamını kavraması gereken taraf burasıdır. PostgreSQL gibi bir şey kullanıp belgeleri jsonb olarak saklamak, üretilmiş sütunlar ve view’larla SQL dostu bir biçim sunmak mümkün olabilir. Böylece nesne tipine göre belgeyi en uygun şekilde temsil etme biçimi seçilebilir.
      Başka bir örnek olarak arama servisi de aktör olarak modellenip sonuçları geçici bir giden kutusu üzerinden döndürecek şekilde yapılabilir.

  • Çeşitli uygulamaların kendine özgü davranışlarını ve bunlara yönelik hafifletme yollarını derleyen çok değerli bir liste.
    Ne yazık ki GoActivityPub’ta bunların yarısını bile henüz uygulayamadık.

  • Yazı başta teknik içerikle başladığı için memnun olmuştum, ama ortalardan itibaren kendi framework’ünü pazarlamaya dönmüş gibi hissettirdi; okuma keyfini azalttı.
    TypeScript kullanan bazı dünyalarda bu uygulama tuhaflıklarını yeniden keşfetmek zorunda kalmayabilmek iyi bir şey. Ama zihinsel model olarak “bu koşul ve durumda şu sonuç çıkar, şu düzeltme gerekir” diye bir kayıt varsa, TypeScript dışındaki durumlarda —örneğin kardeş proje GoActivityPub’ın yazarı da— o emeğin sonuçlarından yararlanabilir. Burada bunlardan birkaçına değinilmiş, ama yazı belirli bir anın fotoğrafı; proje ise zamanla tüm birlikte çalışabilirlik hatalarını biriktirmeye çalışıyormuş gibi görünüyor.
    Şu anki alternatif, bana kalırsa insan tarafından yazılmamış commit mesajlarını tek tek okuyup Fedify’ın kendi hatalarıyla birlikte çalışabilirlik hatalarını ayırt etmeye çalışmak.
    Özellikle depo yapay zekaya “tam gaz” yüklenmiş gibi görünürken böyle bir kayıt tutmaması ironik. LLM’ler hakkında bize yapılan pazarlama, tekrarlı angaryaları otomatikleştirdikleri yönündeydi. O halde Claude’un GitHub issue’ları açmasını ya da daha iyisi, gözlemlenen sonuçları ve Fedify’ın bunları nasıl düzelttiğini depo içindeki .md dosyalarında belgelemesini sağlayabilirsiniz. Kendi debugger’ı da var, ne anlama geldiğini bilmediğim “best practice”leri de; tam buna uygun bir iş olurdu.

    • Gerçekten de önemsiz bir sorunu abartıp ActivityPub’ın başarısızlığı gibi sunuyor. Örneğin 5 bin takipçiniz varsa tek bir gönderi binlerce HTTP teslimatı demek; bunu doğrudan istek işleyicisinin içinde yaparsanız gönder düğmesinin yanıtı 30 saniye sürer ya da sunucu çöker, o yüzden kuyruk kullanın, gibi.
      Üçüncü taraf servislere giden istekleri neden inline çalıştırıyorsunuz? Bu, web uygulaması geliştirmenin temelidir. Üçüncü taraf servislerle iletişim kurmanız gerekiyorsa bunu arka plan işine göndermelisiniz. İsteğe yanıt vermek için gerekli olmayan bilgi varsa arka plan işine göndermelisiniz. İstek işleyicisinin içinde böyle istekler yapıp ortaya çıkan sorunlar, tırmığa basıp sapıyla yüzüne vurmak kadar kendi kendine çıkarılmış sorunlardır; ActivityPub’la ilgisi yoktur.
      Teslimat başarısız olursa yeniden denemek gerekir; zamanlama nasıl olacak, üstel geri çekilme kullanılacak mı, kaç kez denenecek, 500 Internal Server Error ile 410 Gone aynı başarısızlık mı sayılacak gibi şeyler de sıradan web uygulaması geliştirme meseleleridir. Bunlar bir iş kuyruğundan üçüncü taraf servislere istek atarken çıkan sorunlardır ve ActivityPub’la ilgisizdir. Çoğu web framework’ünde makul varsayılanlar bulunur. Yalnızca hangi hatanın oluştuğuna göre yeniden deneyip denememeye karar verilmesi gereken noktada muhakeme gerekir. 410’u yeniden denemek israftır ama acil çözülmesi gereken bir sorun değildir. İş kuyruğunun bellek baskısını artırır, ama uygulamayı birkaç saat içinde devirmesi pek olası değildir.

  • “Reddedilip reddedilmediğine bakın, başka bir şekilde yeniden imzalayın ve hangi sunucuda hangi yöntemin tuttuğunu hatırlayın” — ben ne okuyorum böyle? Mastodon geliştirmesinin yavaş olmasının nedeni bu mu?
    “Tek bir gönderi binlerce HTTP teslimatı”ymış; hem de ağ sistem programlama ve kuyruklama konusunda çok iyi olmasıyla ünlü Ruby’de.
    İnanması zor; bunu bir kütüphaneyle sarmalamış olmaları iyi ama yine de tuhaf.

  • Java ile ActivityPub uyguladıktan sonra, bu tür sunucular arası protokollerin en iyisinin doğrudan git üzerine kurulması olduğu sonucuna vardım.
    Karmaşıklığın önemli bir kısmı, git’in zaten daha iyi çözdüğü sorunları yeniden çözmek için var. Bunu bir git deposu içindeki JSON belgeleri olarak modellerseniz sayfalamayla uğraşmanız gerekmez. Protokol zaten yalnızca eksik verinin gönderilmesini garanti eder, commit imzaları elde edersiniz, olay sıralaması garantisi elde edersiniz, bu yazıda bahsedilen sorunlar çözülür ve geçmiş de bedavaya gelir. Böyle protokollerin içinde hatalı ve yavaş bir yarım git uygulaması vardır diye Greenspun’ın onuncu yasasına benzer bir söz uydurulabilir.

    • git, geçmişin ebeveyn commit’lere bağlı olmasından dolayı harika bir seçim değil. Ancak benzer bir pazarlık stratejisiyle çalışan Merkle ağacı gossip protokolü iyi uyabilir.

  • Bu yazı yapay zeka tarafından üretilmiş düşük kaliteli bir yazı gibi okunuyor.
    Daha somut olarak, neden hikâye formatında yazıldığını anlamadım. Burada aktarılan olgular çok daha kısa ve daha az taraflı biçimde yazılabilirdi; anlatı da ikna edici değil. Özellikle yapay zekaya özgü ifadeler çok fazla olduğu için.
    Keyifle okunmadı. Yine de sorunlara işaret ettiği için teşekkürler; umarım insanlar o sorunları başka bir biçimde okuyup düzeltebilir.