Why Your Conversation Identity Shouldn't Be Your Invitation Identity
To your group chat, you are a phone number with a history attached. To Saturday's dinner, you are just a name and an answer. Messaging apps quietly merged those two identities, and the merge is why a simple RSVP can feel like joining something much bigger than it is.
Quick answer
A conversation identity is durable: a phone number or account, tied to years of history, contacts, and read receipts. An invitation identity should be thin: a name attached to one answer, for one event, that expires when the event is over.
Messaging apps have only ever had one identity system, so every event routed through a chat inherits the heavier, permanent one. RFC 5545, the calendar standard since 2009, already describes the scoped version: an ORGANIZER, an ATTENDEE, and a per-person answer, with no concept of group membership at all.
Separating the two means a guest can answer a question about one evening without exposing their number, their history, or anything else about who they usually are.
You are a different kind of thing to a chat than you are to an event
To your group chat, you are a phone number with a history attached. Every joke you have made, every read receipt, every "typing" indicator that stopped without a message, all filed under the same identity.
To an event you are invited to on Saturday, you are something much smaller. A name, and an answer.
Software has spent twenty years treating those two things as one, mostly by accident. It never sat down and decided that your conversational identity and your invitee identity should be the same thing. It just built messaging first, and events got bolted onto whatever identity was already lying around.
That accident has a cost, and it shows up every time a plan gets made inside a chat instead of somewhere built for plans.
Two different questions, wearing the same outfit
"Who are you in this conversation" and "who are you as a guest at this thing" sound like the same question. They are not, and the gap between them explains a surprising amount of what makes group planning uncomfortable.
Conversational identity is durable and cumulative. It is built from years of messages, a saved profile photo, a name your phone auto-completes, and a running sense of how this person usually behaves in a group.
Invitee identity is deliberately thin. It needs to answer one question, "is this person coming," for one specific occasion, and it should not need anything about who they usually are.
A conversation remembers you. An invitation only needs to hear from you once.
Most messaging apps have exactly one identity system, so every request routed through them inherits the fuller, heavier one. Ask a question that only needs a yes or no, and you get a reply wrapped in someone's entire social history with the group.
The phone number problem, from a different angle
We have written elsewhere about why your phone number shouldn't be your event identity, and the argument there is worth a shorter recap here, because it is the clearest single example of the identity mixup.
A phone number is assigned by a carrier, tied to a contract, and reused across every context you own. It does not know or care whether you are messaging a close friend or answering a stranger's wedding invite.
When an app uses your number as your identity, it inherits that number's entire baggage: your contacts list can find you by it, your read receipts are tied to it, and every group you have ever joined has it stored somewhere.
An invitation does not need any of that. It needs to know you are coming, and it needs a way to tell you if the time changes. A phone number is one of many things that can carry that message, but it is a strange choice for what your identity as a guest should be.
What a conversation actually is, underneath
Strip a chat thread down to what it structurally is, and it is an ordered log with permanent membership. Everyone in it can see everything anyone else said, forever, and leaving is a visible act rather than a quiet one.
That shape is exactly right for a friendship, a family, a running joke that lasts years. It is a terrible shape for a single request that only needs one bit of information back.
An event, by contrast, does not need permanent membership at all. It needs a fixed set of facts, a list of names, and a per-name answer that can be checked and updated.
The standard that already describes this precisely is RFC 5545, the IETF specification behind every calendar file since 2009. It defines an ORGANIZER field and a separate ATTENDEE field, and each attendee carries a participation status called PARTSTAT, which can be NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE or DELEGATED.
None of those five values describe belonging to a room. They describe an answer to a single, bounded question, which is the entire job an invitee identity needs to do.
Its companion, RFC 5546, defines how the invitation and the reply actually travel, with a REQUEST going one way and a REPLY coming back. Neither document has ever needed a concept of joining anything, because an invitation was never designed to be membership.
| Conversational identity | Invitee identity | |
|---|---|---|
| What it is anchored to | A phone number, username or account | A name attached to one event |
| How long it lasts | Indefinitely, across every group you're in | Until the event has happened |
| What it exposes to others | Contact details, history, read state, presence | Whether you are coming |
| What ends it | A visible act: leaving, being removed | Nothing to end, it simply expires |
| What it is good for | An ongoing relationship | Answering one bounded question |
Why the mixup keeps happening
It is not that anyone designed this badly on purpose. Messaging came first, it needed one identity system, and it built a good one: your number or your account, carried everywhere you go inside that app.
Events came later, and they arrived with nowhere else to live. The chat was already open, everyone already had an identity inside it, so the event borrowed that identity rather than getting one of its own.
The result is that answering "are you coming Saturday" costs you the same identity exposure as joining a permanent group would. You cannot separate the two, because the software never built the seam that would let you.
This is the deeper version of an argument we have made about the room itself. Why not everyone wants to join another group chat looks at the social cost of that borrowed identity, the awkward exits, the exposed numbers, the audience for every reply. This piece is about the layer underneath it: the identity system that makes all of that unavoidable in the first place.
A record is not the same thing as a conversation, and neither is an identity
There is a related distinction worth being precise about, because it explains why "just keep the plan in the chat" never quite works. A conversation is a transcript of what was said. A record is a statement of what is currently true.
We go into that difference properly in the difference between a conversation and an event object, and it matters here because identity follows the same split. A conversational identity accumulates, the way a transcript does. An invitee identity should simply state what is true right now: this name, this answer.
Try to fold an invitee identity into a conversational one and you get exactly the mess this article opened with. Your invitee answer becomes one more message in a thread that keeps growing, instead of a single fact that can be checked and changed.
Three properties an invitee identity should have
Once you separate the two, it becomes clear what an identity built purely for invitations actually needs.
- Scoped
- It applies to one event and expires with it, rather than persisting across every future plan the same group ever makes.
- Minimal
- It carries a name and an answer, and nothing an organiser did not actually need to know to run the event.
- Non-transferable
- Being invited to one event does not hand your details to every other guest, the way group membership hands your number to a room full of near-strangers.
None of that is a technical stretch. It is closer to how a wedding RSVP card worked before any of this went digital: a name, a box to tick, and nothing else about you traveling with it.
Nobody's aunt learned your phone number from mailing back a reply card. The card asked one question, you answered it, and the card's job was finished.
Digital invitations quietly gave that up somewhere along the way, not through any deliberate choice, but because chat became the easiest channel to send an invite through. The channel brought its identity model along for the ride.
Why this matters more as groups get bigger
In a group of four close friends, none of this really bites. Everyone already has everyone's number, everyone already knows the history, and borrowing conversational identity for an invitation costs nothing because there was never anything to protect.
The cost appears the moment a group crosses outside that tight circle. A colleague's partner, a friend of a friend, someone invited because they matter to the event but not to the group's existing history.
For that person, being asked to answer through a conversational identity means exposing a number, a name, sometimes a profile photo, to a room of people they have no ongoing relationship with. They are being asked to pay a membership cost for a one-time answer.
The bigger and more mixed a guest list gets, the more that mismatch shows up, and the more people quietly decline rather than say so directly.
There is an asymmetry hiding in that decline, too. The person who says no rarely explains why, and the reason almost never makes it back to the organiser as "I didn't want thirty strangers to have my number."
It gets read instead as disinterest in the event itself, which is usually the opposite of what happened. Plenty of people who quietly decline would have said yes in an instant to a version of the invitation that only asked for their answer.
What it looks like when the two are actually separate
Picture the same event, but built the other way round. The organiser creates one page for it: the time, the place, and a list of names.
Each guest gets a link, not a room. Opening it shows them the current facts and a box to answer, nothing about anyone else's phone number, nothing about their message history with anyone in the group.
They answer, and that answer is attached to their name for this one event only. It does not persist into some ongoing membership, and it does not carry forward to whatever the same group plans next month.
Everyone's actual conversation, the planning, the arguing, the jokes, still happens exactly where it already happens. It just is not also doing the job of proving who is coming.
Where the two identities do need to connect
None of this means the two should never touch. The organiser still needs to know who a guest is in real life, and often that person is also someone they talk to constantly.
The point is narrower: the invitee identity should be able to exist on its own, for a stranger's plus-one or a distant cousin, without requiring the heavier conversational one as a precondition. Where the two overlap, that is fine. Where they do not, nothing should break.
The identity does not need to be permanent to be trustworthy
There is an instinct that a temporary identity must be a weaker one, and it is worth naming why that instinct is wrong here. Trust in an RSVP does not come from how long the identity has existed.
It comes from whether the answer is attached to the right person and the right event, checkable at the moment it matters. A name given once, tied to one occasion, can be entirely trustworthy without ever needing to outlive that occasion.
Compare this to how a doorman checks a wedding guest list. Nobody expects the list to remember who you were last year, and nobody thinks less of the list for that.
It only has to be right about tonight. An invitee identity is the digital version of the same idea: correct for one event, and not required to be anything more than that.
Objections worth taking seriously
"Isn't this just adding another account to make?"
It would be, if the answer required signing up for anything. The useful version of this separation asks nothing of the guest beyond a name and a tap, because requiring an account just reintroduces the same problem in a different outfit.
An invitee identity that demands registration has quietly become a conversational one again, just with a different company holding it.
"My friends don't mind sharing numbers"
Close friends usually do not, and this was never really about them. The mismatch shows up for the guest list around the edges: the plus-one, the colleague, the person invited once.
Keeping identities separate costs the close friends nothing and spares everyone else something real.
"The organiser still needs to know who's coming"
They do, and a scoped invitee identity gives them exactly that: a name and an answer. What they do not need, and rarely wanted in the first place, is a permanent record of that guest's messaging history, presence, or read receipts.
Knowing who is coming and knowing everything about someone are different amounts of information, and only one of them was ever the actual job.
What each identity actually needs to answer
It helps to line up the specific questions each identity is built to answer, because they barely overlap.
| Question | Answered by conversation identity | Answered by invitee identity |
|---|---|---|
| Is this person coming Saturday | Poorly, buried in a thread | Directly, as a single field |
| What is this person's number | Yes, visible to the whole room | No, never required |
| How does this person usually talk in the group | Yes, from months of history | Not applicable, no history exists |
| Has this person seen the latest update | A read receipt, sometimes public | Whether their answer is current |
| Will this identity still mean anything in a year | Yes, it persists indefinitely | No, and it was never meant to |
Read down that middle column and it becomes obvious why conversation identity is such an odd fit for a single RSVP. It answers questions nobody asked, and it answers the one question that matters through inference rather than directly.
An organiser reading a thread has to guess an answer from a thumbs-up, a delayed reply, or silence that might mean yes or might mean busy. An invitee identity built for exactly one job removes the guessing, because the field it stores is the answer itself, not a clue toward one.
That is a small difference on paper and a large one in practice. Guessing at forty people's intentions from forty different reply styles is real, tiring work, and it is work a properly scoped identity was never going to require in the first place.
Where Ontaym fits
This is the idea Ontaym is built around, more than any single feature. An event gets its own identity, a name and an answer scoped to that occasion, entirely separate from whatever messaging identity a guest already has.
Nobody needs an account to answer, nobody's number becomes visible to anyone else on the list, and the answer does not outlive the event it was given for.
Your conversations carry on exactly where they already happen, which is the argument made at more length in keeping chat for conversation and Ontaym for the plan itself. This is the layer underneath that conversation, not a replacement for it.
The short version
Who you are in a conversation and who you are as someone invited to one event have always been different things. Messaging apps merged them by accident, because events had nowhere else to live, and the merge is why answering a simple question about Saturday can feel like joining something much bigger.
Separating the two is not a technical leap. RFC 5545 described the shape of a scoped, minimal invitee identity in 2009, long before anyone thought to ask why a dinner invite needed your phone number to be shared with strangers.
The fix is to let both identities exist without forcing one to carry the other. A name and an answer for the event, and everything else exactly where it already was.
Frequently asked questions
What is the difference between a conversation identity and an invitation identity?
A conversation identity is durable and cumulative: a phone number or account tied to years of message history, contacts and presence. An invitation identity is meant to be thin: a name attached to one answer for one event, which expires once the event has happened.
Why do messaging apps use the same identity for both?
Because messaging came first and built one identity system for itself, and events arrived later with nowhere else to live. The event borrowed the conversation's identity rather than getting a scoped one of its own, so every RSVP inherits a heavier identity than it needs.
Is this the same as the phone number problem?
It is the clearest single example of it, but the idea is broader than phone numbers. Any identity built for an ongoing relationship, whether it is a number, a username or an account, is the wrong shape for answering a single bounded question about one event.
Has anyone actually defined what a scoped invitation identity should look like?
Yes, and a long time ago. RFC 5545, the IETF's calendar specification since 2009, defines an ATTENDEE with a participation status called PARTSTAT, which can only be NEEDS-ACTION, ACCEPTED, DECLINED, TENTATIVE or DELEGATED. None of those values describe membership in anything.
Doesn't separating identities just mean making another account?
Only if it is done badly. A useful invitee identity asks nothing of the guest beyond a name and an answer, with no signup required, because requiring an account just recreates the same heavier identity under a different name.
Why does this matter more for bigger or more mixed guest lists?
Because close friends already share everything and lose nothing from the merge. The cost shows up for the plus-one, the colleague or the distant cousin, who is asked to expose a number and a history to people they have no ongoing relationship with, just to answer one question.
Does this mean giving up on group chats?
No. The conversation keeps happening exactly where it already happens, jokes and all. Separating identities only means the answer to a question about one event does not also require joining, or being fully exposed to, the room where that conversation lives.
What does an event actually need to know about a guest?
A name and an answer, and very little else. Knowing whether someone is coming and knowing their full messaging history, presence and contacts are very different amounts of information, and only the first one was ever the actual job.
Give your next plan one address instead of one more thread.
Plan it with Ontaym