One-way invite, mutual trust

The half-finished relationship

Contact invites feel like they should work like friend requests: accept once, done.

NT² splits the problem into two layers on purpose.

When you accept someone's invite, you gain something real: their vault identity in your Contacts, their signing key material to verify packages, and a path to review what they send in Inbox.

That is one-way trust from their vault toward yours as a recipient. You can say, with cryptographic help, "this package matches the vault I saved as Amara's brother."

What you may not have yet is mutual trust — the symmetric setup where your vault can send encrypted shares to theirs through the same relationship.

If that sounds asymmetric, it is. Asymmetry is a feature, not a bug.

Why one-way comes first

Imagine Amara's brother sends her his share of the rent payment details first. She accepts the asset share into her vault. Good.

Next month she wants to send her IBAN back through the same structured path — not another screenshot.

For that outbound share, her vault needs the encryption material tied to his vault as a recipient. That arrives when he completes the reciprocal part of the invite exchange: his ContactInvite with his Vault Key DID and the peer keys NT² uses for vault-to-vault encryption.

Until that reciprocal step finishes, NT² may block Mode A send with an in-app hint rather than let you encrypt to a half-known contact. The product prefers a clear "relationship incomplete" state over a silent wrong recipient.

The reciprocal invite in plain steps

You already invited them, or they invited you first. Either way, mutual trust needs both directions to exchange invites:

1. Side A shares an invite QR or link.
2. Side B accepts and saves A as a contact.
3. Side B sends their reciprocal invite back.
4. Side A scans B's reciprocal invite on the pending contact row.

When that closes, both vaults hold each other's identities and peer encryption material for ongoing vault-to-vault sharing.

Display names can lie. Fingerprints and completed exchanges cannot be faked by typing the wrong name in a chat header.

A human rhythm, not a technical ritual

The reciprocal step maps to real life:

• Your co-founder sends you production read keys first; you send staging credentials back after deploy planning.
• Your partner receives insurance documents you shared; later you receive their policy number through the same trust path.
• Your sibling receives rent details; next month you send your transfer reference fields back.

Each direction is a decision. Mutual trust means both directions have a vault identity attached, not that trust is permanent or blind.

What one-way trust still gives you

Even before mutuality completes, one-way trust is useful:

• Verify signatures on inbound packages.
• Accept into vault or decline in Inbox with context.
• See who sent an asset share instead of treating it as an anonymous file.

The recipient story matters as much as the sender story. Read Something arrived in my Inbox for that side.

Where contacts fit in the bigger picture

Contacts are how NT² names trust relationships between vaults. Mutual completion is how those relationships become two-way highways instead of one-way delivery lanes.

For how contacts differ from your phone address book, read Secure contacts are trust relationships. For why "verified" is not a button you press, see the next post: Verified trust is cryptographic, not a button.

Follow the series via RSS.