P2P2P — Data Sovereignty

Your data. Your machine. Their browser.

The safest place for sensitive data is the machine that owns it. The best place for the Explorer is where people can reach it. P2P2P connects the two without moving the data.

---

The Problem

Healthcare data is sensitive. Material costs, billing patterns, case volumes — these are operational facts that hospitals guard with legal weight. Uploading a KLS to someone else’s cloud is, for many organisations, simply not an option.

But analysis is a collaborative act. The data engineer builds the KLS. The consultant reviews findings. The CFO wants the headline numbers on their iPad. The domain expert annotates anomalies. These people are rarely in the same room, on the same network, or willing to install software.

P2P2P is the deployment mode that reconciles both needs.

---

The Elevator Pitch

Your hospital’s data never leaves your server room. But your CFO can browse findings on their iPad, your consultant can review from Zurich, and your auditor can verify from Bern — all at the same time, all seeing live data, all through a single URL. When you close the laptop, the data vanishes from the internet. Instantly.

That’s P2P2P.

---

The Vision

No cloud storage. No data replication. No bucket policies. Each hospital runs a proxy. The Explorer is a query router.

---

The Name

P2P2P — Peer-to-Peer-to-People.

The first P2P is the machine-to-machine connection (proxy ↔ Explorer). The second P is the human at the end — the person who needs to see the data without touching the infrastructure.

Traditional P2P moves data between peers. P2P2P moves insight between peers and delivers it to people.

---

The Sovereignty Principle

Data sovereignty means the data owner decides, moment by moment, whether their data is accessible. The decision is physical, not administrative. You don’t revoke a permission — you unplug.

In P2P2P:

What	Where	Who controls it
KLS file	Owner’s machine	Owner
Query execution	Owner’s machine	Owner
Query results	In transit (TLS)	Cloudflare (transport)
Explorer UI	Cloud (Fly.io)	jinflow
Proxy directory	Cloud (Fly.io, in-memory)	jinflow
Session token	Owner’s machine + browser cookie	Owner + user

The data never leaves the owner’s machine. Query results transit through Cloudflare’s network (TLS-encrypted) and the Explorer server (pass-through, not stored), then reach the user’s browser.

---

The User Experience

For the data owner

# Build the KLS as usual
jinflow make --tenant numetrix.szo_brig

# Share it — one command
jinflow-proxy store/numetrix_szo_brig_kls.duckdb --tunnel

# Output:
#   KLS:     numetrix_szo_brig_kls.duckdb (89 MB)
#   Tenant:  szo_brig
#   Tunnel:  https://amber-fox-23.trycloudflare.com
#
#   Registered with proxy.jinflow.io
#   Open:    https://proxy.jinflow.io/s/k8m2np4qr7st9vwx
#
#   Press Ctrl+C to stop

Share the URL with anyone who should have access. When you’re done, press Ctrl+C. The data disappears from the cloud instantly.

For the viewer

1. Receive a URL: https://proxy.jinflow.io/s/k8m2np4qr7st9vwx
2. Click it — the Explorer opens with the tenant’s data
3. Browse findings, theses, entities — the full Explorer experience
4. Every query is answered in real-time from the owner’s machine
5. No login, no account, no installation

For the administrator (multi-site coordinator)

The tenant picker at proxy.jinflow.io shows all registered proxies with their online/offline status. Click any online tenant to enter — no credentials beyond the session URL.

---

Stealth Mode vs Identified Mode

P2P2P operates in a spectrum of trust.

Stealth mode (unauthenticated)

The session URL works without login. Click and browse. No account, no credentials, no trace of who you are. This is not a compromise — it’s a trust-building feature. For the CFO who’s never used an analytics platform, the absence of a login wall is an invitation: “Just look. No commitment.”

Stealth mode answers “What does this system do?” before asking “Who are you?”

Identified mode (GitHub auth)

When a viewer chooses to sign in, they unlock: notebook access (notes, replies, action items), bookmarks (saved views), an audit trail, and author attribution on their notes.

The proxy owner controls whether identification is required:

jinflow-proxy kls.duckdb --tunnel                    # stealth: anyone with URL can view
jinflow-proxy kls.duckdb --tunnel --require-auth     # identified: GitHub sign-in required

Default is stealth. Opt into identification for audit-grade sessions.

---

Why This Is Better Than Cloud Storage

	Cloud (R2)	P2P2P
Data location	Cloudflare R2 bucket	Owner’s machine
Access control	IAM policies, bucket ACLs	Physical: proxy on/off
Revocation	Delete from bucket, purge caches	Ctrl+C
Revocation latency	Minutes (propagation)	Instant
Compliance audit	Cloud provider logs	Local query audit log
Availability	24/7 (cloud SLA)	Only when proxy runs
Setup	R2 credentials, sync profiles	One command

The tradeoff is availability for sovereignty. P2P2P is not always-on. It’s on when the owner decides it’s on. For scheduled reviews, audits, and consulting sessions, that’s not a limitation — it’s the feature.

---

Architectural Implications

The Explorer becomes stateless

In P2P2P mode, the Explorer stores nothing: no KLS files, no query results, no credentials, no user sessions beyond httpOnly cookies pointing at proxy tokens. The proxy directory is in-memory. A restart wipes it clean and proxies re-register within 60 seconds.

This makes the Explorer horizontally scalable and disposable. If it crashes, restart it — proxies reconnect automatically.

The KLS is the API

Every proxy serves the same interface: POST /query { sql }. The Explorer doesn’t care whether the KLS is local, on R2, or behind a tunnel. P2P2P is not a special mode — it’s the same mode as cloud, with a different transport.

---

Security Posture

P2P2P’s machinery is shipped; production hardening is in progress. The design doc tracks the full threat model and remediation plan. Headlines:

• Token-based auth: 24-character random per session. Header-only (no query-param tokens in production).
• SQL whitelist: SELECT / WITH / SHOW / DESCRIBE / PRAGMA only. KLS is opened read-only.
• CORS origin pinning: restrict to the Explorer origin.
• Query audit log: local append-only file, under the owner’s control.
• Heartbeat protocol: 60s interval, proxies marked stale after 3 missed beats.
• Named Cloudflare Tunnels: for production deployments, replace Quick Tunnels with named tunnels under a Cloudflare account.

For the full threat model and mitigation catalogue, see the design doc: docs/design/sense_16_p2p2p.md.

---

Related

• Operating Modes — the five deployment topologies, P2P2P being Mode 2
• Studio / Salon / Lab — P2P2P is primarily a Salon technology
• Deploy Guide — how to run P2P2P in practice