tibet-overlay 0.1.2

Decentralized Identity Overlay — crypto-based device identity over broken IPv4/CGNAT networks with TIBET provenance

tibet-overlay — Decentralized Identity Overlay

Identity belongs to the device, not the network.

Cryptographic device identity over broken IPv4/CGNAT networks.

tibet-overlay creates an identity layer independent of IP addresses. Devices prove who they are via cryptographic JIS identity tokens and TIBET history, not via their IP address. This makes CGNAT, NAT traversal, and IP spoofing irrelevant for identity.

The Problem

IPv4 addresses are exhausted. Millions of devices sit behind Carrier-Grade NATs (CGNAT), sharing the same public IP. This breaks:

• Point-to-point connections — you can't reach a device directly
• Zero-trust security — who is who behind that shared IP?
• Audit trails — IP-based logs are meaningless with CGNAT

IPv6 adoption is too slow, especially in industrial environments.

The Insight

Identity ≠ IP address. Identity should be cryptographic (bound to the device), not topological (bound to the network).

Install

pip install tibet-overlay

Quick Start

from tibet_overlay import IdentityOverlay

overlay = IdentityOverlay()

# Register devices (same public IP = CGNAT)
overlay.register("sensor-01", ip="203.0.113.1", port=44321, behind_nat=True, capabilities=["mqtt"])
overlay.register("sensor-02", ip="203.0.113.1", port=44322, behind_nat=True, capabilities=["mqtt"])

# Verify identity (crypto-based, not IP-based)
proof = overlay.verify("jis:sensor-01")
print(proof.verified)     # True
print(proof.trust_score)  # 0.5

# Resolve endpoint by identity
route = overlay.resolve("jis:sensor-01")
print(route.endpoint)     # 203.0.113.1:44321
print(route.resolved)     # True

# Find by capability
mqtt_devices = overlay.find_by_capability("mqtt")

Demo

tibet-overlay demo
tibet-overlay info

How It Works

[Device A: 10.0.0.x]  ---JIS ID--→  [Identity Overlay]  ←--JIS ID---  [Device B: 10.0.0.y]
  behind CGNAT                     identity = crypto                  behind CGNAT
  IP is irrelevant                 not IP-based                       IP is irrelevant

1. Device registers with JIS identity (cryptographic key pair)
2. Overlay stores identity → endpoint mapping
3. Resolution is by identity, not by IP
4. When IP changes (DHCP, roaming, CGNAT reassignment), identity stays the same
5. TIBET tracks every identity event for audit

Why Not Just Use IP?

Problem	IP-based	tibet-overlay
CGNAT (shared IP)	Can't distinguish devices	Each has unique JIS identity
IP change (DHCP/roaming)	Identity lost	Identity persists
IP spoofing	Trivial	Cryptographically impossible
NAT traversal (VoIP/SIP)	STUN/TURN/ICE nightmare	Identity-based routing
Audit trail	"Which 10.0.0.x?"	"jis:sensor-01 did X at Y"

Use Cases

• IoT behind CGNAT — millions of devices, shared IPs, each with unique identity
• VoIP NAT traversal — SIP + NAT has been broken for 25 years. JIS identity makes STUN/TURN obsolete
• Industrial networks — isolated subnets with overlapping IP ranges
• Mobile devices — IP changes constantly, identity doesn't
• Multi-cloud — same service across AWS/GCP/Azure, one identity

TIBET Provenance

Every identity event creates a TIBET token:

Layer	Content
ERIN	What happened (registration, verification, resolution)
ERAAN	Dependencies (parent tokens, device chain)
EROMHEEN	Context (overlay node, timestamp)
ERACHTER	Intent (why this identity action)

Part of the TIBET ecosystem

Package	Purpose
tibet-core	Protocol core
tibet-y2k38	Y2K38 Time Bridge
tibet-pol	Process Integrity Checker
tibet-pqc	Post-Quantum Crypto Router
tibet-overlay	Identity Overlay
tibet-twin	Digital Twin Guard

License

MIT — Humotica AI Lab 2025-2026

Authors

• J. van de Meent — [e-mail]
• R. AI (Root AI) — [e-mail]

Credits

Designed by Jasper van de Meent. Built by Jasper and Root AI as part of HumoticaOS.

---

Stack-positie: Groep agentic · Bootstrap = OSAPI-handshake naar tibet + jis (fail → snaft-rule + tibet-pol-rapport) · ← tibet-mux · See STACK.md · See demo/golden-path/ for the spine end-to-end.

Enterprise

For private hub hosting, SLA support, custom integrations, or compliance guidance:

Enterprise	[e-mail]
Support	[e-mail]
Security	[e-mail]

See ENTERPRISE.md for details.