NewbieToNode
Creatore verificato
Planting tokens 🌱 Waiting for sun 🌞 Watering with hope 💧 Soft degen vibes only
Commerciante frequente
4 anni
142 Seguiti
32.4K+ Follower
24.9K+ Mi piace
2.2K+ Condivisioni
Post
Tutti
Citazioni
Video
Live
Visualizza traduzione
@SignOfficial
I expected this revoke to go through.
It didn’t.
No error.
Just... no change.
Same credential.
Still valid.
Exactly as if nothing had been called.
For a second I thought I hit the wrong record.
Ran it again.
Nothing moved.
So I checked the attester.
Matched.
Then I checked the schema.
Different address.
That didn’t sit right.
I tried from the attester side again.
Still nothing.
Didn’t even look like it tried.
Switched it.
Called from the schema side.
This time it went through.
That’s where it flipped.
The attester could issue it.
But couldn’t undo it.
The registrant could.
I ran another one.
Different credential.
Same behavior.
Issued in one place.
Controlled in another.
I stayed on it longer than I planned.
Because nothing was failing.
Everything was just... ignoring the wrong caller.
I keep coming back to this as split authority.
The entity creating the credential...
isn’t the one that can turn it off.
From the outside, it looks like issuer control.
Inside, control sits somewhere else entirely.
Two authorities.
Only one visible when the credential is created.
$SIGN only matters if the same entity that issues a credential is also the one that can revoke it under real usage...
not just the one that defined the schema it lives under.
Because once those split...
revocation stops being an action.
And becomes a dependency.
So the real question becomes this.
When something needs to be turned off fast...
who are you actually waiting on?
#SignDigitalSovereignInfra #Sign
I expected this revoke to go through.
It didn’t.
No error.
Just... no change.
Same credential.
Still valid.
Exactly as if nothing had been called.
For a second I thought I hit the wrong record.
Ran it again.
Nothing moved.
So I checked the attester.
Matched.
Then I checked the schema.
Different address.
That didn’t sit right.
I tried from the attester side again.
Still nothing.
Didn’t even look like it tried.
Switched it.
Called from the schema side.
This time it went through.
That’s where it flipped.
The attester could issue it.
But couldn’t undo it.
The registrant could.
I ran another one.
Different credential.
Same behavior.
Issued in one place.
Controlled in another.
I stayed on it longer than I planned.
Because nothing was failing.
Everything was just... ignoring the wrong caller.
I keep coming back to this as split authority.
The entity creating the credential...
isn’t the one that can turn it off.
From the outside, it looks like issuer control.
Inside, control sits somewhere else entirely.
Two authorities.
Only one visible when the credential is created.
$SIGN only matters if the same entity that issues a credential is also the one that can revoke it under real usage...
not just the one that defined the schema it lives under.
Because once those split...
revocation stops being an action.
And becomes a dependency.
So the real question becomes this.
When something needs to be turned off fast...
who are you actually waiting on?
#SignDigitalSovereignInfra #Sign
@SignOfficial
Ho controllato un'attestazione prima che risultasse più breve di quanto era stato inviato.
L'attestatore aveva spinto il valore più in là.
La credenziale non lo ha fatto.
Pensavo di aver estratto quella sbagliata.
L'ho eseguita di nuovo.
Stessa attestazione.
Stesso schemaId.
Ancora più breve.
Questo non mi sembrava giusto.
Così ci ho lavorato sopra.
Quello che è stato inserito...
e quello che è apparso...
non erano gli stessi.
Niente è fallito.
Nessun rifiuto.
Nessun avviso.
È stato risolto pulito.
È stato allora che ho guardato di nuovo lo schema.
"maxValidFor" era inferiore a quanto era stato inviato.
Non stava rifiutando l'input.
Lo stava accorciando.
Ho provato di nuovo.
Attestatore diverso.
Stesso schema.
Stesso risultato.
È stato allora che è scattato.
L'attestatore non sta definendo la credenziale.
Stanno negoziando con lo schema.
E lo schema decide cosa sopravvive realmente.
Dall'esterno, sembra che l'attestatore abbia impostato il valore.
All'interno, parte di esso non passa mai.
Nessun segnale.
Nessuna traccia.
Solo uno stato finale pulito.
Due diverse sottomissioni.
Stessa credenziale.
Continuo a tornare su questo come un'illusione di override dell'attestatore.
Sembra che il controllo sia con l'emittente.
Ma la forma finale è già delimitata altrove.
$SIGN conta solo se i vincoli dello schema come "maxValidFor" non rimodellano silenziosamente ciò che viene inviato...
ma espongono chiaramente quel confine.
Perché una volta che gli input vengono alterati senza visibilità...
la fonte della verità si sposta.
E non lo vedi accadere.
Quindi la vera domanda diventa questa.
Se parte dell'input non sopravvive mai allo schema...
cosa stai verificando esattamente?
#SignDigitalSovereignInfra #Sign
Ho controllato un'attestazione prima che risultasse più breve di quanto era stato inviato.
L'attestatore aveva spinto il valore più in là.
La credenziale non lo ha fatto.
Pensavo di aver estratto quella sbagliata.
L'ho eseguita di nuovo.
Stessa attestazione.
Stesso schemaId.
Ancora più breve.
Questo non mi sembrava giusto.
Così ci ho lavorato sopra.
Quello che è stato inserito...
e quello che è apparso...
non erano gli stessi.
Niente è fallito.
Nessun rifiuto.
Nessun avviso.
È stato risolto pulito.
È stato allora che ho guardato di nuovo lo schema.
"maxValidFor" era inferiore a quanto era stato inviato.
Non stava rifiutando l'input.
Lo stava accorciando.
Ho provato di nuovo.
Attestatore diverso.
Stesso schema.
Stesso risultato.
È stato allora che è scattato.
L'attestatore non sta definendo la credenziale.
Stanno negoziando con lo schema.
E lo schema decide cosa sopravvive realmente.
Dall'esterno, sembra che l'attestatore abbia impostato il valore.
All'interno, parte di esso non passa mai.
Nessun segnale.
Nessuna traccia.
Solo uno stato finale pulito.
Due diverse sottomissioni.
Stessa credenziale.
Continuo a tornare su questo come un'illusione di override dell'attestatore.
Sembra che il controllo sia con l'emittente.
Ma la forma finale è già delimitata altrove.
$SIGN conta solo se i vincoli dello schema come "maxValidFor" non rimodellano silenziosamente ciò che viene inviato...
ma espongono chiaramente quel confine.
Perché una volta che gli input vengono alterati senza visibilità...
la fonte della verità si sposta.
E non lo vedi accadere.
Quindi la vera domanda diventa questa.
Se parte dell'input non sopravvive mai allo schema...
cosa stai verificando esattamente?
#SignDigitalSovereignInfra #Sign
La Credenziale Che È Cambiata Senza Cambiare
@SignOfficial
Stavo controllando di nuovo una credenziale questa mattina.
Lo stesso che avevo verificato qualche giorno fa.
Non mi aspettavo nulla di diverso.
Era passato senza intoppi prima.
L'ho tirato di nuovo.
Stesso attestatore.
Stessi dati.
Stessa referenza.
Ma non si è risolto nello stesso modo.
Non rotto.
Solo... diverso.
Quella parte non mi sembrava giusta.
Quindi ho messo il risultato precedente affianco.
Li ho confrontati riga per riga.
È allora che è comparso.
Le credenziali non erano cambiate.
Ma c'era qualcosa dietro di essa.
Sono tornato allo schema.
L'ho tirato direttamente dal registro.
Stavo controllando di nuovo una credenziale questa mattina.
Lo stesso che avevo verificato qualche giorno fa.
Non mi aspettavo nulla di diverso.
Era passato senza intoppi prima.
L'ho tirato di nuovo.
Stesso attestatore.
Stessi dati.
Stessa referenza.
Ma non si è risolto nello stesso modo.
Non rotto.
Solo... diverso.
Quella parte non mi sembrava giusta.
Quindi ho messo il risultato precedente affianco.
Li ho confrontati riga per riga.
È allora che è comparso.
Le credenziali non erano cambiate.
Ma c'era qualcosa dietro di essa.
Sono tornato allo schema.
L'ho tirato direttamente dal registro.
La Credenziale Che È Scaduta Senza Cambiare
@SignOfficial
Stavo controllando una credenziale SIGN prima su due reti.
Non mi aspettavo nulla di insolito.
È passato sulla prima.
Pulito.
Poi ho verificato le stesse credenziali su un'altra rete.
È fallito.
A quel punto pensavo di aver perso qualcosa di ovvio.
L'ho tirato di nuovo.
Stesso risultato.
Non aveva senso.
Niente era cambiato.
Nessuna revoca.
Nessun aggiornamento.
Stessa credenziale.
Quindi ho rallentato.
Controllato dove è stata emessa.
Allora dove è stata verificata.
`validUntil` era ancora nella fascia.
Ma solo sulla rete da cui proviene.
Stavo controllando una credenziale SIGN prima su due reti.
Non mi aspettavo nulla di insolito.
È passato sulla prima.
Pulito.
Poi ho verificato le stesse credenziali su un'altra rete.
È fallito.
A quel punto pensavo di aver perso qualcosa di ovvio.
L'ho tirato di nuovo.
Stesso risultato.
Non aveva senso.
Niente era cambiato.
Nessuna revoca.
Nessun aggiornamento.
Stessa credenziale.
Quindi ho rallentato.
Controllato dove è stata emessa.
Allora dove è stata verificata.
`validUntil` era ancora nella fascia.
Ma solo sulla rete da cui proviene.
@SignOfficial
Stavo seguendo un "linkedAttestationId" prima.
Mi aspettavo che si risolvesse.
Non si è risolto.
Pensavo di aver estratto quello sbagliato.
L'ho eseguito di nuovo.
Stesso ID.
Ancora vuoto.
Non aveva senso.
Sembrava che mi mancasse qualcosa di ovvio.
Quindi ho controllato direttamente il registro.
Niente nemmeno lì.
Ho aspettato.
Ho provato di nuovo.
Nessuna modifica.
Ma la credenziale...
era a posto.
È stata verificata senza problemi.
Nessun errore.
Nessun avviso.
È stato allora che è cambiato.
Il riferimento mancava.
La credenziale no.
Quindi ho provato un'altra.
Attestazione diversa.
Stesso schema.
"linkedAttestationId" impostato.
Niente dietro di esso.
Nessun ripristino.
Nessun fallimento.
Nessun segnale che ci fosse qualcosa di sbagliato.
È stato allora che ho smesso di cercare il record.
E ho iniziato a osservare cosa viene effettivamente controllato.
Il link non entra mai in gioco.
La verifica non lo segue.
Non aspetta per esso.
Non importa se si risolve.
La credenziale sta in piedi da sola.
A cosa punta...
non viene mai estratto.
È stato allora che è scattato.
Non stava rompendo.
Veniva ignorato.
Fantasma in avanti.
Un riferimento che esiste...
senza mai aver bisogno di risolversi.
Dall'esterno...
tutto sembra completo.
La credenziale verifica.
La struttura regge.
Ma la connessione...
non è forzata.
È qui che diventa rischioso.
Un sistema vede il link...
e assume continuità.
Ma niente lo garantisce.
Niente lo prova.
Niente lo lega.
Due credenziali possono sembrare collegate.
Niente in realtà le lega insieme.
E poiché la verifica non controlla mai...
non c'è segnale che ci sia qualcosa di mancante.
$SIGN ha importanza solo se i riferimenti come "linkedAttestationId" devono essere risolti...
non solo esistere.
Perché una volta che i link non hanno bisogno di mantenere...
la struttura smette di significare connessione.
Quindi la vera domanda diventa questa.
Se una credenziale può puntare in avanti...
senza nulla lì...
cosa tratta esattamente il sistema come collegato?
#SignDigitalSovereignInfra #Sign
Stavo seguendo un "linkedAttestationId" prima.
Mi aspettavo che si risolvesse.
Non si è risolto.
Pensavo di aver estratto quello sbagliato.
L'ho eseguito di nuovo.
Stesso ID.
Ancora vuoto.
Non aveva senso.
Sembrava che mi mancasse qualcosa di ovvio.
Quindi ho controllato direttamente il registro.
Niente nemmeno lì.
Ho aspettato.
Ho provato di nuovo.
Nessuna modifica.
Ma la credenziale...
era a posto.
È stata verificata senza problemi.
Nessun errore.
Nessun avviso.
È stato allora che è cambiato.
Il riferimento mancava.
La credenziale no.
Quindi ho provato un'altra.
Attestazione diversa.
Stesso schema.
"linkedAttestationId" impostato.
Niente dietro di esso.
Nessun ripristino.
Nessun fallimento.
Nessun segnale che ci fosse qualcosa di sbagliato.
È stato allora che ho smesso di cercare il record.
E ho iniziato a osservare cosa viene effettivamente controllato.
Il link non entra mai in gioco.
La verifica non lo segue.
Non aspetta per esso.
Non importa se si risolve.
La credenziale sta in piedi da sola.
A cosa punta...
non viene mai estratto.
È stato allora che è scattato.
Non stava rompendo.
Veniva ignorato.
Fantasma in avanti.
Un riferimento che esiste...
senza mai aver bisogno di risolversi.
Dall'esterno...
tutto sembra completo.
La credenziale verifica.
La struttura regge.
Ma la connessione...
non è forzata.
È qui che diventa rischioso.
Un sistema vede il link...
e assume continuità.
Ma niente lo garantisce.
Niente lo prova.
Niente lo lega.
Due credenziali possono sembrare collegate.
Niente in realtà le lega insieme.
E poiché la verifica non controlla mai...
non c'è segnale che ci sia qualcosa di mancante.
$SIGN ha importanza solo se i riferimenti come "linkedAttestationId" devono essere risolti...
non solo esistere.
Perché una volta che i link non hanno bisogno di mantenere...
la struttura smette di significare connessione.
Quindi la vera domanda diventa questa.
Se una credenziale può puntare in avanti...
senza nulla lì...
cosa tratta esattamente il sistema come collegato?
#SignDigitalSovereignInfra #Sign
@SignOfficial
Stavo controllando un documento di identità prima.
Presumevo che l'attestatore fosse la fonte di verità.
Poi ho guardato lo schema.
Indirizzo diverso.
`registrant` nello schema.
`attester` nel documento di identità.
Non sono la stessa cosa.
Questo non aveva senso.
Quindi ne ho preso un altro.
Poi un altro.
Schemi diversi.
Attestatori diversi.
Stessa divisione.
A quel punto pensavo mi stesse sfuggendo qualcosa.
Qualche collegamento tra di loro.
Qualcosa che collega l'emittente alle regole.
Non riuscivo a trovarlo.
Il documento di identità proveniva dall'attestatore.
Ma le regole no.
L'ho tracciato più indietro.
Lo schema è lì per primo.
Registrato una volta.
Poi riutilizzato.
Ripetutamente.
Chiunque emetta sotto di esso...
non lo sta definendo.
È lì che è cambiato.
L'attestatore controlla l'emissione.
Il registrante controlla cosa significa anche l'emissione.
Due autorità diverse.
Nessun confine visibile tra di loro.
Leggi il documento di identità e ti fidi dell'attestatore...
ma non hanno deciso le regole dietro di esso.
E nulla nel flusso te lo dice.
Sembra solo valido.
È lì che inizia a diventare scomodo.
Se lo schema cambia...
l'attestatore non può fermarlo.
Se il registrante scompare...
le regole non vanno con loro.
Quindi ciò in cui ti fidi...
e ciò che definisce realmente il documento di identità...
non sono la stessa cosa.
Continuo a tornare a questo come divisione di autorità.
Non condiviso.
Non stratificato.
Diviso.
$SIGN ha importanza solo se un sistema in cui `registrant` e `attester` sono separati può mantenere stabili le regole del documento di identità...
even quando l'emittente non le controlla.
Perché una volta che quel divario conta...
non c'è più una singola fonte di verità.
Quindi la vera domanda diventa questa.
Quando l'emittente e chi fa le regole non sono la stessa cosa...
a cosa ti fidi esattamente quando verifichi?
#SignDigitalSovereignInfra #Sign
Stavo controllando un documento di identità prima.
Presumevo che l'attestatore fosse la fonte di verità.
Poi ho guardato lo schema.
Indirizzo diverso.
`registrant` nello schema.
`attester` nel documento di identità.
Non sono la stessa cosa.
Questo non aveva senso.
Quindi ne ho preso un altro.
Poi un altro.
Schemi diversi.
Attestatori diversi.
Stessa divisione.
A quel punto pensavo mi stesse sfuggendo qualcosa.
Qualche collegamento tra di loro.
Qualcosa che collega l'emittente alle regole.
Non riuscivo a trovarlo.
Il documento di identità proveniva dall'attestatore.
Ma le regole no.
L'ho tracciato più indietro.
Lo schema è lì per primo.
Registrato una volta.
Poi riutilizzato.
Ripetutamente.
Chiunque emetta sotto di esso...
non lo sta definendo.
È lì che è cambiato.
L'attestatore controlla l'emissione.
Il registrante controlla cosa significa anche l'emissione.
Due autorità diverse.
Nessun confine visibile tra di loro.
Leggi il documento di identità e ti fidi dell'attestatore...
ma non hanno deciso le regole dietro di esso.
E nulla nel flusso te lo dice.
Sembra solo valido.
È lì che inizia a diventare scomodo.
Se lo schema cambia...
l'attestatore non può fermarlo.
Se il registrante scompare...
le regole non vanno con loro.
Quindi ciò in cui ti fidi...
e ciò che definisce realmente il documento di identità...
non sono la stessa cosa.
Continuo a tornare a questo come divisione di autorità.
Non condiviso.
Non stratificato.
Diviso.
$SIGN ha importanza solo se un sistema in cui `registrant` e `attester` sono separati può mantenere stabili le regole del documento di identità...
even quando l'emittente non le controlla.
Perché una volta che quel divario conta...
non c'è più una singola fonte di verità.
Quindi la vera domanda diventa questa.
Quando l'emittente e chi fa le regole non sono la stessa cosa...
a cosa ti fidi esattamente quando verifichi?
#SignDigitalSovereignInfra #Sign
La Credenziale Che Non È Mai Stata Accettata
@SignOfficial
Stavo controllando un indirizzo destinatario su un'attestazione questa mattina.
Zero transazioni.
Zero storia.
La credenziale era valida.
L'indirizzo non aveva mai fatto nulla.
Ne ho preso un altro.
Schema diverso.
Emittente diverso.
Stesso risultato.
Il campo `recipients` è stato popolato. Codificato in ABI. La struttura sembrava pulita. La credenziale ha superato ogni controllo richiesto dal sistema.
Ma il destinatario non è mai apparso da nessuna parte al di fuori dell'attestazione stessa.
È lì che ha iniziato a sembrare strano.
Così l'ho tracciato fino a qui.
Stavo controllando un indirizzo destinatario su un'attestazione questa mattina.
Zero transazioni.
Zero storia.
La credenziale era valida.
L'indirizzo non aveva mai fatto nulla.
Ne ho preso un altro.
Schema diverso.
Emittente diverso.
Stesso risultato.
Il campo `recipients` è stato popolato. Codificato in ABI. La struttura sembrava pulita. La credenziale ha superato ogni controllo richiesto dal sistema.
Ma il destinatario non è mai apparso da nessuna parte al di fuori dell'attestazione stessa.
È lì che ha iniziato a sembrare strano.
Così l'ho tracciato fino a qui.
FIRMA e la validità che non passa mai
@SignOfficial
Una credenziale è scaduta mentre l'emittente era ancora attivo.
Niente è stato revocato.
Quindi l'ho tirato di nuovo.
`validUntil`
Prima di quanto fosse stato impostato.
Sono tornato indietro.
Stessa attestazione.
Stesso valore.
Quindi ho controllato un livello sopra.
Schema.
`maxValidFor`
Inferiore.
Ne ho fatto un altro.
Stessa schema.
Attestatore diverso.
Hanno spostato ulteriormente la finestra.
Non è apparso.
La credenziale è tornata più corta.
Nessun ripristino.
Nessun avviso.
Manca solo tempo.
Pensavo potesse essere incoerente.
Quindi ho continuato a spingere.
Più attestazioni.
Stessa frontiera.
Una credenziale è scaduta mentre l'emittente era ancora attivo.
Niente è stato revocato.
Quindi l'ho tirato di nuovo.
`validUntil`
Prima di quanto fosse stato impostato.
Sono tornato indietro.
Stessa attestazione.
Stesso valore.
Quindi ho controllato un livello sopra.
Schema.
`maxValidFor`
Inferiore.
Ne ho fatto un altro.
Stessa schema.
Attestatore diverso.
Hanno spostato ulteriormente la finestra.
Non è apparso.
La credenziale è tornata più corta.
Nessun ripristino.
Nessun avviso.
Manca solo tempo.
Pensavo potesse essere incoerente.
Quindi ho continuato a spingere.
Più attestazioni.
Stessa frontiera.
@SignOfficial
Ho ricaricato la stessa attestazione e i dati erano cambiati.
Stessa `dataLocation`.
Contenuto diverso.
L'ho controllato di nuovo.
Stesso puntatore.
Ancora diverso.
Quindi ho estratto il timestamp.
`attestTimestamp`
Più vecchio di quello che stavo vedendo ora.
Pensavo di aver confuso qualcosa.
Quindi ne ho provato un altro.
Attestazione diversa.
Stesso schema.
Stessa posizione.
Nuovi dati.
È lì che ha smesso di sembrare un errore.
L'attestazione è stata verificata.
Pulita.
Niente è andato storto.
Niente è stato segnalato.
Ma ciò a cui si è risolto non era ciò che c'era quando è stata emessa.
Ho continuato.
Altre attestazioni utilizzando `dataLocation` off-chain.
Stesso comportamento.
Il riferimento rimane fisso.
Il contenuto dietro di esso si sposta.
E il sistema lo tratta come la stessa cosa.
Continuo a tornare a questo.
Deriva del puntatore.
Il sistema ancorisce la posizione…
non lo stato dei dati a `attestTimestamp`.
Quindi continua a verificare.
Solo non contro ciò che l'emittente ha effettivamente visto.
È qui che si rompe.
La credenziale passa…
ma non sta più dimostrando ciò contro cui è stata emessa.
$SIGN ha importanza qui solo se un sistema che verifica contro un `dataLocation` invece dello stato a `attestTimestamp` è ancora sufficiente una volta che questi due iniziano a divergere su larga scala.
Perché una volta che si allontanano…
niente si rompe.
Niente fallisce.
Niente viene aggiornato.
Continua a verificare.
Quindi la vera domanda diventa questa.
Quando il puntatore rimane stabile ma i dati cambiano…
cosa sta ancora dimostrando l'attestazione?
#SignDigitalSovereignInfra #Sign
Ho ricaricato la stessa attestazione e i dati erano cambiati.
Stessa `dataLocation`.
Contenuto diverso.
L'ho controllato di nuovo.
Stesso puntatore.
Ancora diverso.
Quindi ho estratto il timestamp.
`attestTimestamp`
Più vecchio di quello che stavo vedendo ora.
Pensavo di aver confuso qualcosa.
Quindi ne ho provato un altro.
Attestazione diversa.
Stesso schema.
Stessa posizione.
Nuovi dati.
È lì che ha smesso di sembrare un errore.
L'attestazione è stata verificata.
Pulita.
Niente è andato storto.
Niente è stato segnalato.
Ma ciò a cui si è risolto non era ciò che c'era quando è stata emessa.
Ho continuato.
Altre attestazioni utilizzando `dataLocation` off-chain.
Stesso comportamento.
Il riferimento rimane fisso.
Il contenuto dietro di esso si sposta.
E il sistema lo tratta come la stessa cosa.
Continuo a tornare a questo.
Deriva del puntatore.
Il sistema ancorisce la posizione…
non lo stato dei dati a `attestTimestamp`.
Quindi continua a verificare.
Solo non contro ciò che l'emittente ha effettivamente visto.
È qui che si rompe.
La credenziale passa…
ma non sta più dimostrando ciò contro cui è stata emessa.
$SIGN ha importanza qui solo se un sistema che verifica contro un `dataLocation` invece dello stato a `attestTimestamp` è ancora sufficiente una volta che questi due iniziano a divergere su larga scala.
Perché una volta che si allontanano…
niente si rompe.
Niente fallisce.
Niente viene aggiornato.
Continua a verificare.
Quindi la vera domanda diventa questa.
Quando il puntatore rimane stabile ma i dati cambiano…
cosa sta ancora dimostrando l'attestazione?
#SignDigitalSovereignInfra #Sign
@SignOfficial
Ho provato a revocare un'attestazione prima e non si è spostata.
Nessun errore.
Solo nessun percorso.
L'ho controllata di nuovo.
Ancora valida.
Quindi sono salito di un livello.
Schema.
`revocable = false`
Ne ho eseguita un'altra sotto lo stesso schema.
Attestazione diversa.
Stesso risultato.
Due credenziali.
Nessuna delle due poteva essere revocata.
È stato allora che è cambiato.
Questa non è stata una revoca fallita.
Non c'era nulla da eseguire.
La credenziale non era bloccata dopo l'emissione.
È stata emessa in quel modo.
Ho continuato.
Altre attestazioni.
Stesso schema.
Stesso comportamento.
Ognuna di esse poteva essere emessa.
Nessuna di esse poteva essere ritirata.
E nulla nell'attestazione te lo dice.
Lo vedi solo quando provi a revocare...
e non succede nulla.
Continuo a tornare a questo.
Un blocco di revoca.
Non un ritardo.
Non una restrizione.
Solo assenza.
L'abilità di emettere esiste.
L'abilità di correggere non esiste.
E quella decisione non viene presa quando la credenziale viene creata.
È già stata presa prima che esista.
$SIGN conta qui solo se un sistema in cui `revocable = false` rimuove completamente la revoca a livello di schema è ancora sufficiente quando le condizioni attorno a quelle credenziali iniziano a cambiare.
Perché una volta che raggiungi quel confine...
niente si rompe.
Niente fallisce.
Niente si aggiorna.
Rimane semplicemente.
Quindi la vera domanda diventa questa.
Se la revoca non è mai esistita in primo luogo...
cosa si aspetta esattamente il sistema di adattare in seguito?
#SignDigitalSovereignInfra #Sign
Ho provato a revocare un'attestazione prima e non si è spostata.
Nessun errore.
Solo nessun percorso.
L'ho controllata di nuovo.
Ancora valida.
Quindi sono salito di un livello.
Schema.
`revocable = false`
Ne ho eseguita un'altra sotto lo stesso schema.
Attestazione diversa.
Stesso risultato.
Due credenziali.
Nessuna delle due poteva essere revocata.
È stato allora che è cambiato.
Questa non è stata una revoca fallita.
Non c'era nulla da eseguire.
La credenziale non era bloccata dopo l'emissione.
È stata emessa in quel modo.
Ho continuato.
Altre attestazioni.
Stesso schema.
Stesso comportamento.
Ognuna di esse poteva essere emessa.
Nessuna di esse poteva essere ritirata.
E nulla nell'attestazione te lo dice.
Lo vedi solo quando provi a revocare...
e non succede nulla.
Continuo a tornare a questo.
Un blocco di revoca.
Non un ritardo.
Non una restrizione.
Solo assenza.
L'abilità di emettere esiste.
L'abilità di correggere non esiste.
E quella decisione non viene presa quando la credenziale viene creata.
È già stata presa prima che esista.
$SIGN conta qui solo se un sistema in cui `revocable = false` rimuove completamente la revoca a livello di schema è ancora sufficiente quando le condizioni attorno a quelle credenziali iniziano a cambiare.
Perché una volta che raggiungi quel confine...
niente si rompe.
Niente fallisce.
Niente si aggiorna.
Rimane semplicemente.
Quindi la vera domanda diventa questa.
Se la revoca non è mai esistita in primo luogo...
cosa si aspetta esattamente il sistema di adattare in seguito?
#SignDigitalSovereignInfra #Sign
FIRMA e la credenziale rilasciata a qualcuno che non è mai stato lì
@SignOfficial
Stavo tracciando un insieme di attestazioni prima quando un indirizzo del destinatario continuava a ripetersi.
Nessuna attività.
L'ho controllato.
Niente.
Nessuna transazione.
Nessuna interazione.
Continuo a ricevere credenziali.
All'inizio pensavo di avere l'indirizzo sbagliato.
Così ho controllato di nuovo.
Stesso risultato.
Ho estratto i campi di attestazione.
`recipients`
Codificato.
Risolto senza problemi.
Nessun errore.
Nessun dato mancante.
Quindi ho ampliato l'ambito.
Emittenti diversi.
Schemi diversi.
Stesso schema.
Indirizzi a cui vengono assegnate le credenziali...
senza mai apparire altrove nel sistema.
Stavo tracciando un insieme di attestazioni prima quando un indirizzo del destinatario continuava a ripetersi.
Nessuna attività.
L'ho controllato.
Niente.
Nessuna transazione.
Nessuna interazione.
Continuo a ricevere credenziali.
All'inizio pensavo di avere l'indirizzo sbagliato.
Così ho controllato di nuovo.
Stesso risultato.
Ho estratto i campi di attestazione.
`recipients`
Codificato.
Risolto senza problemi.
Nessun errore.
Nessun dato mancante.
Quindi ho ampliato l'ambito.
Emittenti diversi.
Schemi diversi.
Stesso schema.
Indirizzi a cui vengono assegnate le credenziali...
senza mai apparire altrove nel sistema.
Midnight e la prova che è rimasta dopo che la sua origine è scomparsa
@MidnightNetwork
Stavo tracciando una prova attraverso il livello di verifica di Midnight quando qualcosa non si allineava.
Non sono riuscito a tornare da dove proveniva.
La prova era ancora lì.
È stato verificato pulitamente.
Ma non c'era niente intorno che mi dicesse come fosse stato prodotto.
Nessuno stato intermedio.
Nessun testimone visibile.
Niente che potessi seguire all'indietro.
L'ho eseguito di nuovo aspettandomi qualcosa che lo ancorasse.
Un riferimento.
Una traccia.
Qualsiasi cosa colleghi il risultato alla sua origine.
Niente.
La prova si è tenuta.
Il processo non lo ha fatto.
Stavo tracciando una prova attraverso il livello di verifica di Midnight quando qualcosa non si allineava.
Non sono riuscito a tornare da dove proveniva.
La prova era ancora lì.
È stato verificato pulitamente.
Ma non c'era niente intorno che mi dicesse come fosse stato prodotto.
Nessuno stato intermedio.
Nessun testimone visibile.
Niente che potessi seguire all'indietro.
L'ho eseguito di nuovo aspettandomi qualcosa che lo ancorasse.
Un riferimento.
Una traccia.
Qualsiasi cosa colleghi il risultato alla sua origine.
Niente.
La prova si è tenuta.
Il processo non lo ha fatto.
@MidnightNetwork
Ho controllato la conferma del validatore a Midnight subito dopo che un lotto di prova era stato approvato in precedenza e qualcosa riguardo a ciò che conteneva mi ha fermato.
Ha restituito un valido pulito.
Nessuna bandiera.
Ma non c'era nulla in esso che mi dicesse cosa fosse stato effettivamente verificato.
L'ho scorrere di nuovo aspettandomi che il contesto apparisse da qualche parte.
Un riferimento. Qualsiasi cosa.
Non c'era niente di più da trovare.
La conferma è rimasta.
Il significato no.
Ho dovuto controllarlo due volte.
Mi aspettavo che la verifica mi dicesse qualcosa sullo stato sottostante.
Non lo ha fatto.
È allora che ha smesso di sembrare dati mancanti.
E ha iniziato a sembrare strutturale.
Il validatore non sta confermando cosa è successo.
Sta confermando che qualcosa di valido è successo.
Senza mai aver bisogno di comprenderlo.
Continuo a tornare su questo come un gap di comprensione.
Dove la verifica rimane intatta.
Ma la comprensione non arriva mai.
Due stati sottostanti completamente diversi possono superare la stessa conferma.
E nulla nell'output li separa.
Questo tiene mentre il volume è basso.
Diventa più difficile ragionare quando le prove iniziano ad accumularsi.
$NIGHT conta solo qui se questo strato di verifica può ancora separare ciò che rimane valido da ciò che rimane significativo una volta che le conferme iniziano ad accumularsi.
Perché un sistema che può verificare tutto senza comprendere nulla non si rompe immediatamente.
Comprime le differenze nello stesso risultato.
Quindi il vero test diventa questo.
Quando le conferme iniziano a sovrapporsi sotto carico, su cosa è esattamente certo il network?
#night #Night
Ho controllato la conferma del validatore a Midnight subito dopo che un lotto di prova era stato approvato in precedenza e qualcosa riguardo a ciò che conteneva mi ha fermato.
Ha restituito un valido pulito.
Nessuna bandiera.
Ma non c'era nulla in esso che mi dicesse cosa fosse stato effettivamente verificato.
L'ho scorrere di nuovo aspettandomi che il contesto apparisse da qualche parte.
Un riferimento. Qualsiasi cosa.
Non c'era niente di più da trovare.
La conferma è rimasta.
Il significato no.
Ho dovuto controllarlo due volte.
Mi aspettavo che la verifica mi dicesse qualcosa sullo stato sottostante.
Non lo ha fatto.
È allora che ha smesso di sembrare dati mancanti.
E ha iniziato a sembrare strutturale.
Il validatore non sta confermando cosa è successo.
Sta confermando che qualcosa di valido è successo.
Senza mai aver bisogno di comprenderlo.
Continuo a tornare su questo come un gap di comprensione.
Dove la verifica rimane intatta.
Ma la comprensione non arriva mai.
Due stati sottostanti completamente diversi possono superare la stessa conferma.
E nulla nell'output li separa.
Questo tiene mentre il volume è basso.
Diventa più difficile ragionare quando le prove iniziano ad accumularsi.
$NIGHT conta solo qui se questo strato di verifica può ancora separare ciò che rimane valido da ciò che rimane significativo una volta che le conferme iniziano ad accumularsi.
Perché un sistema che può verificare tutto senza comprendere nulla non si rompe immediatamente.
Comprime le differenze nello stesso risultato.
Quindi il vero test diventa questo.
Quando le conferme iniziano a sovrapporsi sotto carico, su cosa è esattamente certo il network?
#night #Night
Mezzanotte e i Dati che Esistono Solo a Lungo Abbastanza per Scomparire
@MidnightNetwork
Stavo passando attraverso un flusso di prova prima oggi quando qualcosa non tornava.
I dati erano scomparsi.
La prova non c'era.
Mi aspettavo che la prova si rompesse una volta che gli input scomparissero.
Non lo ha fatto.
L'ho controllato di nuovo.
Stesso risultato.
Il testimone ha ancora tenuto.
Sembrava all'indietro.
Su la maggior parte dei sistemi, rimuovi i dati e qualsiasi cosa dipenda da esso collassa.
Qui, non è successo.
Quindi l'ho rallentato.
Passo dopo passo.
Dove gli input vivevano realmente.
Dove si sono fermati.
Dove è apparsa la prova.
Gli input privati non hanno mai toccato la catena.
Stavo passando attraverso un flusso di prova prima oggi quando qualcosa non tornava.
I dati erano scomparsi.
La prova non c'era.
Mi aspettavo che la prova si rompesse una volta che gli input scomparissero.
Non lo ha fatto.
L'ho controllato di nuovo.
Stesso risultato.
Il testimone ha ancora tenuto.
Sembrava all'indietro.
Su la maggior parte dei sistemi, rimuovi i dati e qualsiasi cosa dipenda da esso collassa.
Qui, non è successo.
Quindi l'ho rallentato.
Passo dopo passo.
Dove gli input vivevano realmente.
Dove si sono fermati.
Dove è apparsa la prova.
Gli input privati non hanno mai toccato la catena.
@MidnightNetwork
Stavo esaminando un contratto Compact questa mattina e qualcosa non quadrava.
Una condizione valutata vera.
Il circuito si comportava come se non esistesse.
Nessun errore.
Nessun fallimento.
Solo… scomparso.
Ho controllato gli input.
Corretto.
Controllato le condizioni.
Ancora vero.
Ma quando l'ho tracciato attraverso la compilazione, quel ramo non è mai diventato vincoli.
Un percorso condizionale che dipendeva da un input esterno valutato vero, ma non è mai entrato nel circuito.
Non rifiutato.
Non rotto.
Solo cancellato.
È lì che si è rotto per me.
Il circuito non esegue la tua logica.
Definisce quale logica è autorizzata a esistere.
Se qualcosa non può essere ridotto a vincoli, Compact non lo rifiuta.
Lo cancella.
Continuo a tornare su questo come esclusione di vincoli.
Non logica scorretta.
Solo logica che il sistema non è mai stato costruito per rappresentare.
Il che significa che qualcosa può essere vero…
e ancora essere non dimostrabile.
E il verificatore non saprà mai la differenza.
Perché dalla sua prospettiva, la prova è completa.
Ma completa su cosa?
Non realtà.
Solo ciò che il circuito ha permesso di esistere.
È lì che inizia a contare.
Perché ora il sistema può provare la correttezza…
to su una versione incompleta della realtà.
$NIGHT ha solo importanza se ciò che Compact esclude non diventa mai parte di ciò che il verificatore assume sia completo.
Perché se lo fa, nulla si rompe.
La prova passa ancora.
Solo la verità scompare.
Quindi la vera domanda diventa questa.
Se qualcosa può essere vero ma mai dimostrabile, cosa sta veramente verificando il sistema?
#night #Night
Stavo esaminando un contratto Compact questa mattina e qualcosa non quadrava.
Una condizione valutata vera.
Il circuito si comportava come se non esistesse.
Nessun errore.
Nessun fallimento.
Solo… scomparso.
Ho controllato gli input.
Corretto.
Controllato le condizioni.
Ancora vero.
Ma quando l'ho tracciato attraverso la compilazione, quel ramo non è mai diventato vincoli.
Un percorso condizionale che dipendeva da un input esterno valutato vero, ma non è mai entrato nel circuito.
Non rifiutato.
Non rotto.
Solo cancellato.
È lì che si è rotto per me.
Il circuito non esegue la tua logica.
Definisce quale logica è autorizzata a esistere.
Se qualcosa non può essere ridotto a vincoli, Compact non lo rifiuta.
Lo cancella.
Continuo a tornare su questo come esclusione di vincoli.
Non logica scorretta.
Solo logica che il sistema non è mai stato costruito per rappresentare.
Il che significa che qualcosa può essere vero…
e ancora essere non dimostrabile.
E il verificatore non saprà mai la differenza.
Perché dalla sua prospettiva, la prova è completa.
Ma completa su cosa?
Non realtà.
Solo ciò che il circuito ha permesso di esistere.
È lì che inizia a contare.
Perché ora il sistema può provare la correttezza…
to su una versione incompleta della realtà.
$NIGHT ha solo importanza se ciò che Compact esclude non diventa mai parte di ciò che il verificatore assume sia completo.
Perché se lo fa, nulla si rompe.
La prova passa ancora.
Solo la verità scompare.
Quindi la vera domanda diventa questa.
Se qualcosa può essere vero ma mai dimostrabile, cosa sta veramente verificando il sistema?
#night #Night
FIRMA e lo schema che non ha imposto alcun tetto
@SignOfficial
`validUntil` era impostato a zero.
Mi aspettavo che scadesse al prossimo controllo.
Non lo ha fatto.
Zero significava solo nessuna scadenza a livello di attestazione.
Quindi sono salito di un livello.
Controllato lo schema.
`maxValidFor`
Anche zero.
È lì che ha smesso di avere senso.
Non c'era alcun tetto ovunque.
Non è sull'attestazione.
Non è nello schema.
Ne ho eseguito un altro.
Schema diverso.
Stessa configurazione.
`validUntil = 0`
`maxValidFor = 0`
Stesso risultato.
La credenziale continuava a risolvere.
Nessuna scadenza.
Nessun ricontrollo.
Nessun segnale costringendolo a fermarsi.
Questa era la prima anomalia.
`validUntil` era impostato a zero.
Mi aspettavo che scadesse al prossimo controllo.
Non lo ha fatto.
Zero significava solo nessuna scadenza a livello di attestazione.
Quindi sono salito di un livello.
Controllato lo schema.
`maxValidFor`
Anche zero.
È lì che ha smesso di avere senso.
Non c'era alcun tetto ovunque.
Non è sull'attestazione.
Non è nello schema.
Ne ho eseguito un altro.
Schema diverso.
Stessa configurazione.
`validUntil = 0`
`maxValidFor = 0`
Stesso risultato.
La credenziale continuava a risolvere.
Nessuna scadenza.
Nessun ricontrollo.
Nessun segnale costringendolo a fermarsi.
Questa era la prima anomalia.
@SignOfficial
`attestTimestamp` corrisponde a `revokeTimestamp`.
Nessun gap.
Non dovrebbe succedere.
L'ho notato mentre controllavo i timestamp.
Ne ho controllato un altro.
Stessa modalità.
Emittente diverso.
Stesso risultato.
All'inizio sembrava una questione di tempistica.
Come se la revoca fosse avvenuta subito dopo l'emissione.
Non è stato così.
Non c'era “dopo”.
I registri SIGN documentano entrambi gli eventi in modo indipendente.
Si sono semplicemente risolti allo stesso momento.
Il che significa che questa attestazione non ha mai avuto uno stato valido.
Non per un breve periodo.
Non nemmeno per un blocco.
Il che significa che non c'è mai stato uno stato che qualsiasi sistema potesse leggere.
È qui che è cambiato.
Questa non era un'attestazione revocata.
Era una che ha saltato completamente la validità.
Annullamento istantaneo.
Un'attestazione che esiste nella struttura, ma non è mai esistita nel tempo.
Ho seguito come il sistema la tratta.
Si risolve.
Lo schema si carica.
L'emittente viene verificato.
Tutto passa in superficie.
Tranne che non c'è mai stato un punto in cui potesse effettivamente essere usato.
Questo appare solo se leggi i timestamp direttamente.
Qui è dove $SIGN inizia a contare.
$SIGN conta solo se il protocollo può distinguere tra un'attestazione in cui `attestTimestamp == revokeTimestamp` e una che è diventata invalida successivamente.
Perché al momento entrambi si risolvono allo stesso modo, anche se solo uno è mai stato valido.
Quindi la domanda diventa questa.
Se l'emissione può produrre qualcosa che non è mai stata valida nemmeno per un secondo, cosa significa esattamente “emesso” all'interno del sistema?
#SignDigitalSovereignInfra #Sign
`attestTimestamp` corrisponde a `revokeTimestamp`.
Nessun gap.
Non dovrebbe succedere.
L'ho notato mentre controllavo i timestamp.
Ne ho controllato un altro.
Stessa modalità.
Emittente diverso.
Stesso risultato.
All'inizio sembrava una questione di tempistica.
Come se la revoca fosse avvenuta subito dopo l'emissione.
Non è stato così.
Non c'era “dopo”.
I registri SIGN documentano entrambi gli eventi in modo indipendente.
Si sono semplicemente risolti allo stesso momento.
Il che significa che questa attestazione non ha mai avuto uno stato valido.
Non per un breve periodo.
Non nemmeno per un blocco.
Il che significa che non c'è mai stato uno stato che qualsiasi sistema potesse leggere.
È qui che è cambiato.
Questa non era un'attestazione revocata.
Era una che ha saltato completamente la validità.
Annullamento istantaneo.
Un'attestazione che esiste nella struttura, ma non è mai esistita nel tempo.
Ho seguito come il sistema la tratta.
Si risolve.
Lo schema si carica.
L'emittente viene verificato.
Tutto passa in superficie.
Tranne che non c'è mai stato un punto in cui potesse effettivamente essere usato.
Questo appare solo se leggi i timestamp direttamente.
Qui è dove $SIGN inizia a contare.
$SIGN conta solo se il protocollo può distinguere tra un'attestazione in cui `attestTimestamp == revokeTimestamp` e una che è diventata invalida successivamente.
Perché al momento entrambi si risolvono allo stesso modo, anche se solo uno è mai stato valido.
Quindi la domanda diventa questa.
Se l'emissione può produrre qualcosa che non è mai stata valida nemmeno per un secondo, cosa significa esattamente “emesso” all'interno del sistema?
#SignDigitalSovereignInfra #Sign
Mezzanotte e il Testimone che Sopravvive ai Dati
@MidnightNetwork
Stavo seguendo un flusso di prova earlier oggi quando qualcosa riguardo il testimone non aveva senso.
I dati erano spariti.
La prova non c'era.
L'ho controllato di nuovo solo per essere sicuro.
Stesso risultato.
Il testimone era ancora presente.
Quello sembrava all'indietro.
Nella maggior parte dei sistemi, una volta che i dati scompaiono, qualsiasi cosa dipendesse da essi scompare con essi.
Qui, non c'era.
Quindi l'ho rallentato.
Passo dopo passo.
Dove i dati vivevano realmente.
Dove si è fermato.
Dove è emersa la prova.
Gli input non hanno mai toccato la catena.
Sono rimasti locali.
Poi è scomparso.
Stavo seguendo un flusso di prova earlier oggi quando qualcosa riguardo il testimone non aveva senso.
I dati erano spariti.
La prova non c'era.
L'ho controllato di nuovo solo per essere sicuro.
Stesso risultato.
Il testimone era ancora presente.
Quello sembrava all'indietro.
Nella maggior parte dei sistemi, una volta che i dati scompaiono, qualsiasi cosa dipendesse da essi scompare con essi.
Qui, non c'era.
Quindi l'ho rallentato.
Passo dopo passo.
Dove i dati vivevano realmente.
Dove si è fermato.
Dove è emersa la prova.
Gli input non hanno mai toccato la catena.
Sono rimasti locali.
Poi è scomparso.
@MidnightNetwork
Questa mattina stavo esaminando un contratto Compact quando qualcosa non si è comportata come mi aspettavo.
Il risultato avrebbe dovuto seguire.
Non lo ha fatto.
Nessun fallimento.
Nessun output.
Solo... niente.
L'ho eseguito di nuovo.
Stessi input.
Stesse condizioni.
Ancora bloccato.
A quel punto pensavo di aver cablato qualcosa di sbagliato.
Così sono tornato indietro.
Linea per linea.
Qualcosa sembrava strano.
Il percorso non stava fallendo.
Non è mai riuscito a completarlo.
È allora che è scattato.
Non si è rotto.
È scomparso.
Solo una parte della logica è effettivamente sopravvissuta.
Il resto non poteva essere espresso come vincoli, quindi non è mai entrato nel circuito.
Non è stato rifiutato.
Solo... non esprimibile.
Questa è un'altra sorta di confine.
Non runtime.
Non validazione.
Prima di entrambi.
Continuo a tornare su questo come vincolo di pre-prova.
Perché ciò che viene compilato non è la tua logica completa.
È solo la parte che può esistere come vincoli all'interno del circuito.
Tutto il resto semplicemente non appare mai.
Il che rende il debug strano.
Non stai cercando errori.
Stai cercando di notare cosa manca.
E lo vedi solo se già lo sospetti.
$NIGHT conta solo se gli sviluppatori possono effettivamente rilevare quali parti della loro logica sopravvivono alla compilazione dei vincoli quando le applicazioni reali iniziano a colpire casi limite.
Perché questo non apparirà quando tutto è pulito.
Appare quando qualcosa dovrebbe funzionare... e semplicemente non c'è.
Quindi la vera domanda diventa questa.
Se Compact filtra la logica prima che diventi mai parte del circuito, come fai a rilevare cosa il tuo contratto non è mai stato autorizzato a fare?
#night #Night
Questa mattina stavo esaminando un contratto Compact quando qualcosa non si è comportata come mi aspettavo.
Il risultato avrebbe dovuto seguire.
Non lo ha fatto.
Nessun fallimento.
Nessun output.
Solo... niente.
L'ho eseguito di nuovo.
Stessi input.
Stesse condizioni.
Ancora bloccato.
A quel punto pensavo di aver cablato qualcosa di sbagliato.
Così sono tornato indietro.
Linea per linea.
Qualcosa sembrava strano.
Il percorso non stava fallendo.
Non è mai riuscito a completarlo.
È allora che è scattato.
Non si è rotto.
È scomparso.
Solo una parte della logica è effettivamente sopravvissuta.
Il resto non poteva essere espresso come vincoli, quindi non è mai entrato nel circuito.
Non è stato rifiutato.
Solo... non esprimibile.
Questa è un'altra sorta di confine.
Non runtime.
Non validazione.
Prima di entrambi.
Continuo a tornare su questo come vincolo di pre-prova.
Perché ciò che viene compilato non è la tua logica completa.
È solo la parte che può esistere come vincoli all'interno del circuito.
Tutto il resto semplicemente non appare mai.
Il che rende il debug strano.
Non stai cercando errori.
Stai cercando di notare cosa manca.
E lo vedi solo se già lo sospetti.
$NIGHT conta solo se gli sviluppatori possono effettivamente rilevare quali parti della loro logica sopravvivono alla compilazione dei vincoli quando le applicazioni reali iniziano a colpire casi limite.
Perché questo non apparirà quando tutto è pulito.
Appare quando qualcosa dovrebbe funzionare... e semplicemente non c'è.
Quindi la vera domanda diventa questa.
Se Compact filtra la logica prima che diventi mai parte del circuito, come fai a rilevare cosa il tuo contratto non è mai stato autorizzato a fare?
#night #Night
SIGN e il Credenziale che Esiste Senza Essere Mai Utilizzato
@SignOfficial
Stavo guardando un'attestazione questa mattina che continuava a passare.
Ogni controllo.
Valido.
Emittente attivo.
Schema risolto.
Niente di sbagliato.
Ma qualcosa sembrava strano.
Quindi ho seguito dove veniva utilizzato.
O dove mi aspettavo che fosse.
Niente.
Nessun controllo a valle che lo faccia riferimento.
Nessun flusso di idoneità che dipenda da esso.
Nessun sistema che lo legga.
Esisteva.
Ma niente la toccava.
All'inizio pensavo di aver perso la connessione.
Query errata.
Endpoint errato.
Quindi ho controllato di nuovo.
Percorso diverso.
Stesso risultato.
Stavo guardando un'attestazione questa mattina che continuava a passare.
Ogni controllo.
Valido.
Emittente attivo.
Schema risolto.
Niente di sbagliato.
Ma qualcosa sembrava strano.
Quindi ho seguito dove veniva utilizzato.
O dove mi aspettavo che fosse.
Niente.
Nessun controllo a valle che lo faccia riferimento.
Nessun flusso di idoneità che dipenda da esso.
Nessun sistema che lo legga.
Esisteva.
Ma niente la toccava.
All'inizio pensavo di aver perso la connessione.
Query errata.
Endpoint errato.
Quindi ho controllato di nuovo.
Percorso diverso.
Stesso risultato.
Accedi per esplorare altri contenuti