// Reticulum's addressing system and destination types. Use when working with destination types (SINGLE, GROUP, PLAIN, LINK), destination hashes, aspect naming, or addressing.
| name | destinations |
| description | Reticulum's addressing system and destination types. Use when working with destination types (SINGLE, GROUP, PLAIN, LINK), destination hashes, aspect naming, or addressing. |
This skill provides knowledge about Reticulum's addressing system and destination types. Invoke when the user mentions destination types, single destination, group destination, destination hash, aspect naming, or addressing.
Destinations are Reticulum's addressing system, replacing IP addresses and ports. Each destination is identified by a 16-byte (128-bit) hash derived from cryptographic identity and naming information.
Key property: Destinations are location-independent. The same destination hash works regardless of network topology or physical location.
SINGLE = 0x00 # Encrypted with recipient's public key (asymmetric)
GROUP = 0x01 # Encrypted with shared key (symmetric)
PLAIN = 0x02 # Unencrypted, broadcast only
LINK = 0x03 # Abstract encrypted channel
Purpose: Encrypted communication to one specific recipient
Properties:
Use cases: Private messages, RPC calls, file transfers
Purpose: Encrypted communication to multiple recipients sharing a key
Properties:
Use cases: Private group chat, multicast notifications
Purpose: Unencrypted broadcast information
Properties:
Use cases: Local service discovery, beacons, public announcements
Purpose: Established encrypted channel between two nodes
Properties:
Use cases: Interactive sessions, streaming data, reliable messaging
Destination hash is 16 bytes (128-bit truncated SHA-256).
# Step 1: Create full name without identity
app_name = "myapp"
aspects = ["service", "function"]
full_name = app_name + "." + ".".join(aspects)
# Result: "myapp.service.function"
# Step 2: Calculate name hash (first 10 bytes of SHA-256)
name_hash = SHA256(full_name)[:10] # 80 bits
# Step 3: Calculate identity hash (first 16 bytes of SHA-256 of public key)
identity_hash = SHA256(public_key)[:16] # 128 bits
# Step 4: Combine and hash to get destination hash
combined = name_hash + identity_hash # 26 bytes
destination_hash = SHA256(combined)[:16] # Final 128-bit address
# GROUP destinations hash ONLY the name - same algorithm as PLAIN
# The group key is used for ENCRYPTION, not address calculation
# Step 1: Create full name
full_name = "myapp.group.channel"
# Step 2: Calculate name hash (first 10 bytes)
name_hash = SHA256(full_name.encode('utf-8'))[:10]
# Step 3: Hash the name_hash to get destination hash
destination_hash = SHA256(name_hash)[:16]
# Note: Group key is set separately via set_group_key()
# and encrypts/decrypts packets, not part of address
# PLAIN uses the same algorithm as GROUP
full_name = "myapp.broadcast.beacon"
name_hash = SHA256(full_name.encode('utf-8'))[:10]
destination_hash = SHA256(name_hash)[:16]
Destinations use hierarchical dotted notation:
app_name.aspect1.aspect2.aspect3...
Rules:
Examples:
"fileserver.files""chat.group.engineering""sensor.temperature.outdoor""lxmf.delivery"Name hash (10 bytes): Hash of name string only, without identity
Destination hash (16 bytes): Final unique address
Addresses displayed as hex enclosed in angle brackets:
<13425ec15b621c1d928589718000d814>
<a5f72aefc8e8679e9f4a5a0a1b2c3d4e>
This is the destination_hash in hexadecimal.
Destinations can require proof of delivery:
PROVE_NONE = 0x21 # No proofs required
PROVE_APP = 0x22 # Application decides per-packet
PROVE_ALL = 0x23 # Proof required for every packet
PROVE_NONE: Fast, no delivery confirmation. Use for non-critical data.
PROVE_APP: Application sets proof requirement per packet. Flexible approach.
PROVE_ALL: Every packet must be proven. Reliable but higher overhead.
Note: The default proof strategy for new destinations is PROVE_NONE.
With 128-bit hashes:
SINGLE destinations embed public key in destination hash calculation:
Purpose:
Process:
Result: Only the holder of the private key can decrypt packets to that destination.
Destinations can use ratchets for forward secrecy on announces:
RATCHET_COUNT = 512 # Number of ratchet keys to retain
RATCHET_EXPIRY = 2592000 # 30 days
RATCHET_INTERVAL = 1800 # 30 minutes between rotations
When ratchet enabled:
IN = 0x11 # Destination receives packets (server)
OUT = 0x12 # Destination sends packets (client)
IN: Accepts inbound packets. Creates receiver. Used for services.
OUT: Sends outbound packets. No receiver. Used for clients.
IN destinations can register callbacks:
destination.set_packet_callback(handler_function)
destination.set_proof_strategy(PROVE_ALL)
packet_callback: Function called when packet received link_established_callback: Called when link established to this destination
SINGLE and GROUP destinations can announce their presence:
destination.announce()
Announce packet contains:
See announce-mechanism skill for details.
# SINGLE destination (IN)
destination = RNS.Destination(
identity, # Identity object
RNS.Destination.IN, # Direction
RNS.Destination.SINGLE, # Type
"app_name", "aspect1" # Name components
)
# GROUP destination (identity is optional — if None and IN, one is auto-created)
destination = RNS.Destination(
identity, # Identity object (or None for auto-create)
RNS.Destination.IN,
RNS.Destination.GROUP,
"app_name", "group_name"
)
destination.set_group_key(group_key) # 32-byte key
# PLAIN destination
destination = RNS.Destination(
None, # No identity for PLAIN
RNS.Destination.IN,
RNS.Destination.PLAIN,
"app_name", "broadcast"
)
Transport layer maintains destination registry:
For detailed specifications:
references/destination-types.md - Type comparison tablereferences/naming.md - Naming rules and restrictionsreferences/addressing.md - Hash calculation algorithm detailsreferences/wire-examples.py - Complete hash calculation examplesRelated skills:
packets-wire-format - How destination hash appears in packetsannounce-mechanism - How destinations announce themselvescryptography-identity - Identity and key generationlinks - LINK destination type detailsSource References:
https://github.com/markqvist/Reticulum/RNS/Destination.pyReticulum's cryptographic primitives, identity structure, encryption tokens, and key derivation. Use when working with Ed25519, X25519, identity hashes, HKDF, token format, encryption, signatures, ratchets, or key derivation.
Reticulum's hardware abstraction layer and interface types. Use when working with RNode, AutoInterface, TCP, UDP, I2P, Serial, KISS, BLE interfaces, interface modes, IFAC, bandwidth allocation, or MTU.
Reticulum's link system — encrypted channels with forward secrecy. Use when working with link establishment, link requests, ECDH, ephemeral keys, forward secrecy, channels, keep-alive, or link timeouts.
Reticulum's packet structure and wire format. Use when working with packet headers, MTU/MDU, packet types, header types (HEADER_1/HEADER_2), packet context flags, IFAC, or binary packet encoding.
Detailed knowledge of Reticulum's announce mechanism for automatic path discovery. Use when working with announce propagation, path discovery, announce bandwidth, announce forwarding, path requests, or announce structure.
Reticulum's resource transfer system for large data over links. Use when working with resource transfers, windowing, hashmaps, segments, compression, file transfers, or resource states.