Il NIP-A3 riscritto un giorno dopo il merge

Titolo e stato

L'intestazione abbandona il riferimento alla RFC. "payto: Payment Targets (RFC-8905)" diventa "payto: Payment Targets", e la voce del README.md viene aggiornata di conseguenza.

Cambiano anche i marcatori di stato. La versione integrata portava optional e una riga author:atxmj. Il file attuale porta draft e optional, senza riga di attribuzione.

La sezione "Event Kind" è sparita. Diceva che il NIP-A3 definisce kind:10133 e che quel kind è sostituibile. Il numero di kind compare ancora nell'evento di esempio e nel paragrafo sulla resa, e 10133 ricade nell'intervallo 10000 <= n < 20000 che il NIP-01 già definisce sostituibile, quindi il comportamento dei relay non cambia. Semplicemente, la specifica non lo dice più da sé.

Il tag

La struttura del tag ora è fissa, di tre elementi:

["payto", "<type>", "<address>"]

La versione integrata ne consentiva di più:

["payto", "<type>", "<authority>", "<optional_extra_1>", "<optional_extra_2>", ...]

Cambiano due cose. Il terzo elemento passa da authority ad address. E vengono rimossi gli elementi finali, descritti come riservati a future funzionalità della RFC-8905, insieme alla regola di compatibilità in avanti secondo cui i client devono comprendere gli elementi da 0 a 2 e possono ignorare tutto ciò che segue.

Validazione

La sezione Validation viene eliminata. Richiedeva che type fosse composto da lettere minuscole, cifre e trattini, e che authority fosse sicuro per gli URL, con i caratteri speciali codificati.

Ciò che resta si sposta nella descrizione del tag: type è "sempre minuscolo", e i client possono applicare validazioni aggiuntive specifiche della rete o della piattaforma ai tipi che riconoscono. La regola sull'insieme dei caratteri e quella sulla codifica non compaiono più in alcun punto del file.

Resa

È questo il cambiamento sostanziale. Il testo integrato diceva ai client di comporre payto://<type>/<authority> per ogni tag e di mostrarlo come pulsante o collegamento. La RFC-8905 era il formato di uscita.

Il testo attuale la rende il ripiego. I client possono usare un URI di schema specifico quando ne esiste uno, come bitcoin:<address> o ethereum:<address>, e ricorrere altrimenti a payto://<type>/<address>. L'elenco di esempio nel file mostra la combinazione: il tag bitcoin viene reso come bitcoin:bc1qxq66e0t8d7ugdecwnmv58e90tpry23nc84pg9k, mentre il tag nano e un tag di tipo unknowntype diventano URI payto://.

Due istruzioni sulla resa spariscono senza sostituto: quella di dare ai tipi riconosciuti un'icona e uno stile, e la nota per cui un client con più destinazioni può mostrare la prima, mostrarle tutte oppure offrire un menu a tendina.

L'elenco dei tipi

La tabella dei tipi consigliati lascia il posto a un elenco semplice intitolato "Commonly Used Tags". La tabella aveva otto voci, ciascuna con nome esteso, nome breve, simbolo e collegamento al materiale di marchio del sistema di pagamento stesso. L'elenco ha quattordici voci e nessuna colonna:

bip352 per i pagamenti silenziosi, bip353 per gli indirizzi DNS, bitcoin, cashme, ethereum, lightning, litecoin, monero, nano, paypal, revolut, solana, venmo e zcash.

Sei sono nuovi: bip352, bip353, litecoin, paypal, solana e zcash. Nessuno degli otto originari è stato tolto. Il file chiude l'elenco dicendo che nuovi formati di ampia diffusione potranno essere aggiunti in seguito.

Zap

La sezione "Implementation Notes" sparisce per intero, compresa la sottosezione sugli zap del NIP-57. Quel testo diceva che i client possono usare un tag payto di tipo lightning come alternativa al campo di profilo lud16 o come suo complemento, con un esempio che mostrava un evento kind 0 e uno kind 10133 affiancati.

Il file attuale non menziona lud16, il NIP-57 o gli zap in alcun punto.

Per chi implementa

Nulla di già pubblicato perde validità. Il numero di kind, il nome del tag e le posizioni del tipo e dell'indirizzo restano invariati, quindi un evento kind 10133 esistente viene interpretato allo stesso modo con entrambe le versioni.

Il codice scritto sul testo integrato potrebbe ora fare più di quanto la specifica chieda. I parser che leggono elementi oltre il terzo non hanno più nulla da leggere. I validatori che applicano le regole sull'insieme dei caratteri e sulla codifica degli URL applicano regole che il file non riporta più. Chi emette sempre payto:// resta corretto, perché quello rimane il ripiego, ma per i tipi dotati di uno schema URI proprio non segue più la strada che il file ora preferisce.