nururl

pronounced "neural"

an experimental addressing convention for NomadNet over Reticulum

One destination. More than one possible way in.

An optional connection hint may help you connect. Whether to use it depends on your connectivity and privacy preferences.

A nururl combines a NomadNet destination and page path with an optional entry-peer hint. It lets someone share the page address and a suggested way to reach it in one string.

In this suggested TCP entry, the highlighted address is the entry peer:

hint → repoducible.net:57001

nururl://repoducible.net:57001/72a2d9c12215802605779f4366d48335/page/index.mu

An entry-peer hint suggests a network endpoint through which the client can try reaching the destination. The entry-peer address is the optional part immediately after nururl://. Its spelling identifies the connection type. The entry peer does not identify the resource and does not have to host it.

A compatible client can try connecting through the suggested entry peer. Reticulum then uses its normal mechanisms to find a path to the destination. Without a hint, the client uses its existing connectivity and any interface discovery behaviour it has been configured to allow.

Use case

What does a nururl add?

A Reticulum destination is sufficient to identify a service, but a client may still need time to discover a path to it. A nururl lets the person sharing a resource also share useful knowledge about a promising place to begin that connection.

The hint might identify the device which hosts the resource. It might instead identify a well-connected entry peer which the sender knows has worked or expects to be useful. The sender can therefore share the resource address together with practical connection information.

This can be useful when a destination is newly online, has moved to a different network connection, or is not yet reachable through the recipient's existing connections. A useful hint may reduce connection delay or provide an entry into a network the recipient could not otherwise reach. That still depends on the hinted peer being reachable, permitted, and capable of reaching the destination. First contact, cooperative work, fast-moving projects, and temporary services are possible applications rather than guaranteed improvements.

When the hint names the device hosting the resource, the first connection may feel closer to the familiar Internet experience of receiving a URL containing a directly reachable host. It does not make Reticulum routing equivalent to ordinary Internet routing and it does not guarantee an immediate connection. It supplies knowledge which might otherwise have to be discovered.

The recipient remains in control. A nururl-aware client may use the hint as supplied, compare it with locally known routes, replace it, ask before using it, or ignore it and use its existing Reticulum context. Clients should apply the recipient's connection policy before resolving, contacting, or testing a suggested peer. An unavailable hint may trigger fallback only through connections that policy permits. A recipient may also extract the destination and resource path for use with a client which does not understand the complete nururl.

For the example on this page, its native NomadNet destination-and-path spelling is:

72a2d9c12215802605779f4366d48335:/page/index.mu

Sharing a hint reveals a suggested association between an entry peer and the destination. Following it may expose connection information to that peer or to network observers. The privacy effect depends on the transport, the selected peer, and the alternatives already available. A hint is not automatically faster or less private. Reticulum Link encryption is not removed merely because an entry peer forwards its traffic.

When this web gateway is used, the gateway fetches the page on the recipient's behalf and can see the requested address and returned content. That gateway disclosure is separate from the privacy consequences of an entry hint.

A suggestion, not a requirement

A hint says, in effect, “if you support this interface protocol, here is a suggested place and method with which to begin.” It does not mean that the resource itself requires that protocol or that every later hop will use it.

If a nururl-aware client does not support the hinted interface protocol, it may discard the complete hint and retain the destination, page path, and request variables. It can then use its existing Reticulum interfaces and normal path discovery. The client must not reinterpret an I2P hint as TCP, for example, and should tell the recipient that it ignored the hint because access may take longer or fail. An explicitly restricted context, such as I2P-only, must retain that restriction rather than silently falling back to another transport.

Including a hint also makes different ways of bootstrapping Reticulum visible. A sender can raise awareness of TCP, Yggdrasil, I2P, Tor, or another supported entry mechanism while indicating the transport they prefer or recommend for first contact. This is an operational preference, not a routing command. The recipient remains free to use, replace, or disregard it.

A stable way into a changing network

Reticulum paths and participating nodes may be temporary. A path learned earlier can disappear before the recipient tries to use it. A sender can reduce dependence on such ephemeral entry points by supplying a known, stable, high-availability interface, including infrastructure operated to a five-nines availability target.

The stable hint does not need to host the resource. It supplies a promising place from which to enter the relevant Reticulum network, establish a path, or rediscover one after topology has changed. This can improve the probability and speed of first contact, but it does not make the complete path permanent. The destination service, the hinted interface, or later nodes may still be unavailable.

A hint may be temporary

