FGTW Identity

Readable Names for Cryptographic Identities

Custom DHT • Kademlia routing • Decentralized discovery

The Problem

Cryptographic systems use public keys as identities:
random 256-bit numbers that look like 71916849411390349927326459079491417677155222436162033175112723725944664108335

Humans can't remember these.
We want Tae Ora, not 29243907897268769068263847572130640405526670312934002257665713467491539430103.

But human-readable names create problems:

Centralization

DNS requires ICANN. ENS requires Ethereum. Someone controls the registry.

Collision

Two people want "alice". Who gets it? First-come? Auction? Authority decides?

Hijacking

If names can be transferred, they can be stolen. Phishing, coercion, hacking.

Discovery

How do strangers find you? Global directory? That's centralization again.

How It Works

Deterministic Addressing

Your handle hashes to a 32-byte DHT address. Anyone can compute where to look—no central registry needed.

↓

Peer Records

Each device you use creates a peer record stored in the DHT. Multiple devices = multiple records
all linked to your handle hash.

            PeerRecord {

                handle_hash: [u8; 32], // BLAKE3 of your handle

                device_pubkey: [u8; 32], // This device's X25519 public key

                ip: SocketAddr, // Where to reach this device

                last_seen: f64, // Eagle timestamp

            }

When someone messages "fractaldecoder", they hash your name, query the DHT, get your device records, and establish TLS connections.

Trust & Discovery

Vouching System (Planned)

FGTW will use social vouching to establish identity trust. Existing users vouch for new users, creating a web of cryptographic attestations.

            When Alice vouches for Bob:

            0. Alice signs: "I vouch for Bob's identity at hash(bob)"

            1. Bob includes Alice's vouching signature in his DHT record

            2. Others who trust Alice can transitively trust Bob

            3. Multiple vouches build reputation

This prevents:

Sybil attacks - can't mass-create identities without vouches
Impersonation - vouch network makes fake identities obvious
Spam - unvouched identities have limited reach

Invite-Only Bootstrap

New users need an invite from existing users. Invites are cryptographically linked, creating an auditable chain.

Current implementation uses simple DHT lookup.
Vouching and invite systems are in design phase.

Kademlia Routing

FGTW uses Kademlia XOR-distance routing to find peers. Each node maintains a routing table.

How Discovery Works

            0. Hash handle: handle_hash = BLAKE3("alice")

            1. Calculate XOR distance from your node ID to handle_hash

            2. Query closest k nodes iteratively

            3. Nodes return peer records for "alice"

            4. Connect directly to alice's devices via TLS

Nodes maintain routing tables based on XOR distance. Closer nodes (by XOR metric) are queried first, making lookups efficient—O(log N) hops.

Protocol Messages

Ping/Pong - Keep-alive and peer discovery
FindNode - Request nodes close to a target
Announce - Register your peer record in DHT
Query - Find all devices for a handle

All messages use VSF (Versatile Storage Format) serialization for compact, efficient network traffic.

Comparison to Other Systems

Property	DNS	ENS	Namecoin	Tor Onion	FGTW Binding
Decentralized	✗	Partial	✓	✓	✓
Human-readable	✓	✓	✓	✗	✓
No registration fee	✗	✗	✗	✓	✓
No blockchain	✓	✗	✗	✓	✓
Works offline	✗	✗	✗	✗	✓
Collision resolution	Authority	Auction	First-come	N/A	Vouching
Immutable	✗	✗	✗	✓	✓
Social recovery	✗	✗	✗	✗	✓

FGTW combines human-readable names with decentralization, avoiding the tradeoffs of DNS, blockchain, and onion routing.

Technical Details

Cryptographic Primitives

            Hash function: BLAKE3 (faster than SHA-256)

            Signing/Encryption: X25519 (Curve25519 Diffie-Hellman)

            Serialization: VSF - compact binary encoding

            Routing: Kademlia XOR distance (256 buckets, O(log N) lookups)

Network Stack

UDP transport for DHT messages
TLS 1.3 for peer-to-peer messaging
WebSocket over TLS for application layer
All traffic indistinguishable from HTTPS

Integration with Photon

FGTW provides the identity layer for Photon Messenger:

Handle Lookup

Message "alice" without knowing IP or public key—FGTW handles discovery

Multi-Device

All your devices registered under one handle, messages routed automatically

Social Recovery

Key shards distributed to trusted contacts—lose all devices, friends reconstruct your identity

Project Status

FGTW is functional and serving as the identity layer for Photon Messenger.

Current status: DHT, Kademlia routing, and handle registration working. Invite system in development—handles may be reset during this phase.

License: MIT OR Apache-2.0 (dual)

Repository: github.com/nickspiker/photon