TEKNİK YAZI / API Tasarımı ve Entegrasyonlar

ActivityPub Nedir? Fediverse'ün Federasyon Protokolü

ActivityPub, Mastodon gibi fediverse sunucularının birbiriyle konuştuğu W3C protokolüdür: actor, inbox, WebFinger, HTTP Signatures ve gizlilik sınırları.

Yayınlandı: Güncellendi:

ActivityPub, farklı sunuculardaki kullanıcıların birbirini takip etmesini ve içerik paylaşmasını sağlayan, W3C’nin Ocak 2018’de yayımladığı açık bir sosyal ağ protokolüdür. Mastodon, Pixelfed, PeerTube ve Lemmy gibi birbirinden bağımsız yazılımlar bu ortak protokol sayesinde birlikte çalışır; bu sunucuların oluşturduğu ağa fediverse (federe evren) denir.

Protokolün yapı taşları actor, inbox, outbox ve ActivityStreams’tir. Bir takip isteğinin sunucular arasında izlediği yol, pratikte zorunlu olan WebFinger ve HTTP Signatures, gizlilik sınırları ve Bluesky’nin kullandığı AT Protocol ile farklar bu yapı taşları üzerinden açıklanıyor.

ActivityPub nedir?

ActivityPub, veri biçimi olarak ActivityStreams 2.0’ı kullanır. ActivityStreams, “kim, neyi, hangi nesne üzerinde yaptı” bilgisini JSON-LD tabanlı bir sözlükle tanımlar. Protokol iki katmandan oluşur:

Spesifikasyon, bir sunucunun bu katmanlardan yalnız birini uygulayabileceğini açıkça belirtir. Fediverse’te belirleyici olan S2S katmanıdır. Mastodon C2S’yi uygulamaz; Mastodon istemcileri sunucuyla Mastodon’un kendi REST API’si üzerinden konuşur, sunucular ise birbirleriyle ActivityPub kullanır.

ActivityPub’ın mantığı e-postaya benzer: Gmail kullanıcısı Outlook kullanıcısına e-posta gönderebildiği gibi, bir Mastodon kullanıcısı da bir Pixelfed hesabını takip edebilir. Fark, iletilen şeyin e-posta değil, yapılandırılmış sosyal etkinlikler olmasıdır.

Temel kavramlar

Actor: Etkinlik yapan varlıktır; kullanıcı, grup veya bot olabilir. Her actor’ün kimliği, JSON belgesi döndüren bir URL’dir. Spesifikasyona göre her actor’ün bir inbox (gelen etkinlikler) ve bir outbox (ürettiği etkinlikler) koleksiyonu bulunmalıdır. Mastodon’da https://mastodon.social/@Gargron tarayıcı için HTML profil sayfasıdır; actor kimliği ise https://mastodon.social/users/Gargron adresidir.

Basitleştirilmiş bir actor belgesi:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    "https://w3id.org/security/v1"
  ],
  "id": "https://example.com/users/alice",
  "type": "Person",
  "preferredUsername": "alice",
  "inbox": "https://example.com/users/alice/inbox",
  "outbox": "https://example.com/users/alice/outbox",
  "followers": "https://example.com/users/alice/followers",
  "following": "https://example.com/users/alice/following",
  "publicKey": {
    "id": "https://example.com/users/alice#main-key",
    "owner": "https://example.com/users/alice",
    "publicKeyPem": "-----BEGIN PUBLIC KEY-----\n...\n-----END PUBLIC KEY-----"
  }
}

publicKey alanı spesifikasyonun parçası değildir; aşağıda anlatılan HTTP imzalarını doğrulamak için fediverse’te yaygın olarak kullanılır.

Activity: Bir eylemdir: Create, Follow, Accept, Like, Announce (Mastodon’daki boost), Update, Delete, Undo.

Object: Eylemin konusu olan içeriktir: Note, Article, Image, Video gibi.

Adresleme: to ve cc alanları etkinliğin kime gideceğini belirtir. https://www.w3.org/ns/activitystreams#Public herkese açık gönderiyi, takipçi koleksiyonu ise yalnız takipçileri hedefler.

Bir gönderi oluşturma etkinliği:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://example.com/activities/1",
  "type": "Create",
  "actor": "https://example.com/users/alice",
  "object": {
    "id": "https://example.com/notes/1",
    "type": "Note",
    "content": "Fediverse'e ilk gönderi",
    "to": ["https://www.w3.org/ns/activitystreams#Public"],
    "cc": ["https://example.com/users/alice/followers"]
  }
}