A hint is connection assistance, not part of the resource's identity. A sender may operate an entry peer or other infrastructure specifically to help the recipient make first contact. If the recipient subsequently establishes another working connection through which the destination remains reachable, the temporary entry peer may no longer be needed. Learning a path through that peer is not, by itself, enough to remove it because the learned path can still name that peer and interface as its way forward.

First sharing, with temporary connection assistance:
nururl://temporary-entry.example/72a2d9c12215802605779f4366d48335/page/index.mu

Later, without the supplied hint:
nururl:///72a2d9c12215802605779f4366d48335/page/index.mu

Both forms identify the same destination and resource. Removing or replacing the hint in a shared address does not change the destination. Removing a hint from an address, disconnecting a local interface, and taking the entry peer offline are three different operations. The later hintless form uses the client's existing context, which may still contain the formerly hinted connection; it does not by itself prove independence from that peer.

If a hint has become stale, a client may disregard it and use another entry point or normal Reticulum path discovery, but only within the recipient's selected connection policy.

A learned path can later expire, topology can change, and the original hint may become useful again. Clients should therefore let recipients retain, replace, or remove hints instead of automatically discarding them after one successful connection.

If the hinted device also hosts the resource and that service is taken offline, the destination remains its identifier but the resource will not be reachable until the service is available again under that identity. A hint cannot keep an offline resource available.

The destination says what to reach. The hint only suggests where to begin.

The page path says which page to request at that destination.

See a hint in a nururl

Choose a connection type to see how its hint is written.

Suggested TCP entrynururl://repoducible.net:57001/72a2d9c12215802605779f4366d48335/page/index.mu

Yggdrasil hintnururl://[200:b857:ddaf:e407:95eb:76f6:ab84:b402]/72a2d9c12215802605779f4366d48335/page/index.mu

Suggested I2P entry

Entry peer: l65asvwjjm62ve4ddgqoergdebnvcri3nw43te4nqqiyqutdewdq.b32.i2p

nururl://l65asvwjjm62ve4ddgqoergdebnvcri3nw43te4nqqiyqutdewdq.b32.i2p/72a2d9c12215802605779f4366d48335/page/index.mu

Suggested Tor onion entry

nururl://edz422kobqpb6tgny6rdvdky5cdrnh5dnzmnn6c2twwebvomk2fdgxyd.onion:4666/72a2d9c12215802605779f4366d48335/page/index.mu

This example uses a reported Reticulum Tor entry. Its inclusion does not guarantee that it is currently available or reaches this destination.

The whole nine yards

Status

nururl is a proposed experimental Reticulum URI format. It is not currently a Reticulum standard and is not registered in the IANA URI Schemes registry.

nururl expands to non-unique Reticulum URL. It is a uniform resource locator for a resource at a specific Reticulum destination address. The destination remains the same while more than one valid nururl can locate it: different nururls may supply different hints, page paths, or request variables. “Non-unique” describes the locators, not ambiguity in the destination address and not immutability of the content served there.

In this convention, the 32-hexadecimal-character value identifies the unique Reticulum destination address being requested. It is not a content hash: the destination may change what it serves over time.

This document defines the experimental nururl 0.1 format targeted by the reticulum.site preview. Implemented restrictions and passing tests are documented separately from requirements and intentions. Implementations must not interpret the examples as permission to create arbitrary interfaces, load configuration files, access local services, or execute commands.

The generic syntax follows RFC 3986. Browser parsing and optional protocol-handler integration are additionally constrained by the WHATWG URL and HTML standards.

Definition

A nururl is an experimental Reticulum URI identifying a NomadNet resource by its destination, page path, and optional request variables. It may include an optional entry-peer hint naming a network endpoint through which the client can try reaching the destination. The entry peer need not host the resource.

Motivation

Reticulum can request and discover a path to a destination through connectivity the client already has. A nururl optionally carries connection information for infrastructure that its author or user expects to provide a useful entry into the relevant Reticulum network. A useful hint may reduce connection delay or provide entry to a network the client could not otherwise reach.

An entry hint is not a guarantee that the named infrastructure is currently available, fastest, or part of the eventual end-to-end route. It is a convenience for reaching Reticulum, not a change to Reticulum routing or the identity of the destination. The destination-only form remains valid.

Sharing a hint reveals the suggested association between an entry peer and a destination. Following it may expose connection information to that peer or to network observers. The effect depends on the transport, selected peer, and alternatives already available; a hint is not automatically faster or less private. A client must apply local connection and privacy policy before resolving, contacting, or testing the peer and may ignore the hint.

