richlegrand/bitbang-cliStabilisci un accesso remoto sicuro a una macchina con shell interattiva, trasferimento file e proxy web tramite WebRTC peer-to-peer crittografato end-to-end, usando un browser o CLI senza inoltro di porte o account.
# BitBang CLI
[](https://github.com/richlegrand/bitbang-cli/actions/workflows/tests.yml)
`bitbang` è un multitool per l'accesso remoto distribuito come singolo binario statico. Da qualsiasi browser: accesso tramite shell interattiva e file browser alla macchina remota. Puoi anche raggiungere le web app presenti sulla rete di quella macchina. Oltre al browser, offre port forwarding TCP, copia di file e condivisione del terminale. Non richiede account né configurazione -- funziona e basta.
Sulla macchina che vuoi raggiungere:
```
curl -sSfL bitba.ng/install | sh
bitbang serve
```
`serve` stampa un URL. Aprilo in qualsiasi browser e ottieni un terminale, un file browser e un proxy verso la rete di quella macchina -- oppure raggiungi la stessa macchina da un altro terminale con `bitbang connect <url>`, che aggiunge il port forwarding (`-L`) e la copia dei file (`bitbang cp`). La connessione è cifrata end-to-end e peer-to-peer; il server `bitba.ng` introduce le due estremità, poi si fa da parte.
`bitbang` è un singolo binario Go statico. Fa parte del [progetto BitBang](https://github.com/richlegrand/bitbang); questo [whitepaper](https://github.com/richlegrand/bitbang/blob/main/whitepaper.md) illustra il design in dettaglio.
## Come si confronta
| | ngrok | Tailscale | `bitbang` |
| ------------------------------ | ---------------------- | ------------------------------ | ------------------- |
| Configurazione prima del primo utilizzo | Account + authtoken | Account + login su ogni dispositivo | **Esegui un solo comando** |
| Per condividere qualcosa, esegui | un web server, più ngrok | il loro client su entrambe le macchine | **`bitbang serve`** |
| Cosa ottiene un browser all'altro capo | il web server che stavi già eseguendo | nulla -- richiede il loro client | **un terminale, un file browser e le web app sulla rete remota** |
| Percorso dei dati | i loro server | P2P (fallback su relay) | **P2P (fallback su relay)** |
| Cifratura end-to-end | Non di default | Sì | **Sì** |
## Ricette rapide
**Raggiungere un servizio a casa**
- [Monta il tuo NAS di casa da qualsiasi luogo (SMB)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#mount-your-home-nas-from-anywhere-smb)
- [Guarda la tua libreria multimediale da qualsiasi luogo (Jellyfin)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#watch-your-media-library-from-anywhere-jellyfin)
- [Usa il tuo LLM da qualsiasi luogo (Ollama, Open WebUI)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#use-your-own-llm-from-anywhere-ollama-open-webui)
- [Controlla le tue telecamere di sicurezza (Frigate)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#check-your-security-cameras-frigate)
- [Raggiungi la tua domotica senza esporla (Home Assistant)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#reach-your-home-automation-without-exposing-it-home-assistant)
- [Stampa sulla tua stampante di casa (IPP, CUPS)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#print-to-your-home-printer-ipp-cups)
**Accedere a una macchina**
- [Ottieni una shell su una macchina dietro NAT](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#get-a-shell-on-a-machine-behind-nat)
- [Ottieni una shell dal tuo telefono](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#get-a-shell-from-your-phone)
- [Desktop remoto su una macchina Windows (RDP)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#remote-desktop-into-a-windows-machine-rdp)
- [Raggiungi un desktop Linux o Mac (VNC)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#reach-a-linux-or-mac-desktop-vnc)
- [SSH verso una macchina senza porte aperte (OpenSSH)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#ssh-to-a-machine-with-no-open-port-openssh)
- [Configura un Raspberry Pi headless](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#set-up-a-headless-raspberry-pi)
**Condividere con qualcun altro**
Condividere significa semplicemente fornire a qualcuno un URL univoco o un codice QR che gli dia accesso. I permessi possono essere personalizzati e impostati per scadere in minuti, ore, ecc.
- [Condividere file senza caricarli da nessuna parte](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#share-files-without-uploading-them-anywhere)
- [Mostrare il tuo progetto a qualcuno](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#show-someone-your-project)
- [Mostrare a qualcuno l'errore su cui sei bloccato](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#show-someone-the-error-you-are-stuck-on)
- [Concedere a qualcuno un accesso che scade](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#give-someone-access-that-expires)
- [Controllare la sessione del tuo agente dal telefono (Claude Code, tmux)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#check-your-agent-session-from-your-phone-claude-code-tmux)
- [Sistemare il router di qualcun altro](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#fix-someone-elses-router)
**Sviluppo e dispositivi**
- [Raggiungere un database dalla tua macchina di sviluppo (Postgres, MySQL)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#reach-a-database-from-your-dev-machine-postgres-mysql)
- [Sincronizzare dispositivi che non riescono a trovarsi (Syncthing)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#sync-devices-that-cannot-find-each-other-syncthing)
- [Osservare un robot da un browser (ROS, Foxglove)](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#watch-a-robot-from-a-browser-ros-foxglove)
**Tecniche**
- [Cosa espone un listener di inoltro](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#what-a-forwarding-listener-exposes)
- [Consentire ad altre macchine sulla tua LAN di usare un inoltro](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#let-other-machines-on-your-lan-use-a-forward)
- [Casi noti per non funzionare](https://github.com/richlegrand/bitbang/blob/main/cookbook.md#known-not-to-work)
## Usare `bitbang`
Ogni connessione ha due estremità: un **listener** (`bitbang serve`, in esecuzione sulla macchina che viene raggiunta) e un **connector** (un browser, oppure la CLI `bitbang`, sulla macchina che effettua il collegamento). Un unico URL del listener serve entrambi i tipi di connector.
### Il listener: `bitbang serve`
```
bitbang serve # everything: shell + proxy + files + forward
bitbang serve shell # just a terminal
bitbang serve files ~/share # just a directory (-files-upload to allow uploads)
bitbang serve proxy localhost:8080 # just one web app, straight at the URL
bitbang serve proxy a.lan:80,b.lan:80 # ...or several, chosen in the browser
bitbang serve forward 127.0.0.1:22 # just TCP, for `connect -L`
bitbang serve shell files ~/share proxy nas.lan:8096 # any combination
```
Ognuno stampa un codice QR, un URL e un codice di accoppiamento. La modalità determina ciò che il listener può fare in assoluto: `serve shell` non ha alcun forwarding da concedere, e un listener di solo forwarding non avvia mai una shell, quindi non c'è nulla a cui escalare.
Un valore predefinito che vale la pena conoscere: **il forwarding e il proxy raggiungono qualsiasi host:porta che il listener può raggiungere**, non solo quello che avevi in mente, quindi un link distribuito per un database raggiunge anche il resto di quella rete. Assegnare un nome ai target dopo la parola lo restringe -- `forward db.internal:5432` raggiunge quello e nient'altro.
### Condividere una sessione in esecuzione: `bitbang share`
`serve shell` avvia una nuova shell. `share` pubblica una sessione tmux già in esecuzione:
```
bitbang share # publish the current tmux session
bitbang share --read-only # publish without a control URL
bitbang share status|stop|rotate
```
Il comando ritorna dopo la pubblicazione, quindi `Ctrl-Z`, `bitbang share`, `fg`
funziona per un'attività già in corso. L'hosting richiede tmux 3.2+ su Unix o
WSL. I client Windows nativi possono aprire gli URL ma non possono ospitare una condivisione.
Per impostazione predefinita, il comando stampa due URL bearer:
- L'**URL di controllo** può digitare con la stessa autorità della tastiera locale.
Un solo controller può connettersi alla volta.
- L'**URL di visualizzazione** è solo per l'osservazione. L'input viene scartato prima di raggiungere tmux, e
fino a `--max-viewers` visualizzatori possono connettersi contemporaneamente (predefinito 16).
`--read-only` omette completamente la credenziale di controllo. I limiti di
visualizzatori e controller sono mantenuti per tutta la durata di ciascuna connessione, anche prima che apra una shell.
Le condivisioni rimangono attive fino all'arresto per impostazione predefinita; `--ttl` imposta una durata (ad es. `--ttl 1h`).
Gli URL di condivisione sono effimeri e non vengono mai salvati in `devices.json`. `share stop`,
la scadenza del TTL o la rimozione della sessione sorgente disconnettono i peer remoti senza
arrestare la sessione sorgente.
Eseguire nuovamente `bitbang share` ristampa gli URL della condivisione in esecuzione. Se si
passa un flag in disaccordo con ciò che è in esecuzione (ad esempio `--read-only`
contro una condivisione che ha un URL di controllo), lo segnala invece di
restituire i vecchi URL; `bitbang share rotate` sostituisce la condivisione
con una che utilizza i nuovi flag.
Un worker in background viene eseguito in una sessione di gestione tmux `_bbshare_*` scollegata,
quindi non c'è alcun daemon o file PID da gestire.
La condivisione non modifica alcuna opzione di tmux. Con `window-size latest` predefinito di tmux, la
finestra segue il client attivo in lettura-scrittura; un visualizzatore solitario fornisce comunque
l'unica dimensione disponibile. Se `window-size` è stato sovrascritto, `share` lo segnala
ma non modifica la configurazione dell'utente.
### Distribuire accesso limitato: `bitbang link`
Un listener, un URL e tutti i **link di accesso** di cui hai bisogno. Ognuno è un
codice separato su quello stesso URL, che concede un sottoinsieme di ciò che il listener offre
e facoltativamente scade a un orario fisso:
```
bitbang link edit # add entries in $EDITOR
bitbang link ls # what you have handed out
bitbang link rm <label> # revoke one
bitbang link qr <label> # its URL and QR code
```
Una voce è una riga di JSON in `~/.bitbang/bitbang/links.json`. Scrivine una senza
codice, ricarica il listener dalla sua console, e ne genera una:
```json
[
{"label": "ana", "grant": "files", "expires": "2026-09-01T00:00:00Z"},
{"label": "ben", "grant": "files /srv/photos"},
{"label": "dev", "grant": "shell forward 127.0.0.1:5432"}
]
```
```
0) owner files forward proxy shell
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#_vtQ0JCPe7s
1) ana files expires in 6d
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#T-Ty_HhvLfY
2) ben files /srv/photos
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#L6La8OzBO74
3) dev forward 127.0.0.1:5432 shell
https://bitba.ng/8ach_I7oQk2vBb9xYzT0Lw#8kmI3LYzB7E
```
`owner` è il codice dell'identità stessa e concede tutto ciò che il listener serve; invia
uno degli altri invece. La console accetta sia l'etichetta che il numero accanto
ad essa, quindi `rm 2` e `rm ben` fanno la stessa cosa.
Un `grant` è scritto con le parole che accetta `serve`, e può solo restringere ciò che il
listener già serve. Ciò significa che un link non è limitato a scegliere capacità:
può indicare una sottodirectory della cartella condivisa, un sottoinsieme dei target di forward, o
un singolo comando per `shell`. Ometti `grant` e il link concede qualunque cosa faccia il listener.
Chiedi qualcosa al di fuori della portata del listener e la console lo rifiuta con
lo stesso messaggio che ti darebbe `serve`.
L'etichetta è ciò che identifica un link, non i suoi termini, quindi due persone possono avere link
con grant e scadenza identici e puoi comunque revocarne uno senza toccare
l'altro.
La revoca e la scadenza raggiungono le sessioni già aperte: la connessione si chiude
e al titolare viene detto il motivo, invece di restare in silenzio. E un codice scaduto viene
ritirato anziché messo in pausa -- rinnovare una voce ne genera una nuova, quindi l'URL che
hai già inviato resta morto.
### Pairing con un codice a 6 cifre
Quando non puoi incollare un URL o scansionare un codice QR, come quando sei al telefono, o a portata di voce, `bitbang serve` stampa anche un breve **codice di pairing**. L'altra parte apre `bitba.ng/<code>` (o esegue `bitbang connect <code>`), il suo schermo mostra un secondo numero a 6 cifre, e loro ti rileggono *quello*. Tu lo digiti per approvare. Un machine-in-the-middle non può far coincidere i due numeri, e il pairing salva le credenziali di connessione del dispositivo per la prossima volta, ad es. `bitbang connect nas1`. Se conosci [Magic Wormhole](https://github.com/magic-wormhole/magic-wormhole), la forma è simile -- un codice pronunciato che introduce in modo sicuro due macchine.
### Porta il tuo TURN
La maggior parte delle connessioni va direttamente peer-to-peer. Quando entrambe le estremità si trovano dietro un NAT che
non fa hole-punching, il traffico necessita di un relay, e per impostazione predefinita è il nostro. `-ice-servers`
punta il listener al tuo invece:
```
bitbang serve -ice-servers ~/turn.json
```
Il listener passa la configurazione al server di signaling alla registrazione, e il server
la fornisce a chiunque si connetta -- così entrambe le estremità usano il tuo relay e il nostro non è mai coinvolto.
Qualsiasi coturn, o un provider ospitato come Cloudflare o Twilio, funziona.
Il file è JSON, in una qualsiasi di queste tre forme che il tuo provider ti ha fornito:
```json
[{"urls": ["turn:turn.example.net:3478"], "username": "user", "credential": "pass"}]
```
```json
{"ice_servers": [{"urls": "stun:stun.example.net:3478"}]}
```
```json
{"iceServers": [{"urls": ["turn:turn.example.net:3478"], "username": "u", "credential": "p"}]}
```
`urls` accetta una stringa o una lista; `username` e `credential` sono per TURN e possono essere
omessi in una voce solo STUN. Il percorso può essere assoluto, relativo o con radice `~`. Un file
che non viene analizzato correttamente blocca il listener all'avvio anziché ripiegare silenziosamente.
Se una sessione finisce per essere inoltrata tramite relay senza che sia stato richiesto, `bitbang connect` lo segnala
invece di lasciarti a chiederti perché sembra lento. Il listener lo registra
in ogni caso (`via RELAY`), e `-relay` / `-norelay` forzano la questione in un senso
o nell'altro quando stai diagnosticando un percorso.
Vale la pena dirlo: si tratta di chi trasporta i byte, non di chi può leggerli. Un relay vede
solo testo cifrato DTLS, incluso il nostro. Esegui il tuo quando hai bisogno di più TURN di quanto possiamo fornire (attualmente limitiamo il tempo).
### Connessione da un browser
Apri l'URL. A seconda di ciò che viene servito, ottieni:
- **Shell** -- un terminale completo nella pagina (colori, ridimensionamento, copia/incolla).
- **Files** -- sfoglia, visualizza in anteprima, scarica e carica.
- **Proxy** -- digita un indirizzo LAN (`nas.local`, `192.168.1.10:8080`, `localhost:3000/admin`) e usa l'app come se fossi in locale. Login, cookie, caricamenti e streaming funzionano tutti.
<!-- TODO: per-feature demos -->
<!-- Remote shell in a browser tab -->
<!-- Streaming Jellyfin through the proxy -->
### Connessione dalla CLI
```
bitbang connect <url> # interactive shell
bitbang connect <url> -- tail -f /var/log/syslog # one-shot command
bitbang connect <url> -L 15432:db.internal:5432 # local TCP forwarding
bitbang connect <url> -L 14450:nas.local:445 -L 15900:[fd00::20]:5900
bitbang cp <url>:/var/log/app.log ./app.log # copy files, scp-style
bitbang cp - <url>:/tmp/firmware.bin < firmware.bin # stdin/stdout work too
```
`-L` inoltra **solo TCP**, come `ssh -L`. `-L` si lega a `127.0.0.1` a meno che non si passi
`-g`, che rende la porta inoltrata raggiungibile dalla rete locale -- e
chiunque la raggiunga ottiene ciò che il tunnel raggiunge, senza alcuna
credenziale BitBang davanti.
Il listener necessita di `bitbang serve forward` o `bitbang serve`. Per impostazione predefinita un
link `forward` raggiunge **qualsiasi host:porta raggiungibile dal listener**, non solo
quello che si aveva in mente, quindi un link fornito per un database raggiunge anche il resto
di quella rete. Restringilo indicando ciò che può raggiungere:
```
bitbang serve forward db.internal:5432 # this link reaches one service
```
Ogni connessione o associazione riuscita viene salvata in `~/.bitbang/devices.json`, così da quel momento in poi basta un nome breve: `bitbang connect nas1`.
## Supporto alle piattaforme
Un binario per piattaforma, nessuna dipendenza runtime. Tutto funziona
ovunque tranne le due righe indicate di seguito.
| | Linux | macOS | Windows |
| ---------------------------------------- | :---: | :---: | :-----: |
| Shell, file, proxy (`bitbang serve`) | sì | sì | sì |
| Inoltro TCP (`-L`) | sì | sì | sì |
| Link di accesso -- concessione, scadenza, revoca | sì | sì | sì |
| Bring your own TURN | sì | sì | sì |
| Associazione con un codice a 6 cifre | sì | sì | sì |
| La console del listener (Invio) | sì | sì | sì |
| `bitbang connect`, `bitbang cp` | sì | sì | sì |
| Visualizzazione di una sessione condivisa | sì | sì | sì |
| **Ospitare una condivisione** (`bitbang share`) | sì | sì | no * |
| **Ridimensionamento del terminale durante la connessione** | sì | sì | no ** |
\* `bitbang share` pubblica una sessione tmux, quindi ospitarne una richiede tmux --
Linux, macOS o WSL. Windows nativo può comunque aprire gli URL di condivisione con
`bitbang connect`.
\*\* Un connettore Windows non rileva il ridimensionamento del proprio terminale, quindi la
shell remota mantiene la dimensione con cui è stata avviata finché non ti riconnetti. Unix
ottiene questo da `SIGWINCH`, di cui Windows non ha un equivalente.
## Sicurezza
- **Identità auto-certificante.** Al primo avvio, `bitbang` genera una coppia di chiavi RSA sotto `~/.bitbang/<program>/`; l'UID del dispositivo è derivato dalla chiave pubblica, quindi impersonare un dispositivo significa trovare una seconda preimmagine del suo UID.
- **Il segreto non tocca mai il server.** Il codice di accesso risiede nel frammento dell'URL (`#…`), che i browser non inviano mai -- `bitba.ng` fa da intermediario per la connessione senza mai vedere la credenziale che la autorizza.
- **Crittografia end-to-end.** Tutto il traffico viaggia su DTLS di WebRTC. Il server di signaling vede solo la chiave pubblica, l'UID derivato e i metadati della connessione -- mai i tuoi dati. Un relay TURN, se necessario, vede solo testo cifrato.
- **Associazione verificata.** Il numero letto ad alta voce nell'associazione tramite codice è una stringa di autenticazione breve (SAS), calcolata indipendentemente su entrambi i lati dalle impronte DTLS negoziate e da due nonce impegnati -- un machine-in-the-middle, le cui impronte differiscono necessariamente, non può far coincidere i due numeri.
- **L'URL è una credenziale bearer.** Chiunque lo possieda ottiene ciò che hai scelto di servire -- una shell, se hai eseguito `serve shell`. Condividilo di conseguenza.
- **PIN opzionale** (`--pin`) per configurazioni permanenti o headless, e **modalità usa e getta** (`-ephemeral`) per un'identità nuova a ogni esecuzione.
- **Cosa vede ancora il server.** Non nulla. Fa da intermediario per la presentazione, quindi
osserva gli indirizzi IP di entrambi i lati, quando si connettono e quanto
si scambiano. La crittografia end-to-end lo tiene fuori dai tuoi dati, non dai
metadati che li circondano -- *fiducia minima* è una descrizione più equa di
*senza fiducia*.
- **Un browser si fida della pagina che ha caricato.** Il client browser è JavaScript
servito dal server di signaling, quindi aprire un URL significa fidarsi che quel server
serva codice onesto. `bitbang connect` non ha tale dipendenza: è un
binario che hai installato e verificato con checksum. Se questa distinzione ti importa,
connettiti con la CLI.
Come i due estremi si autenticano a vicenda, in modo che il server di signaling non possa
inserirsi nella connessione, è trattato in dettaglio qui: [*Trustless Signaling: Authentication Without a Central Authority*](https://github.com/richlegrand/bitbang/blob/main/trustless-signaling.md).
## Perché?
- **Niente da aprire o configurare.** Funziona da dietro NAT, CGNAT o una rete bloccata -- nessuna modifica al router, nessuna VPN, nessun demone tunnel.
- **Niente da installare sul lato che si connette.** Basta un browser. Una CLI è disponibile quando vuoi scripting, pipe e copia di file.
- **Privato per progettazione.** Il traffico è WebRTC/DTLS, peer-to-peer. Il server di signaling non lo vede mai; se un percorso diretto non è possibile, un relay TURN trasporta solo testo cifrato.
- **Nessun account, nessuna telemetria.**
### Perché non usare semplicemente SSH? O Tailscale?
Risposta breve: per una macchina a cui puoi già accedere via SSH, o per una flotta di tuoi
dispositivi su cui puoi installare, continua a usare quello che hai. `bitbang` serve quando
l'altro capo è una persona anziché un dispositivo, o quando non puoi installare nulla
dove ti trovi. Entrambe le domande trovano risposta in dettaglio nelle
**[FAQ](https://github.com/richlegrand/bitbang-cli/blob/main/FAQ.md)**.
## Installazione
```
curl -sSfL bitba.ng/install | sh
```
Linux e macOS. Rileva il tuo sistema operativo e architettura (`amd64`, `arm64` e `armv7` su Linux), scarica il binario dall'ultima [GitHub release](https://github.com/richlegrand/bitbang-cli/releases), verifica il suo SHA-256 rispetto al file `checksums.txt` della release e lo installa in `~/.local/bin/bitbang`.
Le build per Windows sono pubblicate come `bitbang-windows-amd64.exe` e
`bitbang-windows-arm64.exe`. Scarica il binario appropriato dalla pagina Releases,
rinominalo in `bitbang.exe` e inseriscilo nel tuo `PATH`.
**Compilazione dal sorgente:** vedi [sotto](#building-from-source).
**macOS e Gatekeeper.** Il comando di installazione in una riga sopra non è interessato: `curl` non
imposta l'attributo `com.apple.quarantine`, quindi il binario che scarica viene eseguito
normalmente. Se invece scarichi `bitbang-darwin-arm64` dalla pagina Releases
tramite un browser, macOS lo mette in quarantena e rifiuta di aprirlo, perché i binari
della release non sono notarizzati. Rimuovila con uno dei due comandi:
```
xattr -d com.apple.quarantine ./bitbang-darwin-arm64
```
oppure fai clic con il tasto destro sul file nel Finder e scegli Apri, che offre un'override
una tantum. In alternativa, compila dai sorgenti, che non applica mai la quarantena.
**Windows e SmartScreen.** La stessa cosa accade su Windows, per lo stesso
motivo. Un download dal browser allega il Mark-of-the-Web, quindi la prima esecuzione mostra
*"Windows ha protetto il tuo PC"* -- scegli **Ulteriori informazioni**, poi **Esegui comunque**. I
binari della release non sono firmati digitalmente, quindi questo è previsto e non è un segno
che qualcosa non vada. Scaricare il `.exe` con `curl` o con `Invoke-WebRequest` di PowerShell
non lo allega, e nemmeno compilare dai sorgenti.
### Opzioni di installazione
Fissa una versione, cambia la posizione o leggi lo script prima di eseguirlo:
```
curl -sSfL bitba.ng/install | sh -s -- --version 0.5.0
curl -sSfL bitba.ng/install | sh -s -- --prefix /usr/local/bin
curl -sSfL bitba.ng/install -o install.sh && less install.sh && sh install.sh
```
I tag di release non hanno il prefisso `v` (`0.5.0`, non `v0.5.0`).
### Come funziona l'URL di installazione
`bitba.ng/install` è un redirect, non uno script ospitato. La catena:
1. `curl` raggiunge `https://bitba.ng/install`, che risponde con un 302 verso [`install.sh`](https://github.com/richlegrand/bitbang-cli/blob/main/install.sh) in questo repo (su `main`).
2. Lo script viene eseguito nella tua shell, rileva OS+arch e scarica il binario da `https://github.com/richlegrand/bitbang-cli/releases/latest/download/bitbang-linux-<arch>`.
3. Recupera `checksums.txt` dalla stessa release e verifica lo SHA-256 del binario.
4. Installa in `~/.local/bin` (sovrascrivibile).
Lo script di installazione risiede in questo repo, accanto al codice che installa -- così puoi esaminarlo insieme al binario, e l'host canonico bitba.ng possiede solo l'URL breve. Chi ospita autonomamente può puntare l'`/install` del proprio host verso qualsiasi script distribuisca: la variabile d'ambiente `INSTALL_URL` del server di signaling controlla la destinazione del redirect (vuota → 404).
## Riferimento dei comandi
Ogni sottocomando e flag è documentato in **[CLI.md](https://github.com/richlegrand/bitbang-cli/blob/main/CLI.md)**, e `bitbang <command>
--help` stampa le stesse informazioni nel terminale.
## Compilazione dal sorgente
Richiede Go 1.25+. Go puro, linkato staticamente (`CGO_ENABLED=0`) -- cross-compilazione banale, nessuna dipendenza a runtime.
```
go build ./cmd/bitbang/
# cross-compile:
GOOS=linux GOARCH=arm64 go build -o bitbang-arm64 ./cmd/bitbang/
GOOS=linux GOARCH=arm GOARM=7 go build -o bitbang-armv7 ./cmd/bitbang/
GOOS=windows GOARCH=amd64 go build -o bitbang.exe ./cmd/bitbang/
GOOS=darwin GOARCH=arm64 go build -o bitbang-macos ./cmd/bitbang/
```
Da Prompt dei comandi di Windows:
```bat
go build -o bitbang.exe .\cmd\bitbang
go test .\...
run_tests.cmd unit
```
I comandi shell, la condivisione di file, il proxy e il client CLI sono supportati su
Windows. Le shell interattive del browser e della CLI utilizzano Windows ConPTY, inclusi
l'eco dell'input del terminale, la modifica delle righe, l'output VT e gli eventi di ridimensionamento. ConPTY richiede
Windows 10 versione 1809 o Windows Server 2019 o successivo.
## Diagrammi
<p align="center">
<img src="https://assets.kitploit.com/production/public/readmes/47068/d68fcddad62ab84f11a549906a2b5abf2330fb25f39b3c1a1266eac7257a080d.png" alt="shell e condivisione file della CLI bitbang" width="760">
<img src="https://assets.kitploit.com/production/public/readmes/47068/55bb6866c22504a6434e3dee8cb998e747cd73cb9d0bfa5e0bc0ede7b90ce262.png" alt="funzionamento del proxy della CLI bitbang" width="720">
</p>
## Roadmap
Disponibili oggi: **shell, file e proxy**, accessibili dal browser o dalla CLI, oltre al **port forwarding TCP**, alla copia di file in stile scp, all'**accoppiamento ad-hoc** con una tabella dei dispositivi salvata, alla **condivisione del terminale** (`bitbang share`) e ai **link di accesso** (`bitbang link`) che limitano e fanno scadere ciò che un URL concede. Progettati e in arrivo:
- **Serial bridging** -- pilotare un `/dev/ttyUSB0` remoto da una porta virtuale locale (ad es. eseguire Arduino IDE su internet). È stata aperta una issue [qui](https://github.com/richlegrand/bitbang-cli/issues/3).
- **Desktop remoto** -- schermo tramite un video track WebRTC, tastiera/mouse tramite il data channel.
## Licenza
MIT -- vedi [LICENSE](https://github.com/richlegrand/bitbang-cli/blob/main/LICENSE).
## Contribuire
Issue e PR sono benvenute.
Le ricette sono diverse: risiedono nel [cookbook](https://github.com/richlegrand/bitbang/blob/main/cookbook.md),
nel repository [bitbang](https://github.com/richlegrand/bitbang), perché riguardano
ogni progetto e non solo questo. Aggiungere una ricetta è una PR lì.
Farla *elencare* è una seconda, piccola PR per progetto il cui README dovrebbe mostrarla
-- l'elenco [Ricette](#recipes) qui sopra è mantenuto a mano. È una scelta
deliberata: ogni progetto decide quali ricette vale la pena mettere davanti ai propri
lettori, invece di far crescere ogni README con ogni ricetta.