WebFinger: kullanıcı adından actor’e

Kullanıcılar birbirini @alice@example.com biçimindeki adlarla bulur; ActivityPub ise URL ile çalışır. Aradaki çeviriyi ActivityPub’ın parçası olmayan WebFinger (RFC 7033) yapar. Sunucu, adresteki alan adına standart bir sorgu gönderir:

curl -s "https://mastodon.social/.well-known/webfinger?resource=acct:Gargron@mastodon.social"

Yanıttaki rel: "self" ve type: "application/activity+json" bağlantısı actor URL’sini verir (çıktı kısaltıldı):

{
  "subject": "acct:Gargron@mastodon.social",
  "aliases": [
    "https://mastodon.social/@Gargron",
    "https://mastodon.social/users/Gargron"
  ],
  "links": [
    {
      "rel": "self",
      "type": "application/activity+json",
      "href": "https://mastodon.social/users/Gargron"
    }
  ]
}

Sunucu ardından bu URL’den actor belgesini çeker ve inbox adresini öğrenir.

Federasyon nasıl çalışır: bir takip isteği

Alice (mastodon.social), Bob’u (pixelfed.social) takip etmek istiyor:

  1. Alice’in sunucusu @bob@pixelfed.social adını WebFinger ile çözer, Bob’un actor belgesini çeker ve inbox adresini öğrenir.
  2. Bir Follow etkinliği oluşturur, isteği Alice’in özel anahtarıyla imzalar ve Bob’un inbox’ına HTTP POST ile gönderir.
  3. Bob’un sunucusu imzadaki keyId üzerinden Alice’in açık anahtarını çeker ve imzayı doğrular.
  4. Bob’un hesabı takip isteklerini otomatik kabul ediyorsa ya da Bob onaylarsa, Bob’un sunucusu Alice’in inbox’ına bir Accept etkinliği gönderir.
  5. Bob yeni bir gönderi paylaştığında sunucusu Create etkinliğini takipçilerin sunucularına teslim eder. Aynı sunucuda çok takipçi varsa teslim genellikle sunucunun ortak gelen kutusuna (sharedInbox) bir kez yapılır.
{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://mastodon.social/follows/12345",
  "type": "Follow",
  "actor": "https://mastodon.social/users/alice",
  "object": "https://pixelfed.social/users/bob"
}

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "id": "https://pixelfed.social/users/bob#accepts/12345",
  "type": "Accept",
  "actor": "https://pixelfed.social/users/bob",
  "object": "https://mastodon.social/follows/12345"
}

Etkinlik kimlikleri (id) sunucuya göre farklı biçimde üretilir; örnekteki yollar temsilîdir.

Teslim, karşı sunucu geçici olarak erişilemez olabileceği için arka planda ve yeniden denemeyle yapılır. Mastodon bu işi Sidekiq iş kuyruklarıyla yürütür: push kuyruğu diğer sunuculara teslimi, ingress kuyruğu gelen etkinlikleri işler (Mastodon ölçekleme belgesi). Kuyruk, onay ve yeniden deneme kavramlarının genel hâli RabbitMQ yazısında anlatılıyor.

HTTP Signatures

ActivityPub spesifikasyonu kimlik doğrulama yöntemi belirlemez; metnin kendisi, standartlaşma sırasında üzerinde uzlaşılmış bir yöntem olmadığını söyler. Fediverse’te bu boşluğu HTTP Signatures doldurur. Mastodon, aldığı her etkinliğin gerçekten iddia edilen actor’den geldiğini HTTP imzasıyla doğrular; imzasız veya doğrulanamayan teslimler işlenmez.

Basitleştirilmiş bir teslim isteği:

POST /users/bob/inbox HTTP/1.1
Host: pixelfed.social
Date: Fri, 09 Oct 2026 09:00:00 GMT
Digest: SHA-256=...
Content-Type: application/activity+json
Signature: keyId="https://mastodon.social/users/alice#main-key",headers="(request-target) host date digest",signature="..."

Digest başlığı gövdenin SHA-256 özetini taşır ve imzalanan başlıklar arasında yer alır; böylece gövde yolda değiştirilemez. Mastodon tarihsel olarak HTTP Signatures’ın IETF taslak sürümünü (draft-cavage) kullanır; standartlaşmış hâli olan RFC 9421 (HTTP Message Signatures) için gelen istek desteği 4.4’te bayrak arkasında geldi ve 4.5’ten beri varsayılan olarak açıktır.

