98dc2ca2a6
Server: unchanged shape, just added a "signal" message type to the existing /api/send + /api/stream bus. Now carries both "clipboard" (payload) and "signal" (offer/answer/ICE) over the same envelope. Client: -rtc flag turns the Go listener into a Pion peer. Posts an SDP offer at startup, accepts the browser's answer through the signaling bus, exchanges ICE, then receives clipboard text over a DataChannel named "tether". On message: writes to OS clipboard same as SSE path. Web UI: acts as the answerer. Listens for "signal" SSE events, replies to offers, exchanges ICE. When DataChannel opens, the send button uses RTCDataChannel.send() instead of POST /api/send — data no longer traverses the server after pairing. Pill in the header flips sse → negotiating → rtc to make this visible. Toolchain: bumped go.mod to go 1.26, switched to pion/webrtc v4 and prometheus/client_golang v1.23.x. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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 UIPOST /api/send— accept a messageGET /api/stream— SSE feed of every published messageGET /healthz
client/— CLI client. Subscribes to/api/stream, prints received messages to stdout.-sendfor 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