Che cosa garantiamo

1. Il target è fissato prima che tu cominci

puoi verificarlo tu

Quando apri una sessione, il server estrae il target e calcola un impegno crittografico (commitment): lo SHA-256 dell'identificativo del target, di un valore casuale di 32 byte e dell'identificativo della sessione. L'impegno crittografico è sotto “Verifica questa sessione”: annotalo, o copia i suoi primi otto caratteri sul tuo foglio (sheet). Dopo la rivelazione (reveal), il valore casuale è nei dati della rivelazione e puoi ricalcolare l'impegno crittografico. Se corrisponde, il target era fissato quando hai aperto la sessione.

2. Anche l'immagine è fissata

puoi verificarlo tu, per le sessioni aperte dal 7 ottobre 2026, 01:42 (ora di Roma)

L'impegno crittografico fissa un identificativo, non un'immagine. Dal 7 ottobre 2026 lo SHA-256 di ogni immagine del pool di immagini viene registrato prima che una sessione possa estrarla, e ancorato (anchored) nella blockchain di Bitcoin con il lotto (batch) successivo. Dopo la rivelazione puoi salvare le cinque immagini e controllare ciascuna con il suo hash ancorato; lo script di verifica ti dice anche se la tua sessione è coperta, cioè se i cinque hash sono stati ancorati non oltre il tuo impegno crittografico. Per le sessioni aperte prima di quel momento, su quale immagine indichi l'identificativo c'è solo la nostra parola.

3. Le tue impressioni sono fissate prima che tu veda qualsiasi immagine candidata (candidate)

lo facciamo rispettare noi, poi viene ancorato

Sigilli (seal) la sessione prima che ti venga inviata qualsiasi immagine candidata: il server rifiuta di mostrare le immagini candidate per una sessione non sigillata. Il sigillo conserva un hash di ogni fotografia, così come viene salvata dopo che ne sono stati rimossi i metadati, e un hash dell'eventuale testo che hai scritto, e quegli hash vengono ancorati. Una sessione sigillata non può essere modificata. I campi del protocollo strutturato sono congelati dal database ma non entrano nell'hash.

4. Le cinque immagini candidate si presentano allo stesso modo

in parte puoi verificarlo tu

Ogni immagine è salvata esattamente alla stessa dimensione, 1 MiB, come puoi vedere da ciò che scarica il tuo browser. Le cinque sono mostrate nella stessa cornice e si caricano insieme, oppure non se ne mostra nessuna; nulla nel modo in cui vengono servite dipende da quale sia il target. Per le sessioni aperte dopo una modifica fatta il 1° ottobre 2026, l'ordine in cui vengono mostrate deriva dal valore casuale della sessione ed è registrato, e dopo la rivelazione puoi ricalcolarlo; i dati della rivelazione dicono di che tipo è la tua sessione. Le sessioni precedenti usavano un ordine che possiamo ricalcolare solo noi.

5. Metti in ordine senza conoscere la risposta

lo facciamo rispettare noi, poi viene ancorato

Il target ti viene nascosto finché la tua classifica (ranking) non è bloccata. Una classifica bloccata non può essere cambiata, ed è ancorata insieme all'ora in cui è stata bloccata.

6. Ogni classifica che blocchi conta

lo facciamo rispettare noi

Una volta passati sette giorni da quando hai bloccato una classifica, se non l'hai rivelata, la rivela il sito al posto tuo alla sua esecuzione programmata successiva, e conta come qualsiasi altra. Una sessione abbandonata (abandoned) prima della classifica viene contata come abbandonata, non scartata. Ogni sessione che apri lascia un impegno crittografico ancorato.

7. Niente viene riscritto dopo

puoi verificarlo tu, per la tua sessione

Impegni crittografici, sigilli, classifiche bloccate, hash delle immagini, esclusioni dichiarate (declared exclusions) e ogni controllo della regola di arresto (stopping rule) sono scritti in tabelle i cui trigger rifiutano modifiche e cancellazioni. L'unica eccezione è la pulizia delle sessioni da ospite (guest sessions) dopo un giorno, che toglie a una sessione da ospite il collegamento al suo impegno crittografico e conserva l'impegno crittografico. Questo vincola l'applicazione, non noi: il database lo gestiamo noi. Quello che vincola noi è l'ancoraggio. Con una cadenza programmata ogni ora, tutto ciò che è nuovo viene raccolto in un unico hash, concatenato al lotto precedente e marcato nella blockchain di Bitcoin tramite OpenTimestamps entro poche ore. Una volta che il lotto di un record è in un blocco Bitcoin, cambiare il record ne romperebbe la prova. Puoi verificarlo per la tua sessione. I record delle altre sessioni, e i controlli della regola di arresto, può verificarli solo chi li possiede: il registro completo non è pubblico.

