Nostr aslında nasıl çalışır: protokol, jargon olmadan

Nostr hakkındaki çoğu açıklama "bu merkeziyetsiz bir sosyal protokoldür" diyerek durur ve ilginç kısım söylenmeden kalır. İlginç kısım, tüm protokolün kısa bir belgede sığması. Hiç olmadı, gömülü karmaşıklık yok. Birlikte çalışan sadece birkaç ilkel.

Bu rehber, Nostr'u gerçekte kullanırken ortaya çıkan sırayla bu ilkelleri anlatır: bir event nasıl oluşturulur, nasıl imzalanır, relaylere nasıl ulaşır, istemciler nasıl abone olur ve bir yazıyı beğendiğinizde, yanıt aldığınızda veya bir zap aldığınızda akış nasıl görünür. Blockchain karşılaştırmaları yok, büyük anlatı yok. Sadece mekanik.

TL;DR. Nostr, WebSockets üzerinden pub/sub'dir ve kriptografik imzaları vardır. İstemciler imzalı JSON nesnelerini (events) relaylara (küçük sunucular) yayınlar ve diğer istemciler istedikleri eventleri eşleştiren filtrelerle relaylara abone olurlar. İmzalar taklifi önler; birden fazla relay tek bir arıza noktasını önler. Bu, protokolün tamamıdır; geri kalan her şey farklı içerik türleri için biçimlendirme kurallarıdır.

When you're ready, grab your @nostr.blog address →

Yapı taşı: bir event

Nostr'da her şey bir event'tir. Bir yazı bir event'tir. Bir reaksiyon bir event'tir. Bir profil güncellemesi bir event'tir. Doğrudan bir mesaj bir event'tir. Bir zap makbuzu bir event'tir.

Bir event, tam olarak bu şekilde bir JSON nesnesidir:

{
  "id": "abc123...",
  "pubkey": "0a4f7b1a3d9a1529a3080c3ae5ee553e0af0a01d86d01677c0bb270592923f88",
  "created_at": 1776329035,
  "kind": 1,
  "tags": [
    ["t", "nostr"],
    ["p", "3bf0c63f..."]
  ],
  "content": "hello nostr",
  "sig": "def456..."
}

Altı alan anlamlı çalışmalar yapar. id, event'in kendi içeriğinin bir hash'idir; event'i benzersiz şekilde tanımlar. pubkey yazar (64 karakterlik hexadecimal ortak anahtar). created_at Unix zaman damgası. kind, event'in neyi temsil ettiğini açıklayan bir tamsayı (aşağıda daha fazlası). tags hashtag'ler (t), bahsetmeler (pubkey için p, event için e) ve onlarca diğeri gibi yapılandırılmış açıklamaların bir listesidir. content genellikle metin olan serbest biçim yükü.

sig Schnorr imzasıdır, yazar'ın özel anahtarıyla, id'deki hash üzerinde yapılır. Bu, taklifi önleyen alan: herkes hash'i hesaplayabilir, ancak yalnızca özel anahtarın sahibi üzerinde geçerli bir imza üretebilir.

"kind" nedir?

kind alanı istemcilere event'i nasıl yorumlayacaklarını söyler. Sayı, tüm anlamsal türdür.

Aktif kullanımda bir avuç kind:

Yeni kind'ler NIP'ler (Nostr Implementation Possibilities) aracılığıyla önerilir ve standardlaştırılır. Herkes bir tane önerebilir. Yaygın olarak benimsenenleri, protokolün fiili parçaları haline gelir; olmayanlar basitçe hiçbir şeyi bozmadan niş kalır.

Bir event nasıl yayınlanır

Nostr istemcisinde "gönder"e dokunduğunuzda bu dizi çalışır:

1. İstemci JSON'ı birleştirir. pubkey, created_at, kind, tags, content'i doldurur.
2. İstemci id'yi hesaplar. Bu alanların kanonik serileştirmesi üzerinde SHA-256 çalıştırır. Bu, imza kapsamındaki hash'tir.
3. İstemci id'yi özel anahtarla imzalar. secp256k1 üzerinde Schnorr imzası, Bitcoin'in kullandığı aynı eğri. 64 baytlık imza sig alanı olur.
4. İstemci, yapılandırılan her relaya WebSocket bağlantıları açar. Veya yayında ise varolan olanları yeniden kullanır.
5. İstemci event'i mesaj olarak gönderir. Tel üzerindeki format bir JSON dizisidir: ["EVENT", {...event...}].
6. Her relay imzayı doğrular. İmza iddia edilen pubkey'e karşı doğrulanmazsa event'i reddeder. Aksi takdirde kabul eder ve depolar.
7. Her relay event'i abone olanlara gönderir. Açık aboneliği olan ve bu event'le eşleşen filtreye sahip herhangi bir istemci, event'i gerçek zamanlı olarak teslim alır.

