Nostr NIP'leri açıklandı: protokolün belirtim belgeleri

Nostr'un evrimi, anyone'ın önerebileceği kısa belirtim belgeleri olan NIP'ler aracılığıyla gerçekleşir. Zap'lar veya şifreli DM'ler gibi yeni özelliklerin protokole nasıl girdiğini anlamak istiyorsanız, NIP'ler cevaptır.

Bu rehber NIP'lerin ne olduğunu, yönetişim mekanizması olarak nasıl çalıştığını ve teknik olarak ilerliyorsanız hangilerini okumanız gerektiğini kapsar.

NIP'ler, Nostr özelliklerinin nasıl uygulanacağını önerilen GitHub'daki kısa markdown belgeleridir. İstemci geliştiricileri hangilerini destekleyeceklerini seçer. Yeterli sayıda uygulayıcı bunu benimsediğinde bir NIP "gerçek" olur. Yaygın olarak kullanılan NIP'lerin temel kümesi yaklaşık 30; tam liste yaklaşık 100'e yakındır.

Hazır olduğunda, @nostr.blog adresini al →

Bir NIP aslında nedir

Bir NIP, github.com/nostr-protocol/nips deposundaki bir markdown dosyasıdır. Her dosya spesifik bir özellik, format veya kuralı açıklar: olayları imzalamak, bir profil meta veri olayının neye benzediği, doğrudan ileti göndermek, Lightning zap isteklerinin hangi formatı kullandığı.

Boyut değişir. En kısa NIP'ler bir sayfanın altında; en uzunları birkaç bin kelimedir. Çoğu 500 ile 2000 kelime arasında oturur. Bunlar belirtimden tek başına uygulanabilir olacak şekilde yazılır, bu nedenle ileti formatları, gerekli alanlar ve örnek olaylar içerirler.

Adlandırma kuralı NIP-XX'dir; burada XX bir sayıdır. Sayılar NIP birleştirildiğinde atanır; önceliği veya önemini yansıtmazlar. NIP-05 doğrulanmış tanımlayıcılar hakkındadır; NIP-04 eski DM standardıdır; NIP-01 temel protokoldür. Sayılar, özellik önem sırasını değil, teklif sırasını takip eder.

Neden "Uygulama Olasılıkları"

İsim kasıtlı bir seçimdir. Diğer belirtim gelenekleriyle karşılaştırın.

• RFC'ler (İnternet Protokolleri Hakkında Teklifler) genellikle birlikte çalışabilirlik için zorunlu hale gelir.
• EIP'ler (Ethereum Geliştirme Önerileri) genellikle ağ yükseltmesi yoluyla zorunlu hale gelir.
• NIP'ler kalıcı olarak isteğe bağlıdır. 40 NIP uygulayan bir istemci ve 10 NIP uygulayan bir istemci her ikisi de geçerli Nostr istemcileridir; sadece farklı alt kümelerini yaparlar.

Bu, NIP'lerin mevcut uygulamaları asla "kıramayacağı" anlamına gelir. Bazı özellikler için yeni bir NIP, eski istemcileri değiştirilmeye zorlamaz. Protokol kenarlarında büyürken çekirdek istikrarlı kalır.

NIP yaşam döngüsü

Yeni bir NIP'in nasıl var olduğu:

1. Birileri bir boşluk veya ihtiyaç fark eder. "X'i yapmanın standart bir yolu yok." İstemci geliştiricisi, relay operatörü veya belirli bir sorundan hoşnut olmayan bir kullanıcı olabilir.
2. Bir taslak yazarlar. Format mevcut NIP'leri takip eder: başlık, amaç, belirtim, örnekler.
3. NIP'ler deposuna bir çekme isteği gönderirler.
4. Topluluk gözden geçirir. Geliştiriciler, relay operatörleri ve ilgili kullanıcılar yorum yaparlar. Taslak feedback'e göre revize edilir.
5. Birleştir veya terk et. Birleştirilen NIP'ler bir numara alır ve deponun parçası olur. Terk edilen taslaklar çekme isteği tarihçesinde kalır.
6. Uygulama takip eder (veya olmaz). Bazı NIP'ler haftalar içinde uygulanır. Bazıları yıl bekler. Bazıları asla yaygın olarak uygulanmaz.