A nururl string is intended for a nururl-aware client: software that parses this convention, applies its own connection and security policy, and then asks Reticulum for the identified resource. Such a client may be a native browser, a protocol handler, a web-page form backed by a gateway, a resolver, a command-line client, or a resource fetcher. The format does not prescribe a user interface or require an HTTPS gateway.

An ordinary web browser is not nururl-aware merely because a nururl string is entered into its address bar. It needs a compatible protocol handler, browser integration, or an HTTPS page that accepts the string and performs the nururl operation on the user's behalf.

Reticulum does not normally require a route to be embedded in an application address. If a client already participates in a suitable Reticulum context, the destination-only form is sufficient:

nururl:///8331ef3af688e4153234a5910608dc30/page/index.mu

The network discovers or selects a route to that destination. A non-empty authority is therefore an optional entry hint for a client that needs or wants one, not part of the destination's identity and not a complete end-to-end route. This is why several nururls can refer to the same destination and page.

Canonical structure

nururl://authority/destination/page/path?query

Version 0.1 assigns these meanings:

URI component	nururl meaning
Scheme	`nururl` identifies this experimental format.
Authority host and port	Optional Reticulum entry-peer hint.
First path segment	NomadNet application destination.
Remaining path	NomadNet request path at that destination.
Query	nururl controls and namespaced NomadNet variables.

The destination is a 16-byte Reticulum destination hash represented as exactly 32 hexadecimal characters. Canonical output uses lowercase hexadecimal.

The entry peer is a route hint, not the entry peer's Reticulum identity, transport-node hash, or proof of the interface actually used. The destination identifies the service the client intends to reach.

Grammar

The following grammar is descriptive; the validation rules are normative.

nururl        = "nururl://" authority resource [ "?" query ]
authority     = tcp-authority | i2p-authority | tor-authority | empty
resource      = "/" destination page-path
destination   = 32HEXDIG
page-path     = "/page/" page-name
tcp-authority = dns-name [ ":" port ]
              | ipv4 [ ":" port ]
              | "[" ipv6 "]" [ ":" port ]
i2p-authority = canonical-52base32 [ ".b32.i2p" ]
tor-authority = canonical-56base32 ".onion" [ ":" port ]

A missing TCP or Tor port means 4242. An explicit port is from 1 through 65535. IPv6 literals must use square brackets. The destination is the first path segment; there is no colon after it.

Authorities are classified before ordinary DNS handling. A validated .onion authority is Tor; a canonical I2P authority or reserved 52-character shorthand is I2P; every other accepted host or IP authority is TCP. An empty authority supplies no entry hint. The reserved Tor and I2P forms must never fall through to TCP or DNS.

Page paths are case-sensitive and retain their original case.

TCP entry peer

An authority which is not one of the reserved I2P or Tor forms is a Reticulum TCPClientInterface entry hint:

nururl://repoducible.net:57001/8331ef3af688e4153234a5910608dc30/page/index.mu

The default TCP port may be omitted:

nururl://repoducible.net/8331ef3af688e4153234a5910608dc30/page/index.mu

That example means TCP port 4242. Canonical output omits port 4242 and retains every non-default port. A port is never added to an I2P authority.

IPv6 and Yggdrasil entry peer

IPv6 literals remain bracketed so the authority port is unambiguous:

nururl://[200:b857:ddaf:e407:95eb:76f6:ab84:b402]/8331ef3af688e4153234a5910608dc30/page/index.mu

Yggdrasil-over-TCP uses this same form. The executing client must already have the required Yggdrasil connectivity.

No entry-peer hint

An empty authority means that the client must use its selected local Reticulum context without adding an entry interface:

nururl:///8331ef3af688e4153234a5910608dc30/page/index.mu

This spelling has three slashes after the colon: two introduce the empty authority and one begins the resource path. It supplies no entry-peer hint and must not mean localhost or cause processing to invent an entry interface. Existing interfaces and the selected context's independently configured behaviour remain client policy. Any credentials or other interface configuration must already exist locally; nururl does not encode them.

Shared Instance, AutoInterface, I2P-only, Yggdrasil-only, or other execution profiles are client policy. They do not produce different resource addresses.

Native I2P entry peer

Native I2P uses a canonical traditional 52-character .b32.i2p authority with no port:

nururl://l65asvwjjm62ve4ddgqoergdebnvcri3nw43te4nqqiyqutdewdq.b32.i2p/8331ef3af688e4153234a5910608dc30/page/index.mu

