Lightning Address

LUD-16 menggunakan username dan domain, tetapi membatasi nama pada huruf kecil a-z, angka 0-9, dan -_.; tanda tambah hanya boleh jika layanan mendukung tag. Sintaks email biasa lebih luas. Karena itu, kotak surat tidak menjamin Lightning Address, dan nama yang sama tidak mengautentikasi orang penerima. [Lightning Address — LUD-16] [Lightning Address — Project overview]

Dompet mengambil jalur /.well-known/lnurlp/username pada domain melalui GET, dengan HTTPS atau HTTP untuk layanan onion. Responsnya berupa payRequest menurut LUD-06. Domain yang sebenarnya dan layanannya yang menentukan; bagian sebelum tanda at bukan kunci publik node. [Lightning Address — LUD-16]

Respons memberikan callback, metadata, dan batas minSendable/maxSendable. Pembayar memilih amount dalam msat; 1000 msat adalah satu satoshi. Callback mengembalikan invoice dalam pr dan dompet memeriksa kesesuaian jumlah sebelum membayar. Pencarian alamat maupun penerimaan invoice belum berarti penyelesaian pembayaran. [LNURL — LUD-06 payRequest] [Lightning Address — Implementation guide]

LUD-16 yang lebih baru mengizinkan bentuk opsional @domain sebagai singkatan _@domain dengan jalur berakhiran /_. Layanan maupun dompet tidak wajib mendukungnya. +tag yang didukung dikirim di jalur; layanan dapat memakainya sebagai metadata text/tag. Tag bukan kunci Bitcoin baru atau perlindungan privasi otomatis. [Lightning Address — LUD-16]

LUD-16 mewajibkan text/identifier atau text/email dalam metadata; text/email diperuntukkan bagi alamat email yang nyata. text/plain dari LNURL-pay juga tetap wajib. Bandingkan nama dan deskripsi yang ditampilkan dengan domain serta penerima yang dituju. Pernyataan layanan bukan verifikasi independen atas identitas seseorang. [Lightning Address — LUD-16] [LNURL — LUD-06 payRequest]

Layanan bisa menerbitkan invoice dari dompetnya atau memakai server penghubung yang tersambung ke node. Jadi, format itu sendiri tidak berarti kustodi maupun kendali mandiri. Penghubung memerlukan izin sesuai fungsinya, bukan otomatis kendali dompet tanpa batas. Pengendali endpoint dapat memengaruhi invoice yang diterima pembayar. [Lightning Address — Implementation guide] [Lightning Address — Bridge server]

Dompet bisa membayar Lightning Address tanpa menyediakan alamat sendiri bagi pengguna. Penerimaan membutuhkan layanan web yang berfungsi, penerbitan invoice, dan kemampuan menerima pembayaran. Nama yang mudah dibaca tidak menciptakan likuiditas masuk dengan sendirinya. Pencarian berulang dapat mengungkap penerima dan waktu kepada penyedia. [Lightning Address — Implementation guide]

Domain sendiri memungkinkan pengalihan endpoint ke server lain; BTCPay mendokumentasikan HTTP 301, misalnya. Pada domain pihak lain, mempertahankan nama bergantung pada penyedia. Seed tidak memulihkan kendali DNS, sertifikat, atau pemetaan akun. Setelah berganti layanan, periksa lagi pencarian, invoice tujuan, dan penerimaan; jangan menganggap kontak lama diperbarui otomatis. [BTCPay Server — Address redirection] [Lightning Address — Implementation guide]