taior-URI

Lightweight URI scheme for Taior / AORP resources. It encodes how clients reference destinations, payloads, and routing hints inside the Taior overlay without leaking long-lived identifiers.

What it is

• Scheme: taior://
• Purpose: Provide a compact, privacy-aware way to express where a message/file should go in the Taior network.
• Scope: Logical addressing and hints; it does not transport data by itself.

Why it exists

• Avoids reusing IPs/hosts that could fingerprint senders/receivers.
• Carries only ephemeral, non-linkable identifiers compatible with rotating identities.
• Works with probabilistic routing so no single hop learns the full path.

URI structure (draft)

taior://<destination>?k=<ephemeral_key>&p=<profile>&t=<ttl>&h=<hops>

• <destination>: logical recipient handle or rendezvous point (ephemeral or blinded).
• k (optional): ephemeral public key or reference for envelope encryption.
• p (optional): routing profile (e.g., low-latency, high-privacy).
• t (optional): time-to-live hint.
• h (optional): hop budget or mix depth hint.

All fields are short-lived; clients should rotate values frequently.

How it is used

1. Client builds the URI using current ephemeral identity and desired routing profile.
2. URI is embedded in envelopes or manifests carried by Taior messages/files.
3. Nodes read only the hints relevant to their hop; the full URI is not logged or persisted.

Relation to other repos

• taior-protocol: Defines the routing and packet rules this URI scheme aligns with (see PROTOCOL/ docs for semantics of profiles, TTL, and hop hints).
• libtaior: Provides reference parsing/validation helpers so clients can construct and consume taior:// URIs safely.

Status

Draft / research. Expect breaking changes while the scheme stabilizes.

Contributing

Propose changes via issues or small PRs after discussing expected privacy impact. Keep identifiers ephemeral and non-linkable by design.