Fiecare recenzie: (1) e semnată criptografic de dispozitivul clientului, (2) intră într-un registru append-only semnat Ed25519, ancorat OpenTimestamps, și (3) capul registrului e inclus în root-ul de rețea Primer — salonul nu poate prezenta nimănui un istoric alternativ. Cheia publică a salonului e ancorată în registru (primul entry); rețeaua semnează cu o cheie separată, a platformei.
curl -s https://bozanalex.ro/reviews/verify.mjs -o verify.mjs node verify.mjs https://bozanalex.ro
Verifier-ul e open-source: github.com/iclaudiumihaila/verified-reviews-verifier — compară
copia de aici cu cea din repo (trebuie să fie identică) sau scrie-ți propriul: totul e SHA-256 + Ed25519 +
canonical JSON documentat. Verdictul „TOTUL VALID" apare doar când și ancorele Bitcoin sunt confirmate;
cu ancore în așteptare vei vedea onest „VALID CRIPTOGRAFIC — ancorele Bitcoin sunt în așteptare".
| Etichetă / câmp | Cine o garantează |
|---|---|
Rating, text, dată vizită (rating, comment în chain, visitedAt), identitatea pseudonimă (reviewerRef) | Verificabil — semnat de dispozitivul clientului (authorProof); cheile sunt în devices.json |
| Integritatea istoricului (chain, head, inclusion proof, ancore OTS) | Verificabil — SHA-256 + Ed25519 + Merkle + Bitcoin |
paidVisit, paymentMethod, returningClient, visitCount, reviewerSince | Afirmație a salonului — înghețată în hash (nu poate fi schimbată retroactiv), dar neverificabilă de un terț; fiecare payload o marchează explicit în claimSource.salon |
reviewerSalonCount („reviewer activ în rețea") | Mixt — prezența reviewerului la alte saloane e verificabilă în chain-urile lor (verifier-ul o face la pasul 10); numărul exact e afirmația salonului |
Ca să verifici ancorele fără biblioteca oficială, parsează fișierul .ots astfel (toate
numerele multi-byte sunt varuint: 7 biți/octet, bitul 8 = continuare):
offset 0: magic de 31 bytes: 00 "OpenTimestamps" 00 00 "Proof" 00 bf89e2e884e89294 apoi: varuint versiune (la noi: 01) apoi: 08 — op-ul SHA256 (hash-ul fișierului timestampuit) apoi: digest (32 bytes) — trebuie să fie EXACT merkleRoot-ul publicat în document apoi: operații, până la EOF: 00 — attestation: urmează tag (8 bytes) + varuint lungime + payload 08 — aplică SHA256 peste mesajul curent 02 — aplică RIPEMD160 peste mesajul curent f0 / f1 — prepend / append: varuint lungime + atâția bytes la mesaj ff — fork: ramurile se serializează consecutiv
Tag-uri de attestation pe care le vei întâlni aici:
0588960d73d71901 — BitcoinBlockHeader: payload-ul este
doar un varuint cu block height-ul (NU un block header de 80 bytes — header-ul nu mai este
inclus din OTS 1.0 încoace). Coroborezi height-ul cu un explorer public
(mempool.space/api/block-height/<h> → hash, apoi /api/block/<hash> → timestamp).83dfe30d2ef90c8e — PendingAttestation: payload-ul este URI-ul calendarului
care a primit digestul. Înseamnă SUBMITTED, în așteptarea confirmării (normal <24h) — nu e o eroare.Atenție la re-interogare: GET /timestamp/<digest> pe calendarele OTS
publice întoarce 404 chiar și pentru digesturi reale deja trimise (calendarele nu servesc proof-uri la cerere).
Verificarea se face exclusiv din fișierul proof .ots publicat alături de registru, nu prin
re-interogarea calendarului.
Ce NU poate face nimeni — nici salonul, nici platforma: să șteargă sau să editeze o recenzie, să ascundă recenzii negative, să rescrie istoricul, să rotească cheile fără detectare sau să prezinte un ledger alternativ (root-ul de rețea e ancorat extern pe 3 calendare). Ce nu poate încă nimeni verifica: datele economice declarate de salon (plăți, recurență) și independența operatorului de rețea — rețeaua este un pilot operat de Primer, cu saloane demo; spunem asta explicit, nu o mascăm.