Claude Opus 4.7 09355e9914 web: filter incoming by per-browser peerID, not source label
Old filter hid all source=web messages — meant multiple browsers
couldn't see each other's sends. Now each browser only filters out
its OWN peerID, so iphone↔mbp↔desktop all see each other's clipboard.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
2026-05-21 00:48:21 -05:00

tether

Phone ↔ laptop clipboard relay. v0.1 / MVP.

Today this is an HTTP+SSE broadcast bus. The roadmap is what makes it interesting: WebRTC for true P2P, Sign in with Apple for cross-device identity, mDNS for same-LAN discovery, end-to-end encryption baked in.

phone (web UI)              tether-server                tether-client
─────────────               ─────────────                ──────────────
type/paste                  HTTP+SSE relay               Linux/Mac/Win
  │                              │                              │
  └─── POST /api/send ──────────▶│                              │
                                 ├──── event: clipboard ───────▶│
                                 │                              ▼
                                 │                          stdout / OS
                                 │                          clipboard
                                 │◀──── POST /api/send ─────────┘
                                 ▼
                          web UI shows it

Quick start

go run ./server
# in another terminal
go run ./client -server http://localhost:8765

# send a one-shot message from CLI:
go run ./client -server http://localhost:8765 -send "hello"

Then open http://localhost:8765/ on your phone (same network) and try the buttons.

Pieces

  • server/ — single Go binary. Embedded HTML page. Exposes:
    • GET / — phone UI
    • POST /api/send — accept a message
    • GET /api/stream — SSE feed of every published message
    • GET /healthz
  • client/ — CLI client. Subscribes to /api/stream, prints received messages to stdout. -send for one-shot send.
  • server/web/index.html — phone UI (paste, send, live feed of incoming).

Roadmap

Phase What Why
v0.1 (now) HTTP+SSE relay, single broadcast bus Prove the shape end-to-end
v0.2 mDNS service advertisement, QR pairing Zero-config discovery
v0.3 WebRTC data channel (Pion) — clients negotiate P2P after seeing each other via the server's signaling True low-latency E2E (DTLS)
v0.4 Sign in with Apple OAuth → stable sub ties multiple devices to one trust circle Identity without account/password
v0.5 OS clipboard hook on client (read + write) — phone copy → laptop paste appears automatically The actual Universal-Clipboard UX
v0.6 File drop (large blob over WebRTC), encrypted at-rest history Snapdrop-like UX bundled in
v1.0 macOS / Windows clients, push notifications when off-network, packaged installers Product

Why E2E by default

WebRTC data channels mandate DTLS. Once we move from SSE relay (v0.1) to P2P data channels (v0.3+), the server only ever sees encrypted bytes (and only during signaling — not for the data itself). That's free end-to-end encryption, modeled on Apple's Continuity but using standardized protocols.

Why Sign in with Apple

~80% of Windows users also own an iPhone. SiwA gives us a free, privacy-respecting identity provider that returns a stable per-app subject ID. Devices that authenticate to the same sub are in the same trust circle automatically. No passwords, no per-app account.

What this isn't

  • Not a Snapdrop clone (no file drop yet)
  • Not KDE Connect (no OS integration yet)
  • Not Pushbullet (no server-side persistence)
  • Not yet WebRTC (v0.1 is HTTP relay)

But the foundation is right.

License

MIT

Description
phone ↔ laptop clipboard relay — MVP
Readme 137 KiB
Languages
Go 57.5%
HTML 42.5%