Staging — blog preview only.
Skip to content

Secure contacts are trust relationships, not a phone address book

Scheduled

4 min read By NT²

You share rent details with your sister every month. You should not have to find her vault identity in a chat thread each time — or paste the wrong person by mistake.

The wrong address book

Most people already have a Contacts app on their phone. It stores names, numbers, and email addresses for people you call or message.

NT² Contacts is not that.

It is a per-vault trust list: people you are willing to recognize as vault identities when sensitive data moves between you. Each vault on your device has its own list. Your work vault’s contacts are not your family vault’s contacts.

That distinction matters the first time you share a Bank item with a sibling, or a Credential item with a co-founder. The question is not “what is their phone number?” It is “which vault am I trusting for this handoff?”

Sharing without re-finding the person

Amara splits rent with her brother every month. The old habit was a banking screenshot in a group chat — too much detail, no structure, easy to forward by accident.

The better habit is a vault-to-vault share of one Bank item. But even that breaks down if every month starts with “send me your vault link again” or a pasted identifier in the wrong thread.

Secure contacts exist so repeat sharing has a stable recipient. You establish the relationship once. Later shares pick the contact from the Share sheet instead of reconstructing trust from scratch.

Yuki faces the same pattern with a co-founder: production keys before a deploy, not a zip of the whole vault. The co-founder should appear as a named contact in Inbox and in the share picker — not as an anonymous package you hope is right.

For those stories from the sender side, see Split rent without screenshotting banking apps and Send production keys to my co-founder.

How a trust relationship starts

NT² uses an invite-first flow. You do not paste someone’s Vault Key DID into a form as the main path.

The ordinary sequence looks like this:

  1. Open Contacts and tap Invite someone.
  2. Share your invite QR or link — the other person opens it in their vault.
  3. They send their reciprocal invite back.
  4. You scan their reciprocal invite on your pending contact row.

When both sides finish the exchange, encrypted vault-to-vault sharing unlocks for that relationship.

That is slower than dropping a file in chat. It is slower on purpose. Trust should not be as frictionless as forwarding a photo.

Confirm the fingerprint out-of-band

During invite accept, NT² shows the signing key fingerprint for the other vault. That string is how you check “this vault identity matches the person I mean,” not just the display name they chose.

Confirm it the way you would confirm any high-stakes handoff:

  • on a call you already trust;
  • in person;
  • through a channel you use for serious conversations — not the same message that carries the invite link.

Software can verify signatures after that. It cannot replace your judgment about whether this human is your sister, co-founder, or accountant.

Contacts are local and per-vault

Contact rows live in your vault’s local database. They are not uploaded as a plaintext address book for NT² to browse.

Premium sync can replicate contact metadata across your devices as ciphertext — still your vault’s data, not a global social graph.

If you use multiple vaults on one device, each vault keeps an independent contact list. Work keys and family bank details should not share the same trust graph by accident.

This is not automatic trust

Saving a contact does not mean “I trust everything this person will ever send.” It means “I recognize this vault identity as part of our ongoing relationship.”

Each inbound asset share still lands in Inbox where you accept or decline. Each outbound share still chooses fields and delivery mode. Contacts remove repeated identity guesswork; they do not remove judgment.

For the recipient’s decision moment, read Something arrived in my Inbox.

One-way invite is not always enough

Accepting someone’s invite may let you verify what they send you. Mutual trust — where both vaults can send encrypted shares back and forth — requires completing the reciprocal exchange.

That asymmetry confuses people the first time they see it. The next post in this series explains it plainly: One-way invite, mutual trust.

For a guide-style walkthrough, see nt2.me/guides/contacts. For the four-concept map this series builds on, read Identity, assets, trust, and sharing, or follow the RSS feed.

Last updated 2026-10-24

Related stories