Güvenli mod (secure mode) açık sunucular GET isteklerinde de imza ister. Bu yüzden bir actor belgesini curl ile imzasız çekmek her sunucuda çalışmaz; böyle sunucular 401 döndürür.

Fediverse’teki uygulamalar

Bu yazılımlar takip, yanıt, beğeni ve paylaşım gibi temel etkileşimlerin çoğunda birlikte çalışır. Birlikte çalışabilirlik kısmidir: her uygulama her nesne türünü ve her etkinliği aynı biçimde desteklemez ya da göstermez.

Protokol, büyük platformlar ve yayıncılık araçları arasında da yayılıyor:

Bluesky ve AT Protocol ile farkı

Bluesky, ActivityPub yerine kendi geliştirdiği AT Protocol’ü kullanır. İki protokol aynı sorunu farklı varsayımlarla çözer:

KonuActivityPubAT Protocol
KimlikSunucunun alan adına bağlı actor URL’siKalıcı merkeziyetsiz kimlik (DID); kullanıcı adı bir alan adıdır
VeriHer sunucu kendi kullanıcılarının verisini tutar, uzak sunucular kopya alırKullanıcı verisi kişisel veri sunucusunda (PDS) imzalı bir depoda durur
DağıtımSunucudan sunucuya doğrudan inbox teslimiRelay’ler değişiklikleri tek bir akışta (firehose) toplar, AppView’lar bu akıştan uygulama görünümü üretir
Hesap taşımaMastodon takipçileri Move ile yeni hesaba yönlendirir, gönderiler taşınmazHesabın, eski sunucunun katılımı olmadan yeni bir PDS’e taşınabilmesi tasarım hedefidir

Mastodon’da hesap taşıma takipçileri yeni hesaba aktarır, gönderileri taşımaz (Mastodon: hesap taşıma). İki ağ doğrudan birbirine bağlı değildir; Bridgy Fed gibi köprüler hesapları iki tarafta da görünür kılar.

Gizlilik ve güvenlik sınırları

Teknik zorluklar

Ölçekleme: Çok takipçili bir hesabın her gönderisi binlerce sunucuya teslim edilmelidir. Ortak gelen kutusu teslim sayısını azaltır, ancak yük ve yeniden deneme maliyeti sürer.

Arama ve keşif: Merkezi bir dizin yoktur. Bir sunucu yalnız kendisine federasyonla ulaşan içeriği bilir; bu nedenle arama ve keşif sunucudan sunucuya farklıdır.

Medya depolama: Sunucular uzak gönderilerdeki medyayı genellikle kendi önbelleklerine kopyalar. Küçük sunucular için depolama ve bant genişliği önemli bir maliyettir.

Gerçek zamanlı akış: Federasyon sunucular arasında çalışır; kullanıcının ekranına canlı güncelleme ise ayrı bir konudur. Mastodon’un istemciler için sunduğu streaming API’si bu iş için Server-Sent Events veya WebSocket kullanır.

Nasıl başlanır?

Kullanıcı olarak: joinmastodon.org üzerinden kuralları ve moderasyon politikası size uyan bir sunucu seçin. Sunucunun kimlerle federasyonu kestiğine ve ne kadar süredir ayakta olduğuna bakın. Teknik bilginiz ve zamanınız varsa kendi sunucunuzu da kurabilirsiniz; bu durumda moderasyon, yedekleme ve güncelleme sorumluluğu size geçer.

Geliştirici olarak: Asgari bir federasyon uygulaması için actor belgesi, WebFinger yanıtı, imza doğrulayan bir inbox ve imzalı teslim yapan bir arka plan işleyicisi gerekir. Uygulamayı gerçek sunuculara açmadan önce Mastodon gibi yaygın bir yazılımla birlikte çalıştığını test edin.

Sonuç

ActivityPub, sosyal ağ sahipliğini tek bir uygulamadan protokol ve sunucu seçimine taşır. Bu yapı farklı yazılımlar arasında birlikte çalışabilirlik sağlar; ancak içerik keşfi, moderasyon, teslim garantileri, gizlilik ve sunucular arası güven gibi sorunları ortadan kaldırmaz. Bir uygulamayı federasyona açmadan önce kimlik, imza doğrulama, tekrar teslim ve kötüye kullanım akışları birlikte tasarlanmalıdır. Hesap taşınabilirliği öncelikliyse AT Protocol’ün farklı tasarımı da değerlendirilmeye değer.

Birincil kaynaklar