Proposal: consent-gated, human-usable identifiers to complement SimpleX token-links

SimpleX solves a core problem better than anyone else:
no global identifiers, no metadata graph, no unsolicited reachability.

What remains unsolved is not cryptography, but human reachability outside the browser:
token-links are still URLs — long, non-memorable, and impractical to dictate via voice, radio, posters, CVs, or other offline contexts.

This proposal introduces a human-usable identifier that stays fully aligned with SimpleX principles because it is inert by default and permission-gated.

---

1. Definitions (fixed)

UID = block 1 + block 2

tail = block 3 (purpose / scope)

The UID is stable.
The tail is contextual, disposable, and controllable.

---

2. Fundamental rule (entire model in one line)

UID + tail + successful handshake → goal

Anything else results in:

→ nothing

This rule is absolute.

---

3. What an UID is — and is not

An UID is not an address

An UID is not a capability

An UID is not reachable

An UID cannot be called, messaged, or pinged

Possessing a valid UID alone grants zero ability to contact the user.

This replaces the historical telecom assumption:

“If you know the number, you can reach the user.”

with:

“If you know the UID, you may only request permission.”

---

4. UID format (human-first, machine-safe)

Alphabet

Base32, uppercase only, excluding visually ambiguous symbols:

Excluded: O, I, S, Z
Included: 0–9 + 22 letters = 32 symbols

Chosen for:

voice dictation

radio transmission

OCR / camera capture

zero visual ambiguity

Structure

Three blocks, same separator, left-to-right only:

BBBB-BBBB-CCCC

BBBB-BBBB → UID

CCCC → tail

Example:

K7M9-AQ3D-L4X2

Readable, speakable, printable — unlike URLs.

---

5. Purpose-scoped tails (structural anti-spam)

The tail is mandatory and represents why someone is trying to reach you.

A user may expose different tails for:

work

friends

public broadcast (radio, events)

temporary contexts

Each tail can be:

enabled / disabled

rate-limited

time-bounded

revoked

If a tail is abused, it is killed without burning the UID.

---

6. Handshake: the only activation event

The handshake is mandatory and non-customizable.

Flow:

1. A requester declares intent using their own UID

2. The system generates a neutral system message

3. The recipient may:

accept → goal is created

reject → silent drop

ignore → automatic expiry

Properties:

no custom text → no social engineering

no rejection feedback → attacker learns nothing

no oracle (“exists / doesn’t exist”)

---

7. Why knowing everything still gives nothing

Even if an attacker knows:

a valid UID

a valid tail

the full identifier string

Without a successful handshake:

no call

no message

no notification

no signal

no feedback

UID alone → nothing
UID + tail → nothing

Only this creates a capability:

UID + tail + successful handshake → goal

---

8. Spoofing and replay resistance

Spoofing fails because:

no UID maps directly to a channel

the handshake creates a pair-specific, non-replayable link

approval is explicit and local to the recipient

Cloning an UID or a tail does not clone the relationship.

---

9. Relation to SimpleX token-links

Aspect SimpleX token-links UID + tail

Anonymity Strong Pseudonymous
Reachability Anyone with link Consent-gated only
Human usability Poor (URL) High (voice, radio, print)
Offline sharing Difficult Native
Spam resistance High Structural

This model does not replace token-links.

Token-links remain ideal for pure anonymity.
UIDs solve real-world discoverability without re-introducing spam.

A SimpleX client could internally:

resolve an approved UID handshake into a SimpleX connection

keep transport, routing, and metadata guarantees unchanged

---

10. One-sentence summary

The UID is human-friendly but inert; only UID + tail + an explicitly approved handshake creates a communication goal.

The proposal names no implementation files, tests, or entry points. Start by locating the existing SimpleX token-link and client handshake paths, then determine whether the UID and tail model fits without changing the stated privacy guarantees. Done would require an agreed design and implementation scope, followed by relevant protocol and client tests.