Most of the software you use models people. You have a profile; your friend has a profile; the app stores both. What it almost never models is the relationship — the specific, two-sided agreement that says we know each other, and here's what we've each agreed to share. The relationship is implied, scattered across permission flags and friend lists, never a thing you can pick up and look at.

An R-Card is that missing thing made concrete: a small cryptographic object that is the relationship between two beings. Not a profile, not a contact entry — the relationship itself, as a card you can hold.

It's worth saying up front where the idea comes from, because we didn't invent it. The term "Relationship Card" — R-Card — was coined by Drummond Reed in 2008, describing a digital object that instantiates a mutually authorized data-sharing relationship between two parties. That phrasing has aged remarkably well. NAOMS reached for almost exactly the same concept on its own, working from its own first principles, and only afterward discovered it was walking a path Reed had marked out years earlier. When that happens, you name it honestly and tip your hat. So: R-Card it is.

Let us unpack what one actually is, one idea at a time.

A card, not a profile

Start with the difference, because it's the whole point.

A profile is about you. It's one-sided. It exists whether or not anyone is looking, and it says the same thing to everyone — or it says different things and you manage that yourself, field by field.

An R-Card is about us. It exists because two beings established a relationship, and it encodes that relationship: who the two parties are, that they've mutually authorized some data-sharing, and the cryptographic material needed to keep talking securely. You don't have an R-Card the way you have a profile. You have an R-Card with someone. The card and the relationship are the same object.

That single shift — from "a thing about me" to "a thing about us" — is what makes everything downstream interesting.

Why it's asymmetric

Here's a subtlety that trips people up, so let's slow down on it.

You might assume a relationship card is symmetric: one shared card, equally held. It isn't. An R-Card is asymmetric, and that's deliberate. The card we present to you — what we've chosen to share, the face of ourselves we've shown you — is not necessarily the same as the card you present to us. We're in one relationship, but each side authored its own part of it.

Think of a physical business card. The card you hand us is yours; it carries what you chose to put on it. We keep it. Later we might hand you ours, with our choices. We now each hold a card the other authored. The relationship is mutual; the cards are two distinct objects, each owned and shaped by its sender. R-Cards work the same way — which is why "the card S presented to V" is a precise, meaningful phrase, and why a system has to be able to record exactly which card was shown to exactly which peer. (More on that gap below — it's one of the honest "not done yet" parts.)

Asymmetry also buys privacy. Because we author the card we show you, we can show different people different faces — a richer card to a close friend, a leaner one to an acquaintance — without maintaining one global profile that leaks the same data to everyone.

What rides on the card

An R-Card isn't just a name and an avatar. By design it carries:

• The two parties' identities — the relationship binds a specific pair of beings, not a being to "the public".
• Signing keys for the relationship's chain — the cryptographic keys that let the two sides verify each other's updates over time. The card isn't a static snapshot; it's the anchor for an ongoing, verifiable exchange.
• Whatever fields you authored — contact details, custom fields, the shareable face of you for this relationship.
• Attachments, optionally — content-addressed files (a small image, a note) referenced by their content hash, so the reference can't silently change underneath you.

Because the card carries chain signing keys, it's the foundation for the relationship staying current — which is the most ambitious idea in the whole design, and also the least finished.

The dream: a card that updates itself

Here's the problem every contact list has and none of them solve well: you move, you change your number, you get a new email — and now everyone who has your old details has stale details. Forever, usually, until someone notices and asks.

The R-Card design wants to kill that. Because the card binds two peers and carries the keys to verify updates, it's meant to auto-sync:

• Push: when you change a field, the holders of that card are notified that an update is available — and, crucially, selectively. Your employer gets the address change; your friends get the new location; not everyone gets everything. The relationship decides what propagates.
• Pull: holders can also check, on their own schedule, whether the card's author has published a newer version, using a version marker to detect changes.

That's the vision: a relationship you hold that quietly stays true without anyone re-sending a vCard. We want to be honest about where it stands, because the gap matters.

What's real, and what's still ahead

A primer that implies everything works would be exactly the kind of dishonesty this project tries to design out. So, plainly:

• Designed and specified: the R-Card concept — the asymmetric relationship object, its schema, the kinds of trust signals a card can carry, content-addressed attachments — is researched and written down as a settled definition. That groundwork reached a completed state.
• Designed, deliberately deferred: a bridge to translate R-Cards to and from the emerging external standard for relationship credentials was specified and then consciously parked — early adoption of a still-moving standard is a real risk, and we chose not to pay it yet.
• Still being built / on the drawing board: the parts that make an R-Card feel alive are the parts not yet shipped. Recording precisely which card a given peer was shown — so the receiver's side can materialize "this is the card they presented to me" — is in design, not done. The auto-update push/pull mechanism is a written design in the backlog, not a running feature. And a planned dedicated screen for viewing and editing your cards was started as an idea and then cancelled rather than half-built.

So if you ask us today "can I hold a relationship that keeps itself up to date?" the truthful answer is: the object is real and the definition is solid, but the self-updating, peer-bound, browse-your-cards experience is still mostly ahead of us, not behind. That's not a confession of failure — it's just where the work actually is, and we'd rather you know.

Fellow traveler. The instinct to make identity self-certifying — to carry your own proof rather than depend on a registry to vouch for you — is something KERI articulates beautifully, and it's part of why an R-Card carries its own keys instead of pointing at some central directory. We took that instinct; where we differ is altitude. KERI is foundational key-management; an R-Card is the warm, human layer on top — the relationship, not just the key. Different jobs, same north star.

The reason to care about any of this isn't the cryptography for its own sake. It's that a relationship is a real thing between two real beings, and it deserves to be modeled as one — owned by both sides, authored independently, able to stay true over time. A relationship you can hold. We're not all the way there. But we know exactly what we're holding, and exactly what's still missing — and naming both is the point.

Related: An Address Book Where Every Entry Signs Back · Trust Is Directional.

Written by AI agents from real project logs; owned and edited by Mujo.