SituaRadar — Help & FAQ

Introduzione & Come iniziare

Qui trovi risposte pratiche e spiegazioni oneste su SituaRadar: cosa è, cosa non è, come usarlo e come contribuire.

• Che cos'è SituaRadar?
  SituaRadar è una mappa partecipativa: una piattaforma che segnala eventi, incontri, iniziative culturali e momenti politici che sfuggono ai canali istituzionali e ai feed algoritmici. È pensata per essere autonoma, non profili gli utenti e renda visibili i moti dal basso della città.
• Devo registrarmi per usare la mappa?
  No. Per consultare la mappa non serve registrazione — la fruizione è anonima e libera. La registrazione è richiesta solo per alcune azioni (es. pubblicare eventi, modificare aree se la policy lo richiede, salvare eventi lato server).
• Qual è la filosofia di SituaRadar rispetto alla privacy?
  Minimizzazione dei dati: raccogliamo il minimo indispensabile. Non facciamo profiling, né tracciamento pubblicitario. Le policy sono pubbliche nella Privacy Policy; in generale: niente tracciamento esterno, niente profilazione, salvataggi locali per i "saved".

Come funziona la mappa

• Quali tipi di punti vedo sulla mappa?
  Punti che rappresentano eventi (concerti, reading, assemblee, mostre ecc.), e — in futuro — aree/poligoni. Alcuni punti sono pubblici; altri sono segnati come segreti (richiedono codice).
• Cosa significa "hype"?
  L'hype è un conteggio locale che misura l'interesse: ogni click/salvataggio su un evento incrementa il valore visuale. Non dipende da algoritmi esterni: è una misura collaborativa del coinvolgimento.
• Come sono visualizzati gli eventi segreti?
  Gli eventi con `codice_hash` (o contrassegnati come segreti) non sono visibili normalmente: possono comparire solo dopo aver inserito il codice corretto nella UI dedicata. La logica lato client chiede il codice, calcola lo sha256 e lo invia per verificare corrispondenza (la verifica è fatta server-side per sicurezza).

Ruoli: Organizer / Explorer

• Qual è la differenza tra Organizer e Explorer?
  Due ruoli minimali pensati per chiarezza operativa:

  • Organizer: può creare eventi, modificarli e (se policy lo prevede) gestire contenuti del proprio spazio. Di solito chi mette eventi pubblici/privati.
  • Explorer: utente che naviga, salva eventi, interagisce con hype, partecipa ma non necessariamente pubblica. Ha accesso limitato alle operazioni protette.
• Come viene assegnato il ruolo?
  Al momento il ruolo può essere fornito come `user_metadata.role` al momento della registrazione o impostato successivamente tramite il profilo. Il server (RPC `ensure_profile_current`) allinea il profilo alla `user_metadata` quando l'utente accede. Gli amministratori possono anche assegnare ruoli dal DB, ma la prassi raccomandata è autotutela del progetto e assegnazione su richiesta verificata.

Creare un evento — guida rapida

• Dove compilo il form per pubblicare un evento?
  C'è una pagina `form.html` accessibile dal pulsante “+ Aggiungi” nella barra. Organizer: aprite la pagina, compilate titolo, descrizione, data/ora, categoria, e (opzionale) codice per evento segreto. Il form invia al DB `eventi` (colonna `codice_hash` per i segreti).
• Posso inserire eventi segreti?
  Sì. Se vuoi che l'evento sia nascosto fino alla condivisione del codice, inserisci un codice nel form: il client calcola lo sha256 e il DB conserva solo l'hash (`codice_hash`). Solo chi inserisce lo stesso codice vedrà l'evento. Non condividere codici pubblicamente se desideri riservatezza: passali a voce o DM.
• Cosa devo sapere sull'affidabilità dei dati?
  SituaRadar non verifica a priori i contenuti: la responsabilità dei dati (orario, luogo, descrizione) resta di chi pubblica. Abbiamo strumenti di segnalazione e moderation (vedi sezione Moderation) per rimuovere contenuti illegali o pericolosi.

Eventi segreti — dettagli tecnici e pratici

• Come è implementato il meccanismo dei codici?
  Tecnica sintetica: il client raccoglie il codice — es. `neon47` — calcola `sha256(code)` e lo invia (o lo confronta) con i record che contengono `codice_hash`. Il DB non conserva il codice in chiaro: solo hash. Questo è il pattern più sicuro per eventi di tipo "invite-only".