8. Le esclusioni sono dichiarate, mai scelte in base al risultato

lo facciamo rispettare noi

Una sessione può essere lasciata fuori dall'analisi solo con una dichiarazione, per una ragione fissata in anticipo che riguarda da dove viene la sessione, mai com'è andata. Ogni dichiarazione registra la sua data, e l'analisi mostra se è arrivata prima che la sessione fosse sigillata. Ogni dichiarazione indica la sezione e il commit delle note di preregistrazione che la fanno, e quelle note sono pubbliche nella pagina della preregistrazione. Le sessioni da ospite non sono mai dati.

9. Le regole vengono prima dei dati a cui si applicano

in parte puoi verificarlo tu

Le decisioni di analisi prese finora, la regola di arresto e ogni loro modifica sono nelle nostre note di preregistrazione su /preregistration, con l'hash e la prova OpenTimestamps di ogni versione; viene pubblicato solo il testo attuale. La regola di arresto e ogni sua modifica valgono da un istante indicato nel loro testo, non prima del commit che le ha aggiunte. Ogni prova mostra che una versione esisteva al più tardi al momento del suo blocco Bitcoin, qualche ora dopo che ci è arrivata; che sia stata committata prima dell'istante che dichiara si basa sulle date di git, che controlliamo noi. Le sessioni aperte prima che la regola di arresto fosse dichiarata restano esplorative. Le note non sono ancora depositate presso un registro, e l'ipotesi confermativa non è ancora dichiarata.

10. La mano dell'operatore si vede dove conta

• puoi verificarlo tu

  Chiusure. Se l'operatore cancella un account il cui studio ha dati contati, la chiusura viene pubblicata automaticamente, con la data, la ragione, la fase, il numero di dati e, se lo studio ha raggiunto un punto di controllo (checkpoint), l'ultimo fattore di Bayes registrato, su /api/v1/stopping/operator-closures.

• lo facciamo rispettare noi

  Consultazioni dei risultati. Ogni consultazione dei risultati dal pannello di ricerca viene registrata con la sua data e la sua ragione. Il registro non è pubblico, e non copre l'accesso diretto al database.

11. I tuoi dati

lo facciamo rispettare noi

Non ti viene mai chiesto un indirizzo email, e il tuo indirizzo IP non è conservato in chiaro. Puoi cancellare il tuo account dalla pagina del tuo account: cancelliamo il tuo nick, le tue credenziali e ogni foglio che hai fotografato, e il tuo nick non potrà mai più essere registrato. Il fornitore che ospita il nostro database ne conserva una cronologia mobile delle ultime sei ore, a scopo di ripristino; passato quel tempo, niente di tutto questo può essere recuperato. Le tue sessioni restano, senza alcun nome: posizioni, orari, target, le risposte prima della sessione, l'eventuale testo che hai scritto, e gli hash e le ore di scatto delle fotografie. Restano collegate tra loro da un identificativo che non porta alcun nome. Il testo scritto non può essere rimosso dopo il sigillo; se per te conta, metti tutto su carta. Puoi scaricare il tuo account e tutto ciò che contengono le sue sessioni, in un unico file, dalla pagina del tuo account. Il nostro hosting, Vercel, conserva log delle richieste con il tuo indirizzo per un periodo che decide Vercel, e Cloudflare Turnstile, nelle pagine che ti chiedono di dimostrare di essere una persona, riceve il tuo indirizzo e segnali dal tuo browser. L'originale di una fotografia, metadati compresi, viene cancellato al sigillo, o al più tardi dalla seconda pulizia programmata (sweep) dopo che la sessione è stata sigillata o si è conclusa.

Che cosa non possiamo garantire

• Il server durante la tua sessione. Gli ancoraggi dimostrano che niente è stato cambiato dopo. Non possono dimostrare che il server si sia comportato onestamente mentre la tua sessione era in corso. Questo si basa sul progetto descritto qui e su codice che non puoi leggere.
• Le prime ore. Un record aspetta il lotto programmato successivo, poi qualche ora per Bitcoin; dentro quella finestra lo protegge solo il database. Fino al 5 ottobre 2026 le esecuzioni programmate che costruiscono i lotti sono partite a una distanza compresa tra 48 minuti e 8 ore e 21 minuti l'una dall'altra. Lo script di verifica stampa lo scarto effettivo per ogni record della tua sessione.
• Il registro iniziale. I record scritti prima del primo lotto, il 3 ottobre 2026, risultano esistenti a partire dalla data di quel lotto, non da quando sono stati scritti. Per le versioni delle note di preregistrazione precedenti al 2 ottobre 2026, 23:41, l'esistenza è dimostrata da quel momento.
• Che cosa c'era sul tuo schermo mentre mettevi in ordine le immagini. Il controllo delle immagini fissa i byte serviti dopo il loro lotto. I file che salvi mentre le metti in ordine rivelerebbero una sostituzione; quelli salvati dopo la rivelazione no.
• Il codice non è pubblico. Puoi verificare i record della tua sessione, con uno script di verifica pubblico che non condivide codice con il sito; non puoi leggere il software che li ha prodotti.
• Che questo tipo di target sia adatto al remote viewing. Un risultato pari al caso (chance) non può distinguere “nessun effetto” da “tipo di target sbagliato”.

