Glaia è il mio progetto desktop per organizzare più servizi di intelligenza artificiale web in un unico ambiente. Nasce da un problema concreto: troppe schede, accessi ripetuti e strumenti sparsi nel browser. L’obiettivo è dare ordine al lavoro con l’IA, mantenendo separata questa attività dalla navigazione abituale.
Nel video presento l’applicazione, ne mostro l’interfaccia e spiego le scelte progettuali. È importante partire dal suo perimetro: Glaia raccoglie servizi web in un contenitore dedicato; non trasforma quei servizi in modelli eseguiti offline e non modifica le condizioni con cui i rispettivi fornitori trattano i dati.
Il problema da cui sono partito
Quando uso più strumenti di IA, finisco facilmente per distribuire il lavoro tra finestre, schede e accessi differenti. Ritrovare il servizio giusto diventa una piccola interruzione ripetuta molte volte.
Ho quindi immaginato uno spazio stabile, con un elenco dei fornitori e una sessione dedicata per ciascuno. Non volevo sostituire ogni funzione del browser, ma creare un ambiente riconoscibile in cui tornare quando lavoro con quei servizi.
Il nome Glaia richiama Aglaia, un riferimento mitologico che cito nella presentazione. Il progetto nasce comunque da un’esigenza molto pratica: sono io stesso tra i primi utilizzatori dell’applicazione.
Una barra laterale per scegliere il servizio
L’interfaccia mostrata nel video presenta un catalogo di fornitori nella barra laterale. Selezionandone uno, si apre il relativo servizio web; l’utilizzo effettivo può richiedere l’accesso con un account e rimane soggetto ai limiti del fornitore.
I controlli di navigazione richiamano quelli di un browser: permettono di tornare indietro, ricaricare o aprire la pagina esternamente quando serve. L’intento è ridurre l’attrito senza chiedere di imparare un’interazione completamente nuova.
Sono inoltre presenti opzioni per tema chiaro o scuro, lingua italiana o inglese e riduzione delle animazioni. Queste scelte appartengono all’esperienza dell’applicazione, non cambiano automaticamente lingua o comportamento di ogni sito caricato.
Catalogo personalizzabile ed esportazione
Nel video mostro la possibilità di aggiungere, modificare e rimuovere fornitori. Non voglio imporre che tutti usino lo stesso insieme di strumenti: il catalogo deve adattarsi al modo di lavorare della persona.
La configurazione dei fornitori può essere importata ed esportata in JSON. Questo aiuta a trasferire l’organizzazione dello spazio di lavoro tra computer.
Va però distinta la configurazione dall’insieme dei dati dei servizi. Esportare il catalogo non significa esportare automaticamente conversazioni, password o ogni preferenza conservata da un fornitore remoto. Se serve trasferire quei materiali, bisogna verificare le funzioni previste dal relativo servizio.
Che cosa significa local-first in questo progetto
Uso l’espressione local-first per descrivere la gestione locale delle impostazioni e dell’ambiente desktop. Nella presentazione dichiaro l’assenza di un backend proprietario di Glaia e di telemetria dell’applicazione.
Non significa però assenza di comunicazioni verso Internet. Se carico un chatbot web e gli invio una richiesta, il servizio remoto deve ricevere ciò che serve a elaborarla. Il suo account, le sue regole di conservazione e le sue eventuali opzioni sull’addestramento rimangono rilevanti.
Per questo è più preciso dire che Glaia organizza l’accesso ai servizi, invece di promettere che nessun dato venga mai condiviso con loro. Chi cerca un modello completamente locale sta cercando un’altra categoria di soluzione.
Sessioni separate e controlli locali
Il progetto prevede sessioni persistenti separate per i fornitori. L’obiettivo è mantenere continuità d’uso e distinguere i dati locali dei diversi servizi da quelli della navigazione abituale.
Nel video mostro anche un ripristino selettivo: cancellare cookie, cache o archiviazione locale di un fornitore senza intervenire nello stesso modo sugli altri. È utile quando si vuole ripartire da una sessione pulita o risolvere un problema circoscritto.
Questa operazione riguarda i dati gestiti localmente dall’applicazione. Non cancella automaticamente conversazioni o informazioni conservate sui server del fornitore e può richiedere un nuovo accesso.
Anche l’avviso mostrato da un servizio durante la dimostrazione va interpretato con prudenza. Un ambiente incorporato può essere riconosciuto come insolito o non pienamente supportato; l’avviso, da solo, non dimostra un tentativo di tracciamento illecito.
Le scelte tecniche dietro l’interfaccia
Nella presentazione descrivo un’applicazione costruita con Electron e React, strumenti di sviluppo basati su npm, electron-vite per il progetto ed electron-builder per il confezionamento. Richiamo inoltre Zod per validare configurazioni e contratti di comunicazione.
L’interfaccia, il codice di preload e il processo principale comunicano attraverso un livello IPC, cioè un meccanismo di comunicazione tra processi. Nel progetto ho posto attenzione alla separazione dei contesti e alla disattivazione dell’integrazione Node.js nelle pagine dei fornitori.
Sono scelte coerenti con i temi trattati nella documentazione di sicurezza di Electron. Non costituiscono però, da sole, la prova che l’applicazione sia invulnerabile: contano anche aggiornamenti, dipendenze, permessi e implementazione.
La metafora della “bolla”, usata nel video, serve a spiegare l’isolamento. Non va interpretata come anonimato garantito, blocco di ogni comunicazione esterna o impossibilità assoluta di raggiungere risorse locali attraverso qualsiasi percorso. La sicurezza deve essere valutata sul codice e sulla versione effettiva.
Privacy, accessibilità e limiti delle dichiarazioni
Voglio un’applicazione comprensibile, con controlli espliciti e attenzione all’accessibilità. Nella presentazione richiamo anche le linee guida WCAG e la protezione dei dati.
Questi sono obiettivi progettuali. Non presento il video come una certificazione indipendente di conformità al GDPR, né come una verifica completa di accessibilità. La conformità non deriva automaticamente dall’uso di Electron, dal codice aperto o dalla sola presenza di una sandbox.
Allo stesso modo, non considero tutte le applicazioni web create con altri strumenti prive di protezioni. Per confrontare soluzioni diverse bisogna guardare a sessioni, permessi, implementazione e manutenzione, non soltanto all’etichetta utilizzata.
Licenza aperta e contributi della community
Presento Glaia come software distribuito sotto AGPLv3. La licenza GNU Affero General Public License v3 contiene obblighi sul codice sorgente nelle condizioni previste, compreso il caso di versioni modificate con cui gli utenti interagiscono da remoto attraverso una rete.
Non introduce un obbligo generale di chiedermi il permesso o di avvisarmi per ogni utilizzo. Chi vuole riusare o modificare il progetto deve leggere e rispettare la licenza applicabile, distinguendo uso, distribuzione e modifiche.
Nel video richiamo il gruppo di test di Boost Media e la distribuzione attraverso gli strumenti di Ufficio Zero Linux. Invito a segnalare problemi e a contribuire: un’applicazione aperta migliora anche grazie a descrizioni riproducibili degli errori, proposte e lavoro di manutenzione.
Dove trovare Glaia e come valutarlo
Il riferimento per codice, documentazione e versioni pubblicate è il repository ufficiale di Glaia su GitHub. Nella presentazione cito pacchetti per Linux e disponibilità multipiattaforma; prima di scaricare va verificato l’artefatto effettivamente pubblicato per il proprio sistema.
La provenienza del file rimane importante anche per un progetto gratuito. Un avviso relativo alla firma non dimostra da solo che il programma sia dannoso, ma non va neppure ignorato automaticamente.
La domanda con cui propongo di provarlo è concreta: organizzare i fornitori in uno spazio dedicato migliora davvero il proprio lavoro? Glaia nasce per rispondere a questo bisogno. Segnalazioni, contributi e sostegno possono aiutarmi a mantenerlo nel tempo, senza trasformare la presentazione in una promessa di supporto illimitato o di sicurezza assoluta.