Süreç hafiftir. Komite oylaması, resmi onay yoktur. Çekme isteği geniş pozitif feedback alır ve açık bir ihtiyacı ele alırsa, birleştirilir.

Bir kullanıcı olarak önemli olan NIP'ler

Çoğu NIP kullanıcılar için görünmezdir. Bir avuç günlük deneyiminizi etkiler:

• NIP-01: Temel protokol. Olayların nasıl yapılandırıldığı ve imzalandığı. Bunu asla görmezsiniz, ancak başka her şey buna bağlıdır.
• NIP-05: Doğrulanmış tanımlayıcılar. Size you@domain.com okunabilir adları verir. NIP-05 rehberimiz bunu kapsar.
• NIP-07: Tarayıcı uzantısı imzalama. Web istemcilerinin özel anahtarınızı görmeden imzalamasına izin verir.
• NIP-19: Bech32 kodlaması. Genel anahtarınızın neden ham hex yerine npub1... gibi görüntülendiği.
• NIP-23: Uzun form makaleler. Nostr'da blog stilinde gönderileri etkinleştirir.
• NIP-44: Şifreli DM'ler. Modern doğrudan mesajlaşma standardı (eski NIP-04'ten daha iyidir).
• NIP-57: Zap'lar. Genel makbuzlu Lightning ipuçları.
• NIP-98: HTTP kimlik doğrulaması. Nostr kimliklerinin normal web sitelerine kimlik doğrulamasını sağlar.

Kullanıcı olarak tüm bunlarından faydalanırsınız; bunlarla etkileşime geçmezsiniz. İstemciler protokol ayrıntılarını işler.

Bir geliştirici olarak önemli olan NIP'ler

Nostr istemcisi yazıyorsanız veya bakıyorsanız, okunması gereken NIP'ler düzine sayıya çıkar:

• NIP-01 ile NIP-10 (temel mekanik).
• NIP-11 (relay bilgi belgeleri).
• NIP-13 (spam direnci için iş kanıtı).
• NIP-17 (meta veri gizleme için hediye sarılı DM'ler).
• NIP-22 (olay sona erme).
• NIP-27 (metin notu referansları).
• NIP-30 (özel emoji).
• NIP-31 (olay türleri).
• NIP-33 (parametreleştirilmiş değiştirilebilir olaylar).
• NIP-42 (relay'lere bağlantı kimlik doğrulaması).
• NIP-47 (Nostr Cüzdan Bağlantısı).
• NIP-50 (arama yeteneği).
• NIP-65 (relay listesi meta verileri).
• NIP-78 (rasgele özel uygulama verileri).

Bunlar çoğu ana akım istemcinin uyguladığı olanlarıdır. Bu seti ve yukarıdaki kullanıcı yüzlü NIP'leri destekleyen bir istemci, tipik kullanımın %95'ini kapsar.

Bir NIP okuma

Doğrudan birini okumak istiyorsanız, depo github.com/nostr-protocol/nips adresindedir. Çoğu NIP'in yapısı:

• Başlık ve açıklama. NIP'nin ne önerdiği.
• Motivasyon. Özelliğin neden gerekli olduğu.
• Belirtim. Tam ileti formatı, gerekli alanlar, doğrulama kuralları.
• Örnek olaylar. Uyumlu bir olayın neye benzediğini gösteren somut JSON.
• İstemci/relay davranışı. Uygulamaların olayları nasıl işlemesi gerektiği.

NIP'ler, onları uygulayan geliştiriciler tarafından okunabilir olacak şekilde yazılır. Belirtim bölümü önemli olan bölümdür; gerçek protokolün bulunduğu yer burasıdır.

Kısmi benimsenen NIP'ler

Bazı NIP'ler var olur ancak istemciler arasında tutarsız bir şekilde uygulanır. Bu, deneyiminizin istemciye göre değiştiği kenar durumlar oluşturur.

NIP-44 (şifreli DM'ler). Damus, Primal, Amethyst ve çoğu ana istemci tarafından 2024-2025'te benimsendi. Bazı eski istemciler hala yalnızca NIP-04'ü destekler. Istemcisi yalnızca NIP-04'ü destekleyen birine DM gönderirseniz, NIP-44 mesajlarınız sessizce başarısız olur. Pratik cevap: modern bir istemci kullanın ve karşınızdaki kişinin de öyle yaptığını umun.

NIP-17 (hediye sarılı DM'ler). Meta veri gizleme DM'leri. 2026'daki benimseme büyüyor ancak evrensel değil. Özellik, her iki tarafın istemcisi bunu desteklediği yerde harika; aksi halde sessizce daha az güvenli DM'lere geri döner.

NIP-46 (uzak imzalayanlar). Donanım imzalayıcı veya bunker uygulamasının bir istemci adına olayları imzalamasına izin verir. Amethyst'te desteklenir, diğer yerlerde kısmi.

NIP-65 (kullanıcının relay listesi). Kullanıcıların tercih edilen relay'lerini yayınlamasına izin verir, böylece istemciler otomatik olarak doğru yerlere yönlendirebilir. Benimseme iyileşiyor; eski istemciler bunu görmezden gelir.

NIP-50 (arama). İstemcilerin metin eşleşmeleri için relay'leri sorgulamasına izin verir. Bazı relay'ler bunu destekler; çoğu yapmaz. Sonuç olarak arama kalitesi tutarsızdır.

Belirli bir istemcinin hangi NIP'leri desteklediğini kontrol etmek, bir şey beklendiği gibi çalışmadığında faydalı bir tanı yöntemidir. Çoğu istemci, belgelerinde NIP destek matrisini yayınlar.

NIP süreci protokolün nasıl tutarlı kalındığını korur

Merkezi bir otorite yok, bu yüzden tutarlılık sosyal dinamikten gelir. Birkaç gözlem:

Kötü NIP'ler yayılmaz. Mevcut bir NIP'i çoğaltan veya yanlış sorunu çözen bir teklif minimal benimseme alır ve sessizce ölür. Topluluk resmi değil ancak fikirli.

İyi NIP'ler bağımsız olarak uygulanır. Birden fazla istemci geliştiricisi teklifleri okur ve bağımsız olarak karar verir. İyi fikirler uygulayıcıları biriktirir; kötü fikirler yapmaz.

Rekabet eden NIP'ler bazen ortaya çıkar. Aynı özellik için iki farklı teklif bir süre birlikte var olabilir. Genellikle pratikle biri kazanır çünkü daha fazla istemci bunu uygular; bazen birleşirler.

Çatal uyumlu evrim. NIP'ler isteğe bağlı olduğundan, bir istemci NIP-X-v1'i uygulay ve daha sonra yalnızca v1'i destekleyenleri bozmadan NIP-X-v2'ye yükseltebilir. Protokol bölünmez.

Bu karışık ama işlevseldir. Protokol, "uygulayıcılar okur, uygulayıcılar karar verir, uygulayıcılar kodlar" sosyal mekanizması yeterli hizalama ürettiğinden, merkezi bir yönetişim organı olmadan beş yılda önemli ölçüde evrimleşti.

Kendi NIP'inizi önerme

Nostr için yeni bir özellik hakkında bir fikriniz varsa:

1. Önce NIP'ler deposunu kontrol edin. Birileri bunu zaten önermiş olabilir.
2. Değilse, çözdüğünüz sorunu açıklayan bir GitHub sorunu açın.
3. Feedback'e göre, mevcut formatı izleyerek tam bir NIP taslağı yapın.
4. Bir çekme isteği gönderin.
5. Tartışmaya katılın. Revize olmaya istekli olun.
6. Birleştirilirse, harika. Birleştirilmezse, sorunun daha iyi bir çözümü olabilir; neden olduğunu düşünün.

Her iyi fikir bir NIP olmaz. Her NIP bir özellik olmaz. Ekosistem, herhangi bir geliştirici'nin takip edebileceğinden daha fazla teklife sahiptir ve filtre "topluluk yeterince bunu uygular mı" olur. Bu filtre, Nostr'un yukarıdan aşağıya olmadan tutarlı kalmasının temelini oluşturur.