The Difference Between a Conversation and an Event Object
A sentence about Saturday and a record of Saturday look like the same information wearing different clothes. They are different kinds of thing, and that difference is why two careful people read one thread and arrive an hour apart.
Quick answer
A conversation is a sequence of utterances: things people said, kept in order, all equally true at the moment they were sent. An event object is a thing that exists, with named fields holding one current value each.
State means the set of things that are true right now, held somewhere that "right now" can be asked. A thread cannot do that, because changing a plan adds a message rather than replacing a value.
Once a plan has an identity you can link to it, compare two versions of it, count what it holds and let it notify people itself. None of those four are available to a sentence, however clearly the sentence is written.
Two things that look identical and are not
Here are two ways of holding the same Saturday.
The first is a message: "dinner's at 8 on the 14th, that place by the station, Dan's a maybe." The second is a record with a start time of 20:00, a location, an organiser and Dan marked as tentative.
Read them side by side and they look like the same information in different clothes. They are not the same kind of thing at all, and the difference is the reason your group keeps turning up an hour apart.
One is an utterance. Somebody said it, at a moment, and it was true when they said it.
The other is an object. It has an identity, it has fields, and each field has a current value that can be read without reading anything else.
That gap is not a matter of formatting or discipline. It is a category difference, and no amount of clearer writing in the chat closes it.
A sentence containing a fact is not a record holding one
This is the sentence the whole article hangs on, so it is worth slowing down.
Facts can travel inside sentences perfectly well. "The bus leaves at six" delivers a fact to your brain with no loss.
What the sentence cannot do is be consulted afterwards. You can reread it, which is a different act, because rereading gives you the sentence again rather than the answer again.
The distinction shows up the instant something moves. If the bus is retimed, the sentence does not become false in any visible way.
It sits there, still perfectly grammatical, still saying six. Somewhere else in the thread a newer sentence says seven, and now you have two true statements and one bus.
A message can carry a fact. Only a record can hold one.
A record works the other way round. The start time is one named slot, and writing a new value into it removes the old one from the answer.
The old value is not destroyed, which people assume is the same thing. It moves into history, where it belongs, and stops competing for the present.
So what does "state" actually mean?
State gets used loosely enough to mean almost nothing, so here is a working definition you can test in the wild.
State is the set of things that are true right now, held in a place where "right now" can be asked.
Both halves matter. Truth alone is not state, or every accurate sentence ever typed would be state, and clearly your chat is not a database.
Three properties, and a thread has none of them
- Singularity
- For each thing the plan needs, there is exactly one current answer. Not the most recent mention of an answer, and not the answer most people seem to have agreed with. One.
- Addressability
- You can reach that answer directly, without reconstructing the path that produced it. "What time" resolves to a value rather than to a reading exercise.
- Mutability without ambiguity
- Changing the answer replaces it. The change is visible as a change, and afterwards there is still exactly one answer.
Run a group chat against those three and it fails all of them, cheerfully and by design. A thread is optimised for something else entirely, which is keeping a faithful ordered account of who said what.
That is a genuinely hard problem and messaging apps have solved it beautifully. It just happens to be the opposite problem from the one a plan has.
The cruel part: history looks like state until it does not
For the first day or two of any plan, a thread performs beautifully. There is one proposal, everybody read it, and the most recent message is also the true one.
History and state agree, so nobody notices they are different things. The illusion holds right up until the first change.
After that, every additional message widens the gap between "the latest thing said" and "what is actually happening". By the third change the thread is a puzzle with the answer hidden inside it, and the puzzle is exactly why a chat cannot behave like an event database however tidily people type.
What identity buys you
Now the good part. Give the plan an identity, one address that means this event and nothing else, and four abilities arrive that a sentence simply cannot have.
These are not features somebody thought up. They fall out of the structure, which is why they show up in every system that models events properly.
You can point at it
Once the plan has an address, mentioning it and copying it become different acts.
Paste the address into four separate chats and you have made four pointers. Retype the details into four chats and you have made four copies, each of which can now drift away from the others independently.
This is the whole reason the same event scattered across several apps goes wrong so reliably. Copies drift. Pointers cannot.
You can compare two versions of it
An object with fields can be diffed. Version two against version three produces a real sentence: the start time moved by thirty minutes, everything else stayed put.
Try that on a thread. The honest diff between Tuesday's thread and Friday's thread is "here are ninety more messages", which is accurate and completely useless.
This is why a late joiner needs a briefing rather than a read. They have been handed a changelog with no summary, and the only person who can summarise it is the organiser they were trying not to bother.
You can ask it a question
Fields can be counted. How many are coming, who has not answered, how many people asked for the vegetarian option, all of that is arithmetic when the answers live in slots.
In a thread the same questions require a human to scroll, interpret and tally, which is a job somebody in every group quietly ends up doing. If your headcount lives in one person's notes app, you do not have a record, you have a volunteer.
The tallying is also lossy in a way that never gets admitted. Counting thumbs-up reactions turns out to be a surprisingly bad way to build an attendance record, because a reaction was never a commitment in the first place.
It can speak up on its own
This one is the sleeper. A field that changes knows it changed, and an attendee list knows who cares.
So the update can go out by itself, to exactly the people affected, without the organiser remembering at eleven at night. That is structurally different from an announcement, which is why an event notification and a group notification are not the same animal even when they arrive on the same phone.
A sentence cannot notify anyone of anything. It can only be sent again, and sending it again is just another message competing with the first one.
The two things, laid out honestly
Neither column here is the loser. They are answers to different questions, and most of the trouble comes from asking one of them the other one's question.
| Property | A message in a conversation | An event object |
|---|---|---|
| What it fundamentally is | A thing somebody said at a moment | A thing that exists and has values |
| Identity | Position in a sequence | A stable address that outlives the chat |
| Where the truth lives | In the ordering of messages | In the current value of each field |
| Effect of a change | Adds a competing statement | Replaces one value, notes the revision |
| Answering "what time?" | Requires reading and judgement | Requires reading one field |
| Answering "who is coming?" | Requires a human to tally | Requires counting |
| Answering "what changed?" | Not answerable | A comparison between two revisions |
| Age | Visible, and usually misleading | Explicit, as a last-modified value |
| Silence from a person | Indistinguishable from agreement | A named state of its own |
| What it is genuinely great at | Persuading, joking, deciding together | Being correct on Thursday at 19:50 |
Look down the right-hand column and notice how boring it is. That is a compliment.
Nobody wants their friendships to feel like a database. They do want the address to be right, and those two wishes are easier to satisfy separately than together.
The bit that was settled in 2009
None of this is a new observation, and the shape of an event object is not a matter of opinion.
The IETF wrote it down in RFC 5545, the iCalendar specification, which is the reason a .ics file opens on every device you own. It defines an event as named properties: a unique identifier, a start and end, a location, an organiser, a list of attendees, a revision counter, a status and a last-modified stamp.
Two of those deserve a moment. SEQUENCE is a revision number, which means two people can find out whose copy is older without arguing about it.
PARTSTAT is each attendee's participation status, and its default value is NEEDS-ACTION. That default gives silence a name, which is something no group chat has ever managed.
There is a companion document, RFC 5546, which specifies how invitations travel, with a request going out and a reply coming back. So the record, the invitation and the answer have all been formally defined for well over fifteen years.
I am not going to walk through the specification, because this article is about the idea rather than the syntax. The useful thing to take from it is that somebody sat down and enumerated what a plan needs to hold, and the list is short.
Where the boundary genuinely blurs
If the two categories were perfectly clean this would be an easy article and also a slightly dishonest one. They are not clean, and the messy edges are the interesting part.
Conversations that grew fields
Chat apps noticed the gap and started bolting structure on. Pinned messages, polls, edited messages, reactions, group descriptions: every one of those is a small attempt to hold state inside a medium built for history.
Some of them work surprisingly well. An edited message genuinely does replace a value, which is real state, and pinning genuinely does create a kind of address.
They stop short in the same place every time. There is no schema, so nothing can be counted, compared or asked, and the structure decays the moment the plan changes shape.
Objects that are secretly conversations
The blur runs the other way too. A poll looks like an object: it has options, it has counts, it produces a result.
What it actually holds is a set of opinions at one moment, which is not the same as what is happening. Voting that Saturday works is a statement about your calendar, and this is precisely why saying you are going and answering a poll are different acts.
Free-text description fields have the same problem in miniature. Put "meet outside, unless it rains, then the pub" into a description and you have smuggled a conversation into an object, where nothing can read it.
The reply thread hanging off the record
Almost every event tool eventually grows a comments section, and almost every one of them regrets it a little.
People immediately start putting facts in there. "Actually let's make it 8.30" appears as a comment on an event whose start time still says eight, and now the object contains its own contradiction.
The fix is not banning comments, which never works and makes the thing feel unfriendly. It is making the fields obviously more authoritative than the chatter, so a comment reads as a suggestion until somebody moves the value.
When a conversation really is the right container
Sometimes there is no state to hold, and reaching for structure is the mistake.
Deciding whether to do the thing at all is a conversation. Arguing about the restaurant, working out whether anyone actually wants a picnic in February, persuading the friend who never comes: all conversation, all badly served by fields.
The switch happens at a specific moment, and it is not the moment people expect. It is not when the plan is agreed, it is when the plan first becomes something a person could be wrong about.
A Thursday where the difference shows
Abstractions are cheap, so here is the concrete version.
Eleven people, a birthday, a booking that had to move from one restaurant to another on the Wednesday. Everything was announced in the chat, warmly and clearly, by an organiser doing nothing wrong.
On Thursday evening, four separate things need to be true at once. The address must be right, the time must be right, the restaurant must have the right number, and the person who muted the group on Tuesday must still arrive.
In the conversation version, all four depend on the same fragile mechanism: each individual person having read the correct message and retained it. That mechanism has a failure rate, and the failure rate is not small.
In the object version, the same four things depend on one field each. The person who muted the group opens a link and reads the current value, which is a completely different act from reconstructing a fortnight of chat on a phone while walking.
Here is the detail I find most telling. In the conversation version, the organiser is the only backup, so their phone rings at 19:40 three times.
In the object version nobody rings anyone, and the organiser has a nicer evening. That is the actual benefit, dressed up as a technical argument about data structures.
Working out which one you are holding
You can diagnose any group plan in about a minute. This is worth doing before you change tools, because sometimes the answer is that nothing is wrong.
- Ask the plan a question out loud. "What time does it start?" If answering means scrolling, you are holding a conversation.
- Try to find the answer twice. If you and a friend can arrive at different answers from the same thread, there is no state, only interpretation.
- Ask what changed since Monday. A record answers this. A thread offers you the raw material and wishes you luck.
- Count the people who have not replied. If silence and agreement look identical, your headcount is a guess wearing a confident expression.
- Check how many places the details exist. Three copies in three apps is three chances to be wrong, and one source of truth is the whole fix.
Two failures and you are past the point where being tidier helps. Etiquette raises the ceiling on a conversation, and structure removes it.
The objections, taken seriously
Three replies come up whenever this argument gets made, and all three are reasonable.
"This is just being organised"
It genuinely is not, and the difference is worth naming.
Being organised means one person does the work of holding state in their head and repeating it on demand. It works, in the sense that a human can do a machine's job for one evening.
The tell is that it does not accumulate. Next month the same group starts from nothing, because nothing was left behind except a scrolled-past message and a tired friend.
"Structure kills the fun"
It does, when you put it in the wrong place. A calendar invitation to a birthday reads like a summons, and everybody has felt that particular chill.
But the argument here is not to make the conversation more structured. It is to take four facts out of the conversation so the conversation can go back to being fun.
Groups that plan with a record usually end up messing about more in the chat, not less. The admin was the part that made the thread tedious, and a chat is not an event no matter how much work it is doing.
"Our plans change too much for a record"
This one is exactly backwards, and it is my favourite objection for that reason.
A plan that never changes is fine in a thread, because history and state never diverge. It is the plans that move three times before Friday that punish a conversation hardest.
The more your plans move, the more you want the thing that can be moved. That is also why people changing their minds about coming is a data problem rather than a manners problem.
What this means for anyone building things
If you are designing software rather than dinner, the same distinction cuts the design work in half.
Ask of any piece of information: is this something somebody said, or something that is true? Those two want opposite storage, opposite interfaces and opposite defaults.
Things people said should be append-only, ordered, attributed and never silently altered. That is what makes a conversation trustworthy.
Things that are true should be singular, addressable, versioned and loudly changed. That is what makes a record trustworthy.
The failure mode of most planning software is trying to make one surface do both. You get either a chat with a struggling pin, or a rigid form that nobody wants to fill in for a Saturday, and the gap between those two products is where most group plans currently live.
| The thing | Belongs in | What happens if it lives in the wrong place |
|---|---|---|
| The final start time | A field | Two people arrive an hour apart, both certain |
| Whether to do it at all | The conversation | A poll makes a decision nobody feels bound by |
| The address | A field | A screenshot of a map from six weeks ago |
| Who is coming | A field, per person | Somebody counts reactions and gets it wrong |
| Excitement and jokes | The conversation | A record that reads like a memo, so nobody opens it |
| What changed and when | A revision on the record | Multiple messages saying "FINAL", none of them final |
| Arguing about the venue | The conversation | Fields fill with parenthetical hedging nobody can read |
| What to bring | A field | Four people bring crisps and nobody brings ice |
Where Ontaym fits
This is the one section where I am talking about our own product, so it is short.
Ontaym exists because of exactly this distinction. An event is an object with an address, real fields and per-person answers, and your group carries on talking wherever it already talks.
Guests answer at a link without installing anything or handing their phone number to ten strangers. The chat keeps the conversation, and the record keeps the facts.
That is a deliberately narrow job. A ticketed conference wants a publishing platform, and coffee with one friend wants nothing at all.
The short version
A conversation is a sequence of things people said. An event object is a thing that exists, with named parts you can read, change and count.
Facts can pass through a conversation, and they do, constantly. They cannot live there, because living somewhere means being findable later without a search party.
When planning feels heavier than the event deserves, the question is not which app to use. It is whether the thing you need is currently being held by something that can hold it.
If the hard part is deciding, arguing or getting people excited, you need a conversation and you already have a very good one. Leave it alone.
If the hard part is that nobody can say what time it starts, you need an object. No amount of better messaging will produce one, because that is not what messages are for.
Frequently asked questions
What is the difference between a conversation and an event object?
A conversation is a sequence of utterances, kept in the order they were said, where every message stays equally visible forever. An event object is a single thing with named fields, each holding one current value that replaces the last one. The first is built to remember what happened, the second to answer what is true.
What does "state" actually mean here?
State is the set of things that are true right now, held somewhere those things can be asked. It needs one current answer per question, direct access to that answer, and changes that replace rather than accumulate. A chat thread offers none of the three.
Why is a message containing a fact not the same as a record holding one?
A message delivers a fact to whoever reads it at the time, and then stops. It cannot be consulted later without rereading, it does not become false when the world changes, and a newer message contradicting it does not switch it off. A record replaces the value, so there is only ever one answer to find.
What can you do with an event object that you cannot do with a thread?
Four things, and they all follow from it having an identity. You can point at it instead of copying it, compare two revisions to see what changed, count what it holds such as the number of people coming, and let it notify the affected people by itself when a field moves.
Is this what RFC 5545 describes?
Yes. RFC 5545, published by the IETF in 2009, defines the event object behind every .ics file as a set of named properties including start and end, location, organiser, attendees with a participation status, a revision counter and a last-modified stamp. It is a formal statement of what a plan needs to hold.
Do pinned messages and polls not turn a chat into a record?
They get partway and then stop. An edited or pinned message does replace a value, which is real state, but there is no schema underneath, so nothing can be counted, compared or queried. Polls are the trickier case, because they look structured while actually storing opinions at one moment rather than what is happening.
Does using an event record mean making plans feel formal?
The opposite, in practice. The point is to move four facts out of the conversation so the conversation stops doing admin, and groups that plan this way usually mess about more in the chat rather than less. Formality comes from making the conversation structured, which is not what is being suggested.
Our plans change constantly, so is a fixed record not worse for us?
That is the case where a record helps most. A plan that never changes is fine in a thread, because the newest message stays the true one, and it is the plans that move three times that punish a conversation hardest. The more something moves, the more you want a single value you can move.
Give your next plan one address instead of one more thread.
Plan it with Ontaym