In sviluppo
CloudX Remote
Desktop remoto a bassa latenza con trasporto proprietario cifrato.
Il problema
I prodotti di remote desktop esistenti impongono il loro protocollo, il loro account e il loro prezzo. Serviva la stessa reattività, con il controllo di ogni livello e senza dipendere da un servizio di terzi.
Vincoli
- Latenza: il tempo tra input e pixel è la metrica che conta, non il bitrate.
- Un ambiente headless: serve un monitor virtuale che non esiste fisicamente.
- Superficie ridotta: una sola porta UDP, un solo handshake.
- Driver firmati: il display virtuale deve passare la firma, non aggirarla.
Architettura
- Core nativo per piattaforma con API C comune: core.dll su Windows, core.dylib su macOS.
- Handshake X25519 effimero, identità Ed25519, pairing via SAS; payload ChaCha20-Poly1305.
- Multiplex di tutti i canali su una singola porta, con controllo di congestione dedicato.
- Driver di display virtuale user-mode IddCx, alternativo ai prodotti commerciali equivalenti.
Decisioni che contano
Un trasporto, non sei socket
Video, audio, input e clipboard condividono lo stesso tubo cifrato. Un canale in più non apre una porta in più e non aggiunge un handshake da difendere.
GStreamer oggi, path proprietari dopo
La pipeline media parte da GStreamer per arrivare presto a un prodotto misurabile; i path diretti NVENC/DXGI e VideoToolbox/Metal sono il passo successivo, non il prerequisito.
Dove è arrivato
Core, driver e client funzionanti in sviluppo; il banco di misura è la parte costruita prima delle ottimizzazioni.