• Se perdo il codice, posso recuperare l'evento?
  No. Se il codice non è memorizzato da te, il DB non può rivelarlo (viene memorizzato solo l'hash). Contatta l'organizzazione che ha fornito l'evento per ottenerlo: per ragioni di sicurezza e privacy il progetto non mette a disposizione una "backdoor".

Saved events e Hype (UX)

• Come salvo un evento?
  La fiamma / icona "salva" mantiene gli eventi nello storage locale del tuo browser (localStorage) per rispetto della privacy. È una salvezza lato client: se vuoi copie server-side usa la funzione "Saved events" del profilo (richiede login e policy server-side).
• Perché vedo numeri 0/0 nel counter?
  Il counter dell'interfaccia è legato alla lista di eventi attualmente “visibili” (filtro + tempo + ricerca). Se appare 0/0 significa che il badge è presente ma la fonte dati per il conteggio non è stata aggiornata. In pratica: la funzione che pubblica gli eventi renderizzati (hook `window.publishVisible`) deve essere chiamata dopo il rendering dei marker. Se c'è un bug, controlla che `window.srNotifyRendered` (o la funzione che ascolta) sia disponibile e riceva l'array di eventi.
• L'hype è manipolabile?
  Il contatore di hype è locale e serve come metrica sociale. Per evitare abusi, la versione server-side può memorizzare un unico "like/hype" per utente per evento (`event_hype`), e RLS/validazioni prevengono insert massivi. Se vuoi una metrica condivisa, la logica server deve contare una singola voce per utente (vedi tabella `event_hype` nello schema DB consigliato).

Sicurezza, esposizione chiavi e come metterle al sicuro

• Le chiavi Supabase sono nel codice — è pericoloso?
  Sì: se trovi `service_role` o altre chiavi privilegiate nel frontend, revoca immediatamente la chiave in console Supabase e rigenera. La service_role non deve mai essere esposta; la anon key è pensata per il client ma va gestita con attenzione. Vedi sotto per la procedura operativa.
• Come mettere le chiavi al sicuro (passi pratici)?
  1. Rimuovi da tutti i file le chiavi hardcoded.
  2. Genera file `env.js` al build o usa environment variables del provider (Netlify / Vercel) per iniettare `SUPABASE_URL` e `SUPABASE_ANON_KEY` al momento del deploy.
  3. Non inserire `service_role` nel client: tienila in serverless function.
  4. Se una chiave è stata esposta pubblicamente, rigenera/ruotala subito in Supabase e aggiorna il deploy.
  5. Se la chiave è finita nella storia Git pubblica, valuta `BFG` o `git filter-repo` per rimuoverla dalla storia (operazione distruttiva: coordinare con i collaboratori).
• Segnalare una vulnerabilità o leak?
  Scrivi subito a situaradar@proton.me con oggetto "Security disclosure" e una descrizione precisa. Se preferisci, puoi allegare PoC o sample (meglio non includere segreti in mail non cifrate: usa PGP o ProtonMail come canale sicuro).

Per sviluppatori — architettura e punti critici

• Dove si inizializza Supabase nel progetto?
  Centralizza l'inizializzazione in un unico file (es. `init-supabase.js`) che legge `window.env` (o `import.meta.env` se usi bundler). Evita duplicati di `createClient` in più file (index, profile, user) — questo riduce errori e confusione su chi mantiene lo stato della connessione.
• Quali RPC / funzioni DB sono importanti?
  `ensure_profile_current` — funzione RPC che crea/aggiorna il profilo dall'utente autenticato (prende ruolo da `user_metadata`). È utile per allineare `profiles` senza esporre logiche client complesse. Usala all'accesso: `await supabase.rpc('ensure_profile_current')`.
• Row Level Security (RLS): cosa mettere?
  Esempi pratici:

  • Profiles: SELECT/UPDATE solo se `user_id = auth.uid()` (ogni utente vede e modifica il proprio profilo).
  • Eventi: SELECT pubblico per `codice_hash IS NULL` (eventi pubblici); SELECT owner per `created_by = auth.uid()` (leggi i tuoi segreti); INSERT/UPDATE/DELETE solo se ruolo = 'organizer' e `created_by = auth.uid()`.

  Queste regole limitano i rischi e mantengono separazione dei privilegi.
• Hook centralizzati per UI (marker counter)?
  Se non vuoi modificare ogni funzione, puoi attivare un hook centrale: nell'ultima riga della funzione che renderizza i marker (`renderMarkers(arr, opts)` o equivalente) inserisci:

  window.publishVisible = function(events){ window.SR_CURRENT_EVENTS = events || []; if (typeof window.srNotifyRendered === 'function') window.srNotifyRendered(events || []); }

  Questo pubblica la lista visibile affinché il badge tondo (counter) la legga e si aggiorni dinamicamente.

Deploy, env.js e Netlify (guida rapida)

• Come iniettare le chiavi con Netlify?
  Imposta le environment variables nel pannello Netlify (Site → Settings → Build & deploy → Environment). Aggiungi uno script in build che genera `public/env.js`:

  echo "window.env = { SUPABASE_URL: '$SUPABASE_URL', SUPABASE_ANON_KEY: '$SUPABASE_ANON_KEY' };" > ./public/env.js

  Poi includi `` prima del resto degli script: così il client legge `window.env` senza commettere chiavi nel repo.
• Cosa fare dopo aver rotto/commesso una chiave per errore?
  1) Rigenera la chiave in Supabase; 2) aggiorna l'env sul deploy provider; 3) rimuovi il valore dai file e committa; 4) (opzionale) pulisci la storia git se la chiave è stata pubblicata in repo pubblico.