Tüm tur 50 ile 300 milisaniye arasında sürer, relay konumlarına bağlı olarak. Herhangi bir relay yavaşsa veya çevrimdışı ise, diğer relaylar yine de event'i yayınlar. Event'in ağda var olması için sadece bir relaya ihtiyacınız vardır.

Bir istemci yazıları nasıl alır

Okumak, yayınlamanın aynasıdır.

İstemciniz, relayların bir listesine WebSocket bağlantıları açar. Her biri için bir abonelik mesajı gönderir:

["REQ", "sub_id_1", { "authors": ["pubkey1", "pubkey2", ...], "kinds": [1, 6], "limit": 50 }]

Bu, relayden listedeki yazarlardan 50 event'e kadar, kind 1 (kısa not) veya kind 6 (repost) ister. Relay:

1. Eşleşen event'ler için yerel veritabanını sorgular, bunları (varsayılan olarak en eskiden en yeniye, limite kadar) istemciye EVENT mesajları olarak gönderir.
2. Tarihsel döküm tamamlandığını istemciye bildirmek için EOSE (saklanan event'lerin sonu) mesajı gönderir.
3. Aboneliği açık tutar. Daha sonra filtreyle eşleşen herhangi bir yeni event (başka biri tarafından yayınlanan) istemciye gerçek zamanlı olarak gönderilir.

Bu, akışınızın canlı hale gelmesidir. Anket yapmıyorsunuz; relay akışını yapıyor.

İstemciniz bunu yapılandırılan her relaya paralel olarak yapar. Yanıtların birleşimi zaman çizelgenizdir. Relaylar arasında yinelenen event'ler id ye göre çoğaltılmamıştır.

İmzalar aslında taklifi nasıl önler

Bu, çoğu açıklamanın üzerinden geçtiği kısımdır.

Bir istemci bir event aldığında, kanonik serileştirme üzerinden hash'i yeniden hesaplar (yayıncı yaptığı gibi) ve Schnorr doğrulaması çalıştırır: pubkey, id ve sig verilen, imza kriptografik olarak kontrol edilir mi?

Evetse, event gerçektir. Bu event'in yazarı, o anda o pubkey'in sahibiydi. Her istemci, gördüğü her event üzerinde bu kontrolü çalıştırır. Kötü bir imza ile sahte bir event gönderen bir relay, onu gören her istemci tarafından sessizce düşürülür.

Bu önemlidir, çünkü relayler güvenilmez olduğu anlamına gelir. Kötü niyetli bir relay sizi ağzından koparamaz. Yazılarınızı sunmayı reddedebilir, başka birinin (meşru) yazılarını akışınıza enjekte edebilir, ancak özel anahtarınız olmadan sizin tarafından imzalanan geçerli bir yazı üretemez ve özel anahtarınız olmadan var olan bir yazınızı imzayı bozmadan değiştiremez.

Bu özelliğin maliyeti, tam olarak event başına bir Schnorr doğrulamasıdır ve mobil istemciler bile saniyede on binlerce event'i işleyebilecek kadar hızlıdır.

Relayler aslında ne yapar

Relay, üç işi olan aptal, hızlı bir borudur:

1. Event'leri kabul edin ve imzaları doğrulayın. Doğrulanmayan veya politika kontrollerinde başarısız olan her şeyi reddeder (spam filtreleri, boyut sınırları, engellenen pubkey'ler).
2. Event'leri saklayın. Genellikle id, pubkey, kind ve tag değerleri tarafından dizin oluşturulan bir SQLite veya PostgreSQL veritabanında.
3. Aboneliklere hizmet edin. Gelen REQ filtrelerini veritabanıyla (tarihsel için) ve canlı event'lerle (gerçek zamanlı için) eşleştirin.

Hepsi bu. Relay sıralamaz, tavsiye etmez, seçim yapmaz, para kazanmaz, reklam göstermez, algoritma uygulamaz veya bir platform'un yapacağı hiçbir şey yapmaz. İmzalı baytları iletir.

Diğer işlerin yokluğu, relaylerin neden bu kadar küçük olabilmesinin nedenidir. Tek bir 5 dolar/aylık VPS, yüzlerce aktif kullanıcıya hizmet eden bir relay çalıştırabilir. Twitter'da aynı işlev milyarlara mal olur, çünkü Twitter diğer tüm işleri yapar.

Relay politikaları farklılık gösterir. Bazıları izinsiz ve herhangi bir imzalı event'e hizmet eder. Bazıları ödeme gerektirir ("ücretli relay" modeli), diğerleri belirli bir topluluğa kısıtlanır (bir şirketin çalışanları, bir Discord sunucusunun üyeleri) ve yine de bazıları spam filtrelemesi hakkında agresiftir. Hangi relayleri kullanacağınızı seçersiniz; seçiminiz hangi yazıları gördüğünüzü ve hangilerinin takipçilerinize ulaştığını etkiler.

