fedify’den ayrılmak – Ayrıldıktan sonra fedify’nin iyi yanlarını fark etmek

(Bu, benim yönettiğim blogdaki bir yazıdır. Metin, birlikte çalıştığım yapay zeka asistanı Shiro’nun yardımıyla yazıldı; yanlış bir okuma varsa bildirirseniz sevinirim)

Küçük bir Fediverse (Mastodon gibi sunucuların birbirine bağlandığı SNS ağı) sunucusu olan sukhi-fedi’nin, JSON-LD derleme (mesajları sunucuların birbirini anlayabileceği bir biçime dönüştürme işi) ve HTTP imzalama (mesajın gerçekten geçerli olduğunu doğrulayan imza süreci) görevini üstlenen fedify’yi (Bun worker üzerinde çalışan kütüphane) kaldırıp her şeyi doğrudan Elixir ile yeniden uygulama sürecinin kaydıdır. Bu bir kötüleme yazısı değil; yazının yarısı tam tersine "ayrıldıktan sonra fedify’nin iyi yanlarını fark etmek" üzerine.

• Başta fedify’nin framework özelliklerini (createFederation, inbox listener, dispatcher vb. — federasyon işlevlerinin tamamını sizin yerinize ele alan üst seviye araçlar) hiç kullanmadım; sadece en alt katmandaki parçaları ödünç aldım:

  • vocab sınıfları
  • toJsonLd/fromJsonLd (mesaj biçimlerini karşılıklı dönüştüren dönüştürücüler)
  • hem draft-cavage hem de RFC 9421 olmak üzere iki imza yöntemini de bilen signRequest/verifyRequest
  • LD imzaları, document loader
  • anahtar/JWK (açık anahtarı taşıyan standart biçim) giriş/çıkışı

• Ayrılma nedenleri üç taneydi:

  1. Framework’ü kullanmamaya karar verdiğim anda, fedify’nin ücretsiz olarak hallettiği şeylerin (Follow için Accept yanıtı, idempotency, authorized fetch, instance actor) hepsini zaten kendim ele almak zorundaydım. Geriye sadece temel parçalar kaldığı için taşınacak işin miktarı da belliydi
  2. Hedefim 512~768MB bellekli küçük sunuculardı; dayanıklılık testlerinde Elixir 130MB ile istikrarlı biçimde tamamladı ama yalnızca Bun worker 120MB’de OOM (bellek yetersizliğinden çökme) verdi. Sistemde başka bir dilde çalışan tek parça, en ağır ve en zayıf olan parçaydı
  3. Dil ve süreç sınırının kendisi sorun üretiyordu. İmza doğrulaması için gereken ham veriyi korumak, tünelin değiştirdiği adresleri geri yüklemek, veritabanındaki anahtarları JWK olarak paketleyip başka sürece taşımak gibi işler fedify’nin suçu değildi ama giderek artan tesisat işlerine dönüşüyordu

• Değiştirme işi 12 dosya ve yaklaşık 2.100 satırla tamamlandı. Mesaj kuyruğu yapısı aynen bırakıldı, aynı gruba dahil edildi ve geçiş ise sadece "Bun container’ını durdurmak" oldu

• Güvenlik ağını kuran da ironik biçimde fedify’nin kendisiydi. Ed25519 imzaları ve URDNA2015 normalizasyonu (belgeyi her zaman aynı sırayla düzenleyen kural) aynı girdide her zaman aynı sonucu veren yöntemler olduğundan, gerçek fedify koduyla önceden "doğru veri" üretip Elixir’e taşıdıktan sonra sonucu tek karakter bile sapmadan doğrulamak mümkün oldu

• Bun worker emekliye ayrıldı ama silinmedi. Hâlâ geliştirme ortamında doğru veriyi üreten bir rol üstleniyor

• fedify ekibi, ActivityPub hata ayıklama aracı DrFed’i (https://drfed.org/) geliştiriyor. Federasyonun hangi aşamada (DNS/TLS/HTTP/imza/JSON-LD) bozulduğunu gösteren tanılama özellikleri ve iki imza yöntemini de adım adım izleyebileceğiniz bir debugger gibi araçlar içermesi planlanıyor (NLnet NGI0 destekli, AGPL-3.0 açık kaynak, şu anda geliştirme aşamasında)

• Sonuç olarak: TypeScript/JavaScript ile framework’ü bütünüyle kullanacaksanız, fedify hâlâ en iyi seçeneklerden biri demek mümkün. Ghost’un ActivityPub özelliği, hackers.pub ve Hollo da onun üzerinde çalışıyor