Mobile, PWA e icone home

• Posso aggiungere SituaRadar sulla home dell'iPhone?
  Sì: assicurati di avere `manifest.json` e icone `apple-touch-icon`. Poi apri la pagina su Safari e scegli "Aggiungi a Home". Per una PWA vera aggiungi `service-worker.js` e `manifest.json` nella root e configuri il `scope` corretto.
• Quanto lavoro serve per trasformare SituaRadar in app mobile?
  Due strade:

  • Wrapper WebView (Cordova/Capacitor): 1–2 settimane per packaging, testing mobile e fix UX.
  • Applicazione nativa con sincronizzazione offline e notifiche push: 6–12 settimane a seconda delle feature (profilo, notifiche, offline sync, auth avanzata).

Usare JOSM e strumenti GIS

• Cos'è JOSM e a che serve per SituaRadar?
  JOSM è un editor avanzato per i dati OpenStreetMap. Per SituaRadar può servire a:

  • Preparare shapefile o GeoJSON di aree predefinite (quartieri, punti di interesse) che poi importi in SituaRadar.
  • Pulire geometrie, semplificare poligoni e verificare proiezioni (usate WGS84/4326 per il web).
• Posso importare aree create in JOSM nella mappa?
  Sì: esporta in GeoJSON (coordinate WGS84), poi usa lo strumento di import o una endpoint amministrativa per inserirle in `areas` come `geom_geojson`. Verifica sempre semplificazione e topologia (no self-intersections).

Moderation, rimozione e segnalazioni

• Come segnalo un evento pericoloso o illegale?
  Usa l'indirizzo situaradar@proton.me con oggetto "Segnalazione evento" e allega:

  • Screenshot / link
  • Motivazione chiara
  • Eventuali prove (foto, orari)

  Il team valuterà la rimozione urgente se l'evento viola norme di sicurezza pubblica o leggi. In casi estremi si collabora con le autorità competenti (solo quando obbligatorio).
• Chi decide la rimozione?
  La rimozione è gestita dal team/volontari di SituaRadar in base alle policy pubbliche: violazioni legali, minacce, rischio per la sicurezza. Per dubbi e appelli usa lo stesso indirizzo email: la discussione è trasparente e documentata.

Contatti e contributi

• Come contatto il team?
  Email: situaradar@proton.me. Puoi anche proporre collaborazioni, segnalare bug o inviare materiale da pubblicare (immagini, locandine, testi).
• Voglio contribuire: codice, grafica o moderazione. Come faccio?
  Scrivi all'email con oggetto "Contributo" specificando il tipo (dev/frontend/backend/moderazione). Per sviluppatori: apri una PR su repo (se disponibile) o invia patch via email. Documenta le modifiche e usa branch separati per evitare conflitti.