Tam bir örnek: biri yazınızı beğenir

Hepsini bir araya getirerek, Alice Bob'un yazısını beğendiğinde end to end'de ne olacağını açıklamasıdır.

1. Bob yayınlar. Bob'un istemcisi, içeriği "hello world" olan bir kind:1 event oluşturur, imzalar, Bob'un beş yapılandırılan relayına gönderir. Her relay kabul eder ve depolar.
2. Alice abone olur. Alice'nin istemcisinin bunlardan ikisinde Bob'un pubkey'ini authors'de içeren bir filtreyle açık aboneliği vardır. Relayler Bob'un event'ini abonelik aşağıya gönderir. Alice'nin istemcisi yazıyı zaman çizelgesinde gösterir.
3. Alice beğen'e dokunur. Alice'nin istemcisi, içeriği "+" olan bir kind:7 event oluşturur (Nostr "beğeni" kuralı), yanıt verdiği yazıyı (["e", "bob_post_id"]) ve yazarı (["p", "bob_pubkey"]) etiketler. İmzalar ve Alice'nin beş yapılandırılan relayına yayınlar.
4. Reaksiyon yayılır. { "#e": ["bob_post_id"], "kinds": [7] } filtreyle eşleşen açık aboneliği olan herhangi bir relay (Bob'un event'inin yanıtlarını izlemek için kullandığı), reaksiyonu Bob'a gönderir. Bob'un istemcisi beğenileri toplar ve yazının altında sayıyı gösterir.

Olmayanı dikkat edin. Hiçbir merkez "beğen düğmesi" hizmeti çalıştırıldı. Arka uç beğenmenin sayılıp sayılmayacağına karar vermedi. Beğeni sadece imzalı bir event'tir, yazının kendisiyle aynı kanallarda duyurulanır.

Nostr açıkça yapmaz ne

Beş şey, çekirdek protokolü dışında kasıtlı olarak bırakılmıştır, çünkü bunlar istemci veya relay'e ait, paylaşılan tel biçimine değil.

• Kimlik doğrulama. Nostr sadece "bu pubkey bu yazıyı imzaladı" kanıtlar. Pubkey'in belirli bir insan olmadığını, NIP-05 ve zincir dışı bağlamla cevaplandırılan ayrı bir sorudur.
• İçerik denetimi. Protokol neyin görünür olduğuna karar vermez. İstemciler filtreler, relayler filtreler, kullanıcılar filtreler. Her katman bağımsız olarak.
• Ara. Genel arama uç noktası yoktur. Bazı relayler yerel event havuzları üzerinde metin aramasını destekler; hiçbir protokol garantisi yoktur ki herhangi bir relay herhangi bir yazıyı bulabilir.
• Algoritmik sıralama. Protokolde "sizin için" akışı yok. Varsa sıralama istemcide olur.
• Hesap kurtarma. E-posta sıfırlaması yok, telefon sıfırlaması yok, merkez uyuşmazlık sistemi yok. Özel anahtarı kaybetme, kimliği kaybetme. Bu, bir özellik değil, bir değiş tokuş.

Bu yokluklar, protokolü küçük yapan şeydir. Merkez olmayan bir platform'un üzerine cilalı bir kullanıcı deneyimi oluşturmayı, merkez bir platform'un üzerine oluşturmaktan daha zor yaparlar, bu da dürüst maliyettir.

Tasarım neden hiç çalışır

Tasarım bir basit özelliğe güvenir: imzaları doğrulamak ucuzdur, özel anahtar olmadan taklit imkansızdır ve relayler özgürce değiştirilecektir.

Bu üç olgu bileşik. Ucuz doğrulama, her istemcinin her event'i kontrol edebilmesi anlamına gelir. İmkansız taklit, relaylara güvenilmesi gerekliliğini saf dışı bırakır. Özgür değişim, hiçbir relayın kimse üzerinde gücü olmadığı anlamına gelir.

Bir araya getirilenler, platform katmanının değiştirilebilir olduğu ve kimlik katmanının kullanıcı tarafından sahip olunduğu bir sosyal ağ elde edersiniz. "Merkeziyetsiz"in pratikte gerçekten anlamı budur, pazarlama genellikle kelimeyi nasıl kullanırsa kullanır.

Kullanıcı tarafından akışın tamamını görmek istiyorsanız (bir anahtar çifti, NIP-05 kimliği, relay listesi, cüzdan, göndermek için hazır), nostr.blog'un kaydı bu adımları bir sayfaya daraltır. Burada açıklanan mekanik, o akışın altında gerçekten çalışan şeydir.