Stats
Actions
Tags
From reticulum-protocol
Reticulum's addressing system and destination types. Use when working with destination types (SINGLE, GROUP, PLAIN, LINK), destination hashes, aspect naming, or addressing.
How this skill is triggered — by the user, by Claude, or both
Slash command
/reticulum-protocol:destinationsThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.pynpx claudepluginhub torlando-tech/reticulum-skills --plugin reticulum-protocolProvides Data Availability storage patterns for Ritual dApps using StorageRef for off-chain providers like GCS, HuggingFace, Pinata. Covers credentials, error handling, DKMS encryption for precompiles like multimodal, FHE, LLM, agents.
Build decentralized P2P apps in Rust with Iroh for QUIC-based networking, NAT hole punching, content distribution, document sync, and gossip protocols.
Implements Cloudflare Durable Objects for stateful coordination in real-time apps like chat rooms, multiplayer games, WebSocket hibernation, alarms, and SQLite storage.