weed-cli 2.1.0__tar.gz → 2.2.0__tar.gz

{weed_cli-2.1.0 → weed_cli-2.2.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: weed-cli
-Version: 2.1.0
+Version: 2.2.0
 Summary: Censorship-resistant video PoC — discovery/hosting/download over signed relay events, a real Kademlia DHT, or a TLS-capable NAT-traversal tunnel
 License: MIT
 Keywords: p2p,video,censorship-resistant,discovery,dht,kademlia,nat-traversal
@@ -116,6 +116,10 @@ weed discover --relay http://127.0.0.1:9101
 weed download <content_hash_prefix> --relay http://127.0.0.1:9101 --out downloaded.mp4
 weed like <content_hash> --relay http://127.0.0.1:9101
 weed subscribe <target_pubkey> --relay http://127.0.0.1:9101
+
+# --relay is repeatable everywhere: an event goes to every relay named,
+# and this copies anything you signed that one relay has and another lacks
+weed sync-relays --relay http://127.0.0.1:9101 --relay https://relay.example.org
 ```
 
 `--advertise-host` matters once you're off localhost — there's no NAT
@@ -160,15 +164,39 @@ weed> download 7f2477c7ea675004ad5dbab6dc7c44327c724b880cc389807df1965b77966acc
 `web_ui.py` wraps the same `node.py` functions behind a small stdlib
 JSON API plus a static, no-build-step frontend — host/discover/download/
 like/subscribe without memorizing CLI flags. Binds `127.0.0.1` by
-default (no auth built — this is a local control surface, not something
-meant to face the internet); `--bind 0.0.0.0` widens it at your own
-risk and auto-detects your real LAN IP for the printed/scanned QR code.
+default (a local control surface, not something meant to face the
+internet); `--bind 0.0.0.0` widens it and auto-detects your real LAN IP
+for the printed/scanned QR code. Auth is optional: `--auth-token` (bare
+for a generated token, or give one; `$WEED_UI_TOKEN` in Docker) gates
+every API call behind a bearer token. The startup QR and printed URL
+then carry it, so scanning is the login; the page shows an unlock
+prompt if opened any other way; the stream URLs it hands to VLC carry
+it as `?token=`, since a player can't send a cookie.
 
 ```bash
 weed serve                          # alias for `web`, positional: serve [bind] [port]
 weed serve 0.0.0.0 8080             # reachable from your phone; prints a scan-to-open QR
+weed web --bind 0.0.0.0 --auth-token # same, behind a generated token (printed + in the QR)
+weed web --bind 0.0.0.0 --tls --auth-token --stream-plain-port 8081
 ```
 
+`--stream-token` (with `--auth-token`) adds a second, guest tier: a
+browser opened with that token gets the **party view** and nothing
+else — the live Orbit stream, what's playing, a vote on which
+downloaded track plays next (one vote per person per track, toggleable),
+and whatever links you set. The admin's **Party** tab holds the guest
+link and its QR code, the title and links, the live tally with a ▶ per
+track, and an "auto-play the top vote when a track ends" switch.
+Guests can't host, download, like, subscribe, or read the library.
+
+`--stream-plain-port` adds a plain-HTTP listener that serves *only* the
+stream endpoints (the Orbit MJPEG stream and downloaded files), for
+players that can't do TLS with a self-signed cert — a Roku IP-camera
+viewer, a smart TV. Nothing else is served there, and the token still
+applies (`?token=`). In "IP Camera Viewer for Roku", enter the Pi's IP,
+that port, and `/api/orbit-view?token={0}` as the stream URL with the
+token as the login: the app substitutes `{0}` itself.
+
 Includes real HTTP range support (`/api/stream/<job_id>`) so a
 `<video>` tag can seek a completed download instead of downloading it
 blind.
@@ -233,6 +261,13 @@ hardcode a threshold):
 Over real WAN distance (tunneled to a remote box over SSH), the gap is
 ~1700x and separates cleanly at a single sample — the hard case this
 PoC stress-tests is two peers that are genuinely close together.
+`node.py`'s real download path runs this after its FETCH-and-verify
+gate: `--timing-rounds` (default 5) nonce challenges per candidate,
+each on a chunk the host hasn't been asked to forward yet (so a relay's
+cache is cold), each timed next to a plain `PRICE` round trip on the
+same socket so the number is a ratio rather than milliseconds. Medians
+break ties in the auction; `--max-timing-ratio` turns it into a hard
+gate.
 
 **`poc_reputation.py`** — persistent local reputation plus signed,
 portable attestations (Ed25519, real signing/verification): a client's
@@ -321,12 +356,18 @@ downloader `CONNECT`s; the relay asks the host to dial back
 sockets, no opinion on the tunneled protocol. Supports TLS at the edge
 (`tls://` prefix, for relays like Fly that terminate TLS themselves) and
 a periodic heartbeat so idle control connections survive proxies that
-reset connections after a few minutes of silence.
+reset connections after a few minutes of silence. `--tunnel` is
+repeatable: the host registers with every relay named, the publish
+event lists them all in order, and a downloader tries each in turn —
+probing with a real `INFO` round trip, since a relay accepts any
+`CONNECT` and only afterwards says whether it knows the host — so one
+tunnel relay being down (or restarted, or having never heard of this
+host) is a skipped entry, not a failed download.
 
 ```bash
 python3 discovery_relay.py 9101
 python3 tunnel_relay.py 9199
-weed host real_archive --port 9201 --tunnel 127.0.0.1:9199 \
+weed host real_archive --port 9201 --tunnel 127.0.0.1:9199 --tunnel tls://tunnel.example.org:9199 \
     --relay http://127.0.0.1:9101 --advertise-host 10.255.255.1
 weed download <content_hash> --relay http://127.0.0.1:9101 --out downloaded.mp4
 ```
@@ -379,10 +420,20 @@ just designed:
 Honest edges that are still real constraints even though the core
 mechanisms hold up:
 
-- Loopback timing separation isn't airtight on a single sample —
-  averaging repeated challenges is required.
-- Relay death loses anything posted exclusively there; redundancy
-  across relays isn't automatic.
+- The timing challenge is now on the real download path (`node.
+  nonce_challenge`: five nonce-salted `CHALLENGE` rounds per candidate,
+  each timed against a bytes-free `PRICE` round trip on the same socket,
+  medians, reported as a ratio) — but the verdict is still yours. The
+  ratio breaks ties in the auction and `--max-timing-ratio` can reject
+  on it; there's no default cutoff because the honest-vs-relay
+  crossover depends on how close the two are (loopback vs LAN vs WAN).
+  Measure it live, then pick a number.
+- Relays still never talk to each other. Every event a node signs now
+  goes to every relay it names, the web UI mirrors its own events across
+  its relays every few minutes, and `weed sync-relays` does the same on
+  demand — but that redundancy is per node, scoped to that node's own
+  events by default (`--all` mirrors everyone's). An event whose signer
+  only ever named one relay, and never syncs, still dies with it.
 - Lightning settlement is regtest-only, and both sides still have to
   name which of exactly two demo LND identities (`alice`/`bob`) they
   are — the protocol pays whoever really won, but the pool of real
@@ -390,8 +441,14 @@ mechanisms hold up:
   an arbitrary host's own independently-run LND node.
 - The DHT covers host-discovery only, not the richer publish/like/
   subscribe/attestation event system.
-- The tunnel relay (even with TLS) is a single point of failure and
-  bandwidth cost, with no redundancy story the way discovery relays have.
-- The web UI has no authentication; it's local-only by design. It also
-  doesn't expose `--lightning-node` in its Host/Download forms yet,
-  even though the API accepts it.
+- A host can register with several tunnel relays and downloaders fail
+  over between them, but each relay is still a bandwidth cost the host
+  can't avoid — every tunneled byte crosses it — and an active download
+  doesn't migrate if its relay dies mid-transfer; it restarts on the
+  next one.
+- The web UI's auth is two shared bearer tokens (`--auth-token` for
+  everything, `--stream-token` for the guest party view), off by default
+  and local-only when off. No accounts, no rotation without a restart,
+  and votes are anonymous per browser cookie — enough to put a
+  LAN-bound UI behind something and hand guests a safe subset, not a
+  reason to face it at the internet.

{weed_cli-2.1.0 → weed_cli-2.2.0}/README.md

@@ -84,6 +84,10 @@ weed discover --relay http://127.0.0.1:9101
 weed download <content_hash_prefix> --relay http://127.0.0.1:9101 --out downloaded.mp4
 weed like <content_hash> --relay http://127.0.0.1:9101
 weed subscribe <target_pubkey> --relay http://127.0.0.1:9101
+
+# --relay is repeatable everywhere: an event goes to every relay named,
+# and this copies anything you signed that one relay has and another lacks
+weed sync-relays --relay http://127.0.0.1:9101 --relay https://relay.example.org
 ```
 
 `--advertise-host` matters once you're off localhost — there's no NAT
@@ -128,15 +132,39 @@ weed> download 7f2477c7ea675004ad5dbab6dc7c44327c724b880cc389807df1965b77966acc
 `web_ui.py` wraps the same `node.py` functions behind a small stdlib
 JSON API plus a static, no-build-step frontend — host/discover/download/
 like/subscribe without memorizing CLI flags. Binds `127.0.0.1` by
-default (no auth built — this is a local control surface, not something
-meant to face the internet); `--bind 0.0.0.0` widens it at your own
-risk and auto-detects your real LAN IP for the printed/scanned QR code.
+default (a local control surface, not something meant to face the
+internet); `--bind 0.0.0.0` widens it and auto-detects your real LAN IP
+for the printed/scanned QR code. Auth is optional: `--auth-token` (bare
+for a generated token, or give one; `$WEED_UI_TOKEN` in Docker) gates
+every API call behind a bearer token. The startup QR and printed URL
+then carry it, so scanning is the login; the page shows an unlock
+prompt if opened any other way; the stream URLs it hands to VLC carry
+it as `?token=`, since a player can't send a cookie.
 
 ```bash
 weed serve                          # alias for `web`, positional: serve [bind] [port]
 weed serve 0.0.0.0 8080             # reachable from your phone; prints a scan-to-open QR
+weed web --bind 0.0.0.0 --auth-token # same, behind a generated token (printed + in the QR)
+weed web --bind 0.0.0.0 --tls --auth-token --stream-plain-port 8081
 ```
 
+`--stream-token` (with `--auth-token`) adds a second, guest tier: a
+browser opened with that token gets the **party view** and nothing
+else — the live Orbit stream, what's playing, a vote on which
+downloaded track plays next (one vote per person per track, toggleable),
+and whatever links you set. The admin's **Party** tab holds the guest
+link and its QR code, the title and links, the live tally with a ▶ per
+track, and an "auto-play the top vote when a track ends" switch.
+Guests can't host, download, like, subscribe, or read the library.
+
+`--stream-plain-port` adds a plain-HTTP listener that serves *only* the
+stream endpoints (the Orbit MJPEG stream and downloaded files), for
+players that can't do TLS with a self-signed cert — a Roku IP-camera
+viewer, a smart TV. Nothing else is served there, and the token still
+applies (`?token=`). In "IP Camera Viewer for Roku", enter the Pi's IP,
+that port, and `/api/orbit-view?token={0}` as the stream URL with the
+token as the login: the app substitutes `{0}` itself.
+
 Includes real HTTP range support (`/api/stream/<job_id>`) so a
 `<video>` tag can seek a completed download instead of downloading it
 blind.
@@ -201,6 +229,13 @@ hardcode a threshold):
 Over real WAN distance (tunneled to a remote box over SSH), the gap is
 ~1700x and separates cleanly at a single sample — the hard case this
 PoC stress-tests is two peers that are genuinely close together.
+`node.py`'s real download path runs this after its FETCH-and-verify
+gate: `--timing-rounds` (default 5) nonce challenges per candidate,
+each on a chunk the host hasn't been asked to forward yet (so a relay's
+cache is cold), each timed next to a plain `PRICE` round trip on the
+same socket so the number is a ratio rather than milliseconds. Medians
+break ties in the auction; `--max-timing-ratio` turns it into a hard
+gate.
 
 **`poc_reputation.py`** — persistent local reputation plus signed,
 portable attestations (Ed25519, real signing/verification): a client's
@@ -289,12 +324,18 @@ downloader `CONNECT`s; the relay asks the host to dial back
 sockets, no opinion on the tunneled protocol. Supports TLS at the edge
 (`tls://` prefix, for relays like Fly that terminate TLS themselves) and
 a periodic heartbeat so idle control connections survive proxies that
-reset connections after a few minutes of silence.
+reset connections after a few minutes of silence. `--tunnel` is
+repeatable: the host registers with every relay named, the publish
+event lists them all in order, and a downloader tries each in turn —
+probing with a real `INFO` round trip, since a relay accepts any
+`CONNECT` and only afterwards says whether it knows the host — so one
+tunnel relay being down (or restarted, or having never heard of this
+host) is a skipped entry, not a failed download.
 
 ```bash
 python3 discovery_relay.py 9101
 python3 tunnel_relay.py 9199
-weed host real_archive --port 9201 --tunnel 127.0.0.1:9199 \
+weed host real_archive --port 9201 --tunnel 127.0.0.1:9199 --tunnel tls://tunnel.example.org:9199 \
     --relay http://127.0.0.1:9101 --advertise-host 10.255.255.1
 weed download <content_hash> --relay http://127.0.0.1:9101 --out downloaded.mp4
 ```
@@ -347,10 +388,20 @@ just designed:
 Honest edges that are still real constraints even though the core
 mechanisms hold up:
 
-- Loopback timing separation isn't airtight on a single sample —
-  averaging repeated challenges is required.
-- Relay death loses anything posted exclusively there; redundancy
-  across relays isn't automatic.
+- The timing challenge is now on the real download path (`node.
+  nonce_challenge`: five nonce-salted `CHALLENGE` rounds per candidate,
+  each timed against a bytes-free `PRICE` round trip on the same socket,
+  medians, reported as a ratio) — but the verdict is still yours. The
+  ratio breaks ties in the auction and `--max-timing-ratio` can reject
+  on it; there's no default cutoff because the honest-vs-relay
+  crossover depends on how close the two are (loopback vs LAN vs WAN).
+  Measure it live, then pick a number.
+- Relays still never talk to each other. Every event a node signs now
+  goes to every relay it names, the web UI mirrors its own events across
+  its relays every few minutes, and `weed sync-relays` does the same on
+  demand — but that redundancy is per node, scoped to that node's own
+  events by default (`--all` mirrors everyone's). An event whose signer
+  only ever named one relay, and never syncs, still dies with it.
 - Lightning settlement is regtest-only, and both sides still have to
   name which of exactly two demo LND identities (`alice`/`bob`) they
   are — the protocol pays whoever really won, but the pool of real
@@ -358,8 +409,14 @@ mechanisms hold up:
   an arbitrary host's own independently-run LND node.
 - The DHT covers host-discovery only, not the richer publish/like/
   subscribe/attestation event system.
-- The tunnel relay (even with TLS) is a single point of failure and
-  bandwidth cost, with no redundancy story the way discovery relays have.
-- The web UI has no authentication; it's local-only by design. It also
-  doesn't expose `--lightning-node` in its Host/Download forms yet,
-  even though the API accepts it.
+- A host can register with several tunnel relays and downloaders fail
+  over between them, but each relay is still a bandwidth cost the host
+  can't avoid — every tunneled byte crosses it — and an active download
+  doesn't migrate if its relay dies mid-transfer; it restarts on the
+  next one.
+- The web UI's auth is two shared bearer tokens (`--auth-token` for
+  everything, `--stream-token` for the guest party view), off by default
+  and local-only when off. No accounts, no rotation without a restart,
+  and votes are anonymous per browser cookie — enough to put a
+  LAN-bound UI behind something and hand guests a safe subset, not a
+  reason to face it at the internet.