Receive Addresses and Messaging Across Nodes
Overview
A Receive Address is a destination for private one-to-one messages. People on other UnoLock nodes can send to it, and you can send to theirs, through the same messaging flow you use for any other address.
Clients create, encrypt, sign, verify and decrypt messages. Home nodes address, queue, relay, rate-limit and hold the sealed bytes. The node never needs to read a message to deliver it.
Addresses are fixed to their node
Each Receive Address is fixed to its original node's onion service for security.
- When the address is set up, your client checks a route challenge that names your home node's onion service and signs the route with a private key that only the client holds.
- The node verifies that signature, seals the route, and publishes only the sealed value to the lookup network.
- The authorization fixes the address to the original node's onion service for its lifetime.
This is a security property: a later change in the lookup network cannot silently redirect a known address to another node.
Route pins
When a sender's node first verifies the sealed route for an address, it pins that route before contacting the target.
- Pins are stored separately from expiring lookup data, in the node's encrypted SQLite database.
- Restarts and later lookup-network changes cannot replace a pin.
- Verified public-key pins also persist without automatic expiry.
- When pin capacity is full, new pins are rejected rather than evicting known bindings.
Pins are trust history. Back them up with the node database. Clearing them, or restoring an older snapshot, loses the corresponding trust history. See Backup and Recovery.
Never clear pins to force an address move
Deleting trust pins does not make a changed destination legitimate. If an address needs to live somewhere else, create a new address.
Receiving while you are offline
Your receiving client can stay closed. The node refreshes the published route using the stored client authorization, without asking your client to sign again, so the client can remain offline indefinitely while the node and the address remain active.
The hosting node receives messages while your client is closed, subject to its admission, storage and retention policy. An offline client does not need to be online, but the hosting node does: an offline client cannot make an offline hosting node reachable.
Standing route authorization does not override address deletion, expiry, policy or message retention limits.
Moving to a new onion service
Moving to a different onion service requires a new Receive Address. Republishing does not move an existing address, and neither expired lookup data nor failed publication allows an address to move to another node.
- Share the new address with senders through the normal trusted address-sharing flow.
- If the original node is unavailable, delivery follows its normal retry limits; it does not accept a replacement binding.
- A host outage does not make an old address transferable.
Recovering the same node is not a move
Replacing hardware or failing over to a standby keeps addresses working only when it preserves the same node's onion identity and encrypted state. That is recovery, not an address move. See Backup and Recovery and High Availability.
How messages travel
- The sending browser seals the message. It signs the message header, then encrypts it to the destination's public encryption key. Subject, body, labels, filenames, Space names, command data and user-authored metadata stay sealed.
- The sending node takes custody. It stores the outbound item before delivery.
- The sending node resolves the destination. It checks its persistent pin for the address and queries the lookup network only for an unknown address. It opens the sealed route and verifies the client signature before contacting any onion service.
- The sending browser checks the keys. The destination node supplies its public encryption and validation keys, and the sending client checks them against the commitments embedded in the full Receive Address. A conflicting answer fails closed.
- The message crosses Tor. The sending node delivers the envelope to the destination node's onion service. The receiving node stores it durably before it acknowledges custody. Failures before custody are retried with bounded backoff, and duplicate envelopes are handled idempotently.
- The receiving browser opens it. After decryption, the receiving client verifies the signature before it trusts the sender's identity or acts on any command the message carries.
The custody acknowledgement says only that a node accepted the bytes. It is not proof that the recipient read or accepted the message, and it does not reveal whether a destination exists, is enabled, or accepted the message.
Attachments
Attachments are encrypted before storage. Accepting a message records a bounded descriptor for each attachment rather than copying the bytes immediately. When you open, save or explicitly retrieve an attachment, the encrypted object is imported and its encrypted length and digest are verified. Partial imports are not shown as complete files.
Contacts are labels, not proof
A Contact label is not cryptographic proof of who controls an address. Exchange Receive Addresses through a channel you trust, and never exchange Safe recovery material, passkeys or administrator codes.
Full reference
FAQs
Do I have to keep my Safe open to receive messages?
No. Your receiving client can stay closed while the hosting node and the address remain active. The node receives messages under its normal admission, storage and retention policy.
Can someone redirect my Receive Address to a different node?
No. The address is fixed to its original node's onion service, and verified route pins persist across restarts. A later lookup-network change cannot replace them.
I moved my Safe to a different node. Does my old address follow me?
No. Moving to a different onion service requires a new Receive Address that you share with senders. Republishing does not move an existing address.
Does a delivery acknowledgement mean the recipient read my message?
No. It only means a node took custody of the encrypted bytes. It does not prove the recipient read or accepted the message.
What happens if the recipient's node is offline?
Delivery is retried within bounded retry limits. The message is not rerouted to another node.