The .b32.i2p suffix may be omitted on input:

nururl://l65asvwjjm62ve4ddgqoergdebnvcri3nw43te4nqqiyqutdewdq/8331ef3af688e4153234a5910608dc30/page/index.mu

An authority consisting of exactly 52 canonical lowercase Base32 characters and nothing else is reserved as abbreviated I2P. Canonical output restores the .b32.i2p suffix. Although DNS syntax permits a single label of up to 63 characters, a canonical I2P-shaped label must never be resolved or connected through ordinary DNS/TCP by a nururl-aware client. This deliberate reservation prevents an I2P peer copied without its suffix from leaking to DNS.

Some Reticulum interface displays append the generic :4242 field to a bare I2P peer. Version 0.1 accepts that exact paste-compatible spelling as I2P and removes the port during canonicalization. Any other port on a bare I2P-shaped label is rejected. A full .b32.i2p authority with any port is also rejected. Adding a port can therefore never turn an I2P-shaped authority into TCP. A hypothetical TCP service with the same single-label spelling must use an unambiguous dotted hostname instead.

The authority becomes an RNS I2PInterface peer. A local profile name such as webvm is not portable and does not belong in a nururl unless it is a valid, independently resolvable TCP authority.

The I2P spelling identifies the hinted entry mechanism. It does not guarantee that a shared Reticulum daemon used an I2P-only path. An explicitly selected I2P-only execution profile must fail rather than silently use a clear-network route.

Version 0.1 supports traditional destination-hash addresses only. Extended Base32 addresses for encrypted LeaseSets are outside its scope. A label matches [a-z2-7]{51}[aq]; the final character restriction enforces zero Base32 padding bits.

Tor onion entry peer

A canonical Tor v3 onion-service address identifies a suggested Reticulum entry peer reached through Tor:

nururl://edz422kobqpb6tgny6rdvdky5cdrnh5dnzmnn6c2twwebvomk2fdgxyd.onion:4666/72a2d9c12215802605779f4366d48335/page/index.mu

This example uses a reported Reticulum Tor entry and its explicit port. Its inclusion does not guarantee that it is currently available or that it reaches the example destination. The 56-character Base32 label encodes a 32-byte public key, a two-byte checksum, and version byte 3. A nururl-aware implementation must decode and verify the version and checksum before accepting it. Version 2 onion names, malformed labels, and invalid checksums are rejected.

The default Reticulum TCP service port is 4242 and is omitted from canonical output. A different onion-service port is explicit:

nururl://edz422kobqpb6tgny6rdvdky5cdrnh5dnzmnn6c2twwebvomk2fdgxyd.onion:4666/72a2d9c12215802605779f4366d48335/page/index.mu

The .onion authority itself selects Tor without additional query metadata. A compatible client sends the onion hostname to Tor using the SOCKS domain-name address form. It must not resolve the hostname through ordinary DNS or connect to it as ordinary clear-network TCP.

A Tor hint describes an outbound-initiated, full-duplex connection. Once the client has connected to the onion entry peer, Reticulum requests can travel outward and responses, announces, and discovery data can return over the same connection. This does not require the client to publish an onion service or accept new, unsolicited inbound Tor connections.

Unsupported or disregarded hints

A valid hint remains advisory. If a nururl-aware client understands the format but does not support its hinted interface protocol, local policy may allow the client to discard the complete hint and retain the destination, page path, and request variables. It may then continue through its existing Reticulum context. The client should report that the hint was ignored because connection may take longer or fail.

The client must not reinterpret an unsupported hint as another connection type and must apply connection policy before resolving, contacting, or testing the suggested peer. An explicitly restricted context, such as I2P-only, must not silently fall back to direct TCP.

A client which does not support Tor may discard a Tor hint under the same policy and retain the resource components. It must never reinterpret a .onion authority as ordinary TCP or DNS.

Query parameters

nururl 0.1 uses the authority spelling to determine the connection type. Every query name must begin with nn.; every other query name is invalid and must be rejected. Implementations must not guess.

Query fields use UTF-8 application/x-www-form-urlencoded encoding, are separated by &, and split at their first =. + decodes to space; a literal plus is %2B. Empty values are preserved. Empty fields, names without =, a bare trailing ?, malformed percent escapes, and invalid UTF-8 are rejected. Names are decoded before case-sensitive namespace validation and duplicate detection, so nn.x and nn%2Ex are duplicates. Every decoded name must begin with nn.; every other name is rejected.

