Nostr

Anna menemukan penulis yang ingin diikutinya di Nostr. Kemudian, aplikasinya tidak lagi cocok. Jika ia menggunakan kunci privat yang sama atau perangkat penandatangan terhubung secara aman di aplikasi lain, identitasnya dapat tetap sama. Kunci publik memungkinkan orang mengenalinya dan memeriksa tanda tangan; kunci privat memungkinkan seseorang menandatangani sebagai Anna. Karena itu, npub dan nsec sangat berbeda. Menurut NIP-19, keduanya adalah bentuk kunci publik dan privat dalam pengodean Bech32. NIP adalah dokumen bernomor yang menjelaskan aturan dan perluasan Nostr. Pengodean bukan enkripsi: nsec bukan tautan profil biasa yang aman dibagikan kepada siapa saja. Identitas yang tetap sama juga tidak menjamin aplikasi baru menemukan seluruh kiriman lama atau memindahkan semua pengaturan. [2] [7]

Aplikasi, yang disebut klien, menandatangani kiriman dan mengirimkannya ke relay pilihan. Relay adalah server yang menerima pesan lalu menyimpan atau meneruskannya sesuai aturannya sendiri. Aplikasi Petr terhubung ke relay dan meminta kiriman yang diminatinya. Tidak ada satu server pusat maupun kewajiban setiap server menyalin semuanya. Secara teknis, klien dan relay memakai WebSocket, koneksi yang tetap terbuka: EVENT membawa pesan, REQ membuka langganan, dan OK melaporkan penerimaan atau penolakan. Bahkan OK positif tidak memastikan kiriman sampai kepada Petr atau disimpan selamanya. EOSE menandai akhir hasil tersimpan untuk permintaan itu; langganan kemudian masih dapat menerima pesan baru. [1] [7]

Saat Petr menerima pesan, aplikasinya memeriksa apakah tanda tangan cocok dengan kunci publik yang tercantum dan apakah data bertanda tangan tetap utuh. Ini tidak membuktikan kebenaran pesan ataupun identitas asli penulisnya. Penulis juga menentukan waktu pembuatan, sehingga itu bukan cap waktu independen. Untuk pembaca yang ingin memahami teknisnya: catatan bernama event memuat pubkey, created_at, kind, tags, dan content, yakni kunci, waktu, jenis, penanda, serta isi. SHA-256 mengubah susunan data dengan format yang ditentukan secara persis menjadi nilai pemeriksaan singkat bernama id. Nilai ini memungkinkan perubahan pada data bertanda tangan terdeteksi. Kolom sig berisi Schnorr Signature menurut BIP340 pada kurva secp256k1. Artinya adalah “pemegang kunci terkait menandatangani data ini”, bukan “pernyataan ini layak dipercaya”. [1]

Kunci publik yang panjang sulit diingat. NIP-05 memungkinkan pengaitannya dengan pengenal yang menyerupai alamat email. Aplikasi menanyakan kepada domain terkait kunci mana yang sesuai dengan nama tersebut, lalu membandingkannya dengan kunci profil. Yang diperiksa adalah kaitan dengan domain itu, bukan otomatis nama asli, reputasi, atau keandalan seseorang. Operator domain dapat mengubah kaitan tersebut. Setelah Anna mengikuti seseorang, kunci publik asli harus tetap menjadi acuan; pemberian nama yang sama kepada kunci lain tidak boleh diam-diam mengganti siapa yang ia ikuti. Pseudonimitas berarti memakai pengenal tetap sebagai pengganti nama asli, bukan jaminan anonimitas. [3]

Petr tidak perlu mengunduh seluruh pesan. Ia mengirim filter, misalnya untuk penulis tertentu dan jenis kiriman tertentu. Syarat berbeda dalam satu filter digabung dengan AND: semuanya harus terpenuhi. Beberapa nilai yang diperbolehkan untuk satu syarat merupakan pilihan OR; begitu pula beberapa filter dalam satu REQ. Memenuhi salah satu filter sudah cukup. limit membatasi kumpulan awal hasil tersimpan, bukan otomatis pesan berikutnya dalam langganan. NIP-01 menggunakan bentuk heksadesimal kunci dalam event dan filter, bukan format npub untuk pengguna. Hasil pencarian kosong bisa disebabkan filter, server pilihan, atau riwayatnya; bukan bukti kiriman itu tidak ada di mana pun. [1]

Anna mengubah deskripsi profil dan ingin orang lain melihat versi baru. Karena itu Nostr membedakan apa yang seharusnya disimpan relay. Untuk event yang dapat digantikan, relay memilih catatan terbaru bagi pasangan pubkey dan kind yang sama. Event yang dapat dialamatkan juga memakai nilai penanda d, misalnya untuk membedakan dokumen dari penulis yang sama. Jika waktu catatan yang dapat digantikan sama, dianjurkan mempertahankan id yang lebih kecil secara leksikografis, yaitu yang lebih dahulu menurut urutan penulisannya. Event sementara, atau ephemeral, bahkan tidak diharapkan disimpan. Ini adalah konvensi dan perilaku relay dapat berbeda. Jadi, Nostr bukan buku besar dengan satu riwayat tetap yang disepakati seluruh jaringan. [1]

Anna menyadari ia mengirim sesuatu yang seharusnya tetap pribadi. NIP-09 memungkinkan permintaan penghapusan bertanda tangan. Sebelum mematuhinya, klien harus memeriksa bahwa permintaan dan kiriman asli berasal dari kunci publik yang sama; orang lain tidak boleh menghapus kiriman Anna hanya dengan merujuknya. Server dan aplikasi yang bekerja sama dapat membuang konten atau berhenti menampilkannya. Namun, permintaan itu tidak menghapus semua salinan, tangkapan layar, atau arsip independen. Menyembunyikan kiriman di satu aplikasi juga tidak menjelaskan apakah server lain masih menyediakannya. Karena itu, apa yang diterbitkan lebih penting daripada sekadar tersedianya tombol Hapus. [4]

Siapa pun yang memperoleh kiriman publik dapat membacanya; tanda tangan tidak menyembunyikan isinya. Pesan pribadi memakai aturan tambahan. NIP-44 menjelaskan enkripsi isi, sedangkan NIP-17 membahas pembungkusan dan pengiriman dengan lapisan perlindungan tambahan. Ini bukan anonimitas otomatis: alamat jaringan, waktu, dan perilaku aplikasi masih dapat mengungkap informasi. Enkripsi ini juga tidak menyediakan forward secrecy, perlindungan percakapan lama jika kunci jangka panjang bocor kemudian. Orang yang memperoleh kunci privat yang diperlukan dan pesan terenkripsi yang sebelumnya direkam dapat membaca komunikasi lama. Periksa ekstensi yang benar-benar didukung aplikasi; nama “Nostr” saja tidak menjelaskan tingkat privasinya. [5] [6]