Nostr

Peristiwa memuat pubkey, created_at, kind, tags, content, id, dan sig. NIP-01 menghasilkan id dengan SHA-256 dari serialisasi yang ditentukan tepat dan memakai BIP340 pada secp256k1. Klien memverifikasi integritas serta otorisasi kunci. Penulis mengisi created_at; itu bukan stempel waktu independen atau bukti kebenaran isi. [Nostr — NIP-01: Basic protocol] [fiatjaf — Original Nostr description]

Klien menerbitkan EVENT dan berlangganan dengan REQ melalui WebSocket. OK menyatakan penerimaan atau penolakan relay tersebut. EOSE mengakhiri daftar peristiwa tersimpan, bukan selalu langganan peristiwa baru. Tidak satu pun mengonfirmasi penerimaan oleh tujuan, replikasi seluruh jaringan, atau penyimpanan permanen. [Nostr — NIP-01: Basic protocol]

Dalam satu filter, peristiwa harus memenuhi semua kondisi: penulis dan jenis berarti AND. Beberapa filter dalam satu REQ digabung dengan OR; satu saja cukup. limit membatasi daftar awal, bukan jumlah peristiwa mendatang. Hasil yang tidak ada bisa mencerminkan riwayat relay terbatas, bukan ketiadaan peristiwa. [Nostr — NIP-01: Basic protocol]

Peristiwa yang dapat diganti dibandingkan menurut pubkey dan kind; peristiwa beralamat juga memakai tag d. Versi baru dapat menggantikan versi lama; waktu yang sama diselesaikan dengan id lebih kecil secara leksikografis. Peristiwa sementara tidak diharapkan disimpan. Ini aturan relay, bukan arsip global yang tak berubah; implementasi dapat berbeda. [Nostr — NIP-01: Basic protocol]

NIP-19 memakai Bech32 untuk tampilan pengguna: npub menandai kunci publik, nsec kunci privat. Pengodean bukan enkripsi. Membagikan nsec berarti menyerahkan kunci rahasia, bukan sekadar tautan profil. Peristiwa dan filter NIP-01 memakai kunci publik heksadesimal, bukan bentuk tampilan npub. [Nostr — NIP-19: Encoded entities]

NIP-05 menghubungkan nama mirip alamat surel dengan kunci publik menurut respons domain. Itu membuktikan hubungan, bukan identitas nyata atau kejujuran. Klien seharusnya mengikuti kunci asli: bila domain memetakan nama ke kunci lain, klien tidak boleh otomatis menggantikan profil yang telah diikuti dengan kunci baru. [Nostr — NIP-05: Internet identifiers]

NIP-09 mendefinisikan permintaan penulis untuk menghapus peristiwanya. Sebelum menyembunyikan, klien harus memeriksa kesamaan kunci publik peristiwa asli dan permintaan. Relay dan klien dapat memprosesnya, tetapi protokol tidak dapat menghapus semua salinan yang telah diunduh atau disimpan. Penghapusan di satu antarmuka bukan bukti penghapusan global. [Nostr — NIP-09: Deletion requests]

NIP-44 mendefinisikan payload terenkripsi, bukan seluruh sistem pesan privat; NIP-17 menambahkan pembungkus dan aturan pengiriman. NIP-44 sendiri tidak menyediakan forward secrecy saat kunci kemudian bocor. Alamat jaringan, waktu, dan perilaku klien tetap relevan meski isi dienkripsi. Dukungan setiap NIP harus dibedakan per aplikasi. [Nostr — NIP-44: Encrypted payloads] [Nostr — NIP-17: Private messages]