NomadNet request variables use the nn. namespace:

nururl://repoducible.net:57001/8331ef3af688e4153234a5910608dc30/page/blob.mu?nn.g=public&nn.r=reticulum_nixos_flake_rngit_mirror&nn.ref=HEAD&nn.path=README.md&nn.render=y

The nururl handler removes the nn. prefix and passes structured request data:

{
  "var_g": "public",
  "var_r": "reticulum_nixos_flake_rngit_mirror",
  "var_ref": "HEAD",
  "var_path": "README.md",
  "var_render": "y"
}

NomadNet's native representation appends request variables to a page target. A backtick introduces the variable fields, a vertical bar separates fields, and each field is a name=value pair. For example:

72a2d9c12215802605779f4366d48335:/page/wiki.mu`path=RRC|format=micron

NomadNet supplies those fields to the page application as var_path=RRC and var_format=micron. This backtick-and-pipe convention is real NomadNet application syntax; it is not part of RFC 3986 and is not canonical nururl syntax. The equivalent canonical nururl is:

nururl:///72a2d9c12215802605779f4366d48335/page/wiki.mu?nn.path=RRC&nn.format=micron

A nururl-aware client translates decoded nn.name=value fields into the structured NomadNet request variable var_name=value. It must not construct the native delimiter string and parse it again, because values containing a backtick or vertical bar would otherwise be ambiguous. Implementations may accept the native form as legacy input, but canonical output uses the nn. query representation and percent-encodes values according to the rules above.

Each encoding layer is decoded exactly once. Malformed percent escapes, control characters, and ambiguous duplicate parameters are rejected.

Relative NomadNet links

Generic URI resolution cannot safely interpret NomadNet page links because a root-relative link would remove the destination path segment. For example, resolving /page/repo.mu generically would produce an address without the destination.

A Micron-to-HTML adapter must therefore:

interpret the source link according to NomadNet semantics;
retain or replace the intended destination explicitly;
retain the selected entry hint for same-destination links; and
construct a new complete nururl or HTTPS gateway URL.

It must not blindly resolve Micron links against either the outer HTTPS URL or the nururl.

Application variables come from the target link and are not inherited from the previous request. A destination change requires a fresh policy check. Unsupported links remain inactive. Native same-destination links such as :/page/repo.mu follow these rules.

HTTPS gateway wrapper

Ordinary browsers do not automatically know how to open an experimental nururl: scheme. Public sharing therefore uses an HTTPS gateway wrapper whose uri parameter contains one percent-encoded nururl:

https://reticulum.site/open?uri=nururl%3A%2F%2Frepoducible.net%3A57001%2F8331ef3af688e4153234a5910608dc30%2Fpage%2Findex.mu

The wrapper and the inner nururl have separate roles:

Value	Role
`reticulum.site`	HTTPS gateway contacted by the browser.
`repoducible.net:57001`	Entry peer contacted by that gateway.
`8331…dc30`	NomadNet destination reached through Reticulum.

The gateway is not part of the portable nururl. Another compatible gateway can accept the same inner address.

Construct wrapper query values with a structured URL encoder. Never interpolate an unescaped nururl into the outer query.

The /open?uri= endpoint described here is part of the v0.1 design. Its presence in an example does not claim that a deployment has implemented it.

Optional browser integration

An HTTPS gateway may offer the browser-handler alias web+nururl: with exactly the same component meanings:

web+nururl://repoducible.net:57001/8331ef3af688e4153234a5910608dc30/page/index.mu

A same-origin gateway page can offer registration conceptually as:

navigator.registerProtocolHandler("web+nururl", "/open?uri=%s");

Registration and invocation depend on browser support and user choice. The HTTPS wrapper is this preview's sharing method for browsers without a compatible handler; it is not required of native clients.

Supporting web+nururl: does not make nururl: a registered or natively handled browser scheme.

Parsing and normalization

An implementation must validate the representation it actually receives before using a parser that can remove or normalize syntax. Parser success is not proof of nururl validity. It must then parse generic URI component boundaries and validate each decoded component before use.

Only nururl and an explicitly supported alias such as web+nururl are accepted. Credentials, all fragment components (including an empty trailing #), malformed escapes, controls, duplicate decoded query names, and unknown query names are rejected. Destination, page path, and authority are validated independently. A browser protocol handler may already have serialized or removed input characters; the receiver can validate only what it receives.

Split paths into encoded segments before decoding. Decode each segment once as strict UTF-8. Reject empty, . and .. segments, controls, and decoded / or \. Subdirectories are permitted; the page name is not empty. The 512-byte limit measures the decoded UTF-8 request path, separately from the whole-input limit.

The authority profile accepts ASCII DNS names without a trailing dot, four-decimal-octet IPv4, bracketed RFC 5952 IPv6 without zone identifiers, and decimal ports 1–65535 without leading zeroes. Rejected numeric IP spellings do not fall through as DNS. Canonical I2P-shaped labels and .b32.i2p names are handled before TCP or DNS. A .onion name is reserved for a validated Tor v3 authority and is likewise handled before TCP or DNS.

Canonical output uses nururl, lowercase DNS and destination text, uppercase hexadecimal percent escapes, RFC 5952 IPv6, minimal non-default decimal ports, the full .b32.i2p spelling, and stable query-name ordering. It omits empty queries and default port 4242 from TCP and Tor authorities. web+nururl input canonicalizes to nururl. Canonicalization is idempotent and preserves the parsed destination, hint, path, variables, and connection type.

Legacy input accepted by reticulum.site may include:

repoducible.net:57001/8331ef3af688e4153234a5910608dc30:/page/index.mu

It normalizes to:

nururl://repoducible.net:57001/8331ef3af688e4153234a5910608dc30/page/index.mu

Legacy input compatibility does not change the canonical v0.1 grammar.

Security boundaries

nururl syntax defines addressing data, not permission. A public gateway must apply a separate connection policy before acting on an entry hint.

The preview policy is intended to apply destination and page allowlists, bounded query data, connection and response limits, renderer isolation, and explicit overlay allowlists. Implemented and tested controls are deployment documentation; this format specification does not by itself establish DNS- rebinding resistance or other operational safeguards. A conforming nururl may be refused by gateway policy without becoming invalid.

The entry peer is only a hint. It does not prove which interface a shared daemon used. Isolated route tests must enforce and report their actual execution profile.

“Read-only” describes operations offered by the preview UI. It does not prove that requesting an arbitrary NomadNet page has no server-side effect: page programs may interpret request variables. The preview permits only reviewed destinations, paths, and variable combinations. Values must not contain secrets.

The HTTPS gateway can see the destination, entry hint, request variables, and retrieved content. It does not provide browser-to-NomadNet end-to-end confidentiality. Rendered content and secondary fetches must not gain access to unapproved networks, local files, or execution facilities.

The reticulum.site preview contacts a suggested onion peer through its outbound Tor client. The web gateway can still see the requested nururl and the content it fetches. It does not provide an onion gateway or onion service.

An “I2P-only” worker uses only its approved I2P entry context. It cannot prove which transports other Reticulum nodes use beyond that entry.

Version 0.1 validation profile

The current preview implementation is tested against at least these limits; deployment and egress controls are reported separately:

destination: exactly 32 hexadecimal characters;
complete encoded input: at most 2048 bytes;
decoded page path: begins with /page/, follows the segment rules above, and is at most 512 UTF-8 bytes;
NomadNet variables: at most 16 unique nn. keys;
variable names: 1–32 ASCII alphanumeric, _, or - characters after the prefix;
variable values: at most 512 bytes each after one percent-decoding step;
native I2P authority: [a-z2-7]{51}[aq](\.b32\.i2p)?, with the narrow bare :4242 input compatibility described above;
Tor v3 authority: exactly 56 canonical lowercase Base32 characters followed by .onion, with a valid version byte and checksum;
TCP and Tor port: omitted for 4242 or explicit and within 1–65535;
.onion authorities are never DNS names; and
no credentials, duplicate keys, or unknown query parameters.

Connection attempts, total request time, temporary interface lifetime, response size, and renderer work are independently bounded by preview policy; they are not universal syntax limits.

Version 0.1 has no version field. Later documents must not silently reinterpret strings valid under this version; incompatible semantics require a distinct scheme or an explicitly negotiated future mechanism.

Non-goals for v0.1

Version 0.1 does not encode:

multiple simultaneous entry hints;
arbitrary Reticulum aspects or request paths;
execution profiles or local configuration names;
files, media downloads, or mutable form submissions;
credentials or authorization; or
permission to install interfaces or access arbitrary network services.

Registration

Public adoption should publish a stable specification and seek provisional URI-scheme registration under RFC 7595. Registration documents and reserves a scheme name; it does not install a browser handler or guarantee browser support.