RFC: Request for Comments (HOLogram)

Le RFC sono documenti tecnici concisi che descrivono proposte di cambiamento al protocollo HOLogram e all’ecosistema (HLP, HCT, RI semantica, HRL/HCS)

L’obiettivo è evolvere lo standard con trasparenza, merito e verificabilità

Ambito delle RFC

Una RFC può proporre:

  • HLP: semantica dei moduli (Input Vault, Normalizer, Persona Mixer, DP Engine, Privacy Budget, HUD), requisiti, limiti, interoperabilità
  • HCT: nuovi test di conformità, soglie, metodologie di verifica
  • RI (Reference Implementation): implicazioni semantiche (non il codice), allineamento alla specifica
  • HRL/HCS: regole reputazionali non finanziarie (criteri, pesi, badge)
  • Processo/Governance: miglioramenti al flusso RFC e al ciclo di rilascio

Fuori ambito: richieste puramente implementative “di codice” (aprire PR nel repo RI), bug minori del sito

Stati di una RFC

  • Draft — proposta iniziale, pronta per essere discussa
  • Review — in revisione tecnica (commenti, modifiche)
  • Accepted — approvata per l’inclusione (in attesa di integrazione/rilascio)
  • Rejected — non accettata (motivazioni tracciate)
  • Final — integrata nello standard (HLP/HCT/Policy aggiornate)
  • Superseded — superata da una nuova RFC (con riferimento incrociato)

Numerazione e formato

  • ID: RFC-YYYY-NNN (es. RFC-2026-001) in ordine di approdo a Review
  • Titolo: descrittivo e conciso
  • Sezioni minime: Motivazione, Specifica proposta, Impatto su HLP/HCT/RI/HRL, Compatibilità, Sicurezza, Esempi/Test, Migrazione, Rischi
  • Linguaggio: usare RFC‑2119 (MUST, SHOULD, MAY) per requisiti normativi
  • Lunghezza: 1–5 pagine (salvo allegati tecnici)

Processo (end‑to‑end)

  1. Proposta iniziale
    • Fork del repo hologramprotocol/rfc
    • Aggiungi file RFC-YYYY-NNN.md in /rfc/drafts/
    • Apri una Pull Request con etichetta rfc:proposal
  2. Discussione & Review
    • Commenti pubblici
    • Revisione tecnica da ≥ 2 reviewer (almeno 1 con ruolo sicurezza se tocca DP/Privacy)
    • Possibile call tecnica dedicata
  3. Esito
    • Accepted → pianificazione integrazione in HLP/HCT/Policy
    • Rejected → motivazioni documentate
  4. Integrazione
    • Allineamento HLP (o note di chiarimento)
    • Aggiornamento HCT (test minimi)
    • Eventuale nota in RI (semantica)
    • Changelog pubblico
  5. Chiusura
    • Stato Final e pubblicazione in /rfc/final/
    • Se sostituita da nuova RFC: Superseded

Criteri di accettazione (decisione tecnica)

Una RFC viene accettata se:

  • migliora la protezione della biometria comportamentale (riduzione riconducibilità)
  • mantiene naturalità e funzionalità
  • rispetta local‑only & zero‑retention
  • non introduce manipolazione dell’utente
  • definisce chiaramente impatti su HLP/HCT/RI/HRL
  • include test o metrica di verifica (anche proposta)
  • non crea regressioni note sulla compatibilità
  • è sostenuta da revisione tecnica sufficiente

Compatibilità & Migrazioni

Ogni RFC deve indicare:

  • Compatibilità: retrocompatibilità o breaking change
  • Migrazione: passaggi minimi per portarsi alla nuova versione (parametri, soglie, naming)

Sicurezza & Privacy

Indicare rischi e mitigazioni:

  • possibilità di fingerprinting dell’offuscamento
  • effetti collaterali su anti‑bot/UX
  • interazione con DP Engine / Privacy Budget
  • impatti sugli ambienti ad alta sensibilità

Relazione con HOLoToken (HRL/HCS)

Le RFC non sono “bounty”

Tuttavia, contributi tecnici sostanziali (proposta + test + integrazione) possono riflettersi nel profilo reputazionale HCS (dimensioni: security, core, docs, QA), secondo policy pubbliche della community

Dove proporre / discutere

  • RFC repository (Pull Request): https://github.com/hologramprotocol/rfc
  • Discussioni: sezione Discussions/Issues del repo RFC
  • Security‑touching RFC: coordinarsi prima con security@hologramprotocol.org
Torna alla Home