Come verificare, passo per passo

Ti servono Node.js 18 o successivo e un terminale. Quando apri una sessione, annota l'impegno crittografico sotto “Verifica questa sessione”.

La tua sessione

1. Dopo la rivelazione, apri /api/v1/sessions/<session id>/reveal nello stesso browser, dove hai effettuato l'accesso, e salva la pagina come reveal.json. Solo tu puoi scaricarlo.
2. Nella schermata della rivelazione, sotto “Salva le cinque immagini”, salva i file da A.jpg a E.jpg nella stessa cartella.

3. Scarica lo script di verifica:

   curl -o verify-anchor.mjs https://www.bearemoteviewer.com/verify-anchor.mjs

4. Eseguilo. Ricalcola l'impegno crittografico e l'ordine in cui ti sono state mostrate le cinque immagini, controlla ogni record della tua sessione e il suo percorso fino al suo lotto, la catena dei lotti dal primo in poi, il blocco Bitcoin, e ogni immagine rispetto ai cinque hash ancorati:

   node verify-anchor.mjs session reveal.json --image A.jpg --image B.jpg --image C.jpg --image D.jpg --image E.jpg --batches https://www.bearemoteviewer.com/api/v1/anchor/batches

   Codice di uscita 0: tutto verificato, Bitcoin compreso. 3: valido finora, ma una prova non è ancora in un blocco Bitcoin; salva di nuovo reveal.json tra qualche ora e rilancialo. 1: qualcosa non è stato verificato; leggi le righe FAIL. Una riga FAIL che finisce con “could not be checked: fetch failed” significa che un block explorer non ha risposto: rilancialo.

5. Confronta l'impegno crittografico con quello che hai annotato all'inizio:

   node -e "console.log(require('./reveal.json').commitment.commit)"

6. Per ricalcolare l'impegno crittografico senza il nostro script di verifica, con lo SHA-256 di Node:

   node -e "const c=require('crypto'),r=require('./reveal.json').commitment,u=s=>Buffer.from(s.replace(/-/g,''),'hex');const h=c.createHash('sha256').update(u(r.targetId)).update(Buffer.from(r.nonce,'hex')).update(u(r.sessionId)).digest('hex');console.log(h===r.commit?'commit OK':'commit MISMATCH')"

7. Lo stesso per l'ordine in cui ti sono state mostrate le cinque immagini, se pack.orderScheme in reveal.json è 2:

   node -e "const c=require('crypto'),r=require('./reveal.json'),n=Buffer.from(r.commitment.nonce,'hex'),u=s=>Buffer.from(s.replace(/-/g,''),'hex'),k=id=>c.createHash('sha256').update(n).update('order').update(u(id)).digest();const o=[...r.pack.members].sort((a,b)=>Buffer.compare(k(a),k(b)));console.log(o.join()===r.pack.presented.join()?'order OK':'order MISMATCH')"

8. Per non fidarti di nessun block explorer, prendi le intestazioni dei blocchi dal tuo nodo Bitcoin e passale con --headers headers.json; il formato è nelle prime righe dello script di verifica.

Una versione delle note di preregistrazione

Viene pubblicato solo il testo della versione attuale; per le versioni precedenti ci sono l'hash e la prova.

1. Scarica il testo attuale:

   curl -o preregistration.md https://www.bearemoteviewer.com/api/v1/preregistration/document

2. Calcolane lo SHA-256 e confrontalo con l'hash segnato “questa” su /preregistration:

   sha256sum preregistration.md

3. Scarica la prova per quell'hash, con l'hash al posto di <sha256>:

   curl -o preregistration.ots https://www.bearemoteviewer.com/api/v1/preregistration/stamps/<sha256>.ots

4. Verificala, oppure usa ots verify dal client di OpenTimestamps:

   node verify-anchor.mjs file preregistration.md preregistration.ots

Su Windows. In Windows PowerShell scrivi curl.exe dovunque questi passi dicono curl: lì il semplice curl è un altro comando. Per l'hash, usa (Get-FileHash preregistration.md).Hash.ToLower() invece di sha256sum. I comandi node funzionano così come sono scritti, in PowerShell e in bash.