The Difference Between a Conversation and an Event Object

Messaging Features vs Event Features August 21, 2026 16 min read By The Ontaym Team

Underneath nearly every planning failure in group chat sits a single structural fact: a conversation and an event are different kinds of data. One is a stream of moments; the other is an object with fields, identity and state. This is the idea the rest of this library keeps returning to — stated once, plainly.

Two structures wearing one interface

Open any group chat that has ever planned anything and look at it without reading the words. A birthday dinner announcement. A joke. An address. A cancellation of a different plan. A confirmation, a retraction, a photograph of a dog. On the screen they are indistinguishable: same bubbles, same font, same left-to-right drift into the past. The interface presents them as one substance — messages — and so, without anyone deciding anything, the group treats them as one substance. Everything that is said is filed in the same place, retrieved by the same scrolling, and granted the same authority as everything else.

But the substance is not one. Two radically different kinds of thing are being forced through a single container. The joke and the banter are utterances — moments of talk, complete in themselves, valuable exactly once. The dinner and its address are facts about a plan — structured claims with a lifespan, an identity, and a habit of changing. Utterances belong in a stream, where each new one pushes the last further into history. Facts belong in a record, where each edit replaces what came before. The group chat is a superb stream and a nonexistent record, and the mess that follows — the scrolling, the re-asking, the pins, the “wait, which time is real?” — is not a failure of the people. It is what happens when a record is stored as a stream.

This article is the structural version of that argument: what a stream actually is, what an object actually is, and why the four properties that separate them — append vs. mutate, position vs. identity, tense vs. state, mention vs. reference — decide everything about how a group plans. Practical treatments elsewhere in this library cover how the failure feels day to day; this one covers why it happens at all.

The conversation is a log

Be precise about what a chat is, because everything else follows from it. A conversation is an append-only log. New entries are added at the end; existing entries are never rewritten, never merged, never silently replaced. When a message enters the stream, it is frozen: the words, the timestamp, the position. From that moment it can only be read, never revised — corrections arrive as new entries that stand beside the entries they correct, not in place of them.

This gives a log a peculiar relationship with time. A log has no tense. Every entry remains exactly as true as the moment it was written — “8 PM at the usual place” is still there saying 8 PM after the world has moved to 9. The log doesn’t lie, because it never claims to describe the present; it records a series of pasts, stacked in order. It is a transcript, and a transcript is a perfect record of talk and a terrible record of anything else. Nothing in the log’s design marks which entry is currently authoritative. Authority, in a log, is always positional: the most recent relevant entry, whoever can find it, wins.

Order, in fact, is most of what a log has. Each entry’s meaning is completed by its position — a “yes!” is meaningless until you find what it answered, a “still 8?” is a question or a confirmation depending on what came before and after. And an entry’s identity is its position. The only way to refer to a message is by where it sits: that message from Tuesday night, the one after Maya’s photo. There is no handle to grab — no ID, no address, no stable name — that survives the message being surrounded by ten thousand newer ones. A log, in short, is honest, ordered, immutable — and shapeless. It has no fields, no current values, no identity apart from sequence. For recording how a group felt and spoke across a week, it is ideal. For holding what the group decided, it has nothing to offer but position.

The event is an object

An event object is the opposite arrangement on every axis. It is a record with fields: labeled slots — what, when, where, who, status — each holding one current value. Not a paragraph containing a time; a time, in a slot, next to a place, in its own slot. The fields can be read individually, written individually, and trusted individually.

It has identity: the event is a thing that persists across every change to it. Move the dinner from Friday to Saturday, from the bar to the park, from twelve guests to nine — it remains the same event, the same object, with new values. This is the property a log lacks entirely. In the stream, Friday-dinner and Saturday-dinner are just different entries; in the object, they are the same entity whose when field changed.

And it has state: the object’s answer to “what is the case now?” is stored, not implied. Mutation is how the object breathes — an edit replaces the old value for every future reader, so the record is always current by construction. Where the log accumulates truth-at-time-of-sending, the object maintains truth-at-time-of-reading. A message says; an event is.

None of this makes the object “better” than the log in any general sense. An object is a poor place to keep a joke, an argument, or the slow social process by which a group figures out what it wants to do. The object is silent about how decisions happen; it only holds what they concluded. The log is where the life happens. The object is where the facts live. Planning fails when a group has only the first and believes it has both.

Identity: what makes it the same event

Identity is the least obvious and most consequential of the object’s properties, so it deserves its own argument. Consider what actually happens to a plan: it is proposed, argued over, moved, renamed, half-cancelled, revived, and finally held. Through all of that, the group never once wonders whether it still has “the same plan.” The birthday dinner is the birthday dinner. Humans track identity through change effortlessly; it is one of the most basic things minds do.

A group chat cannot do it at all. In the stream, there is no “the dinner” — only entries that mention a dinner, some of which agree with each other and some of which don’t. The dinner has no existence apart from its mentions, no handle to hold it by. And this is not a pedantic point, because a striking number of coordination features are impossible without identity. You cannot subscribe to updates about a plan that has no identity to subscribe to. You cannot attach an RSVP to a plan, only to a message about a plan. You cannot ask what changed, because change requires a thing that persists while its properties vary. When people say “the plan got lost in the chat,” the precise statement is harsher: the plan never had an identity to be found by. There were only sentences, and sentences cannot be found, only reread.

Identity is also what lets one event be shared as one thing. A link to an event page works socially because the link names an identity: everyone who taps it arrives at the same object, whatever app they came from. The stream offers no equivalent — the closest it gets is quoting or forwarding, which copy an entry’s content while abandoning its (positional) identity, producing the familiar drift of diverging copies. Identity is what turns talk about a thing into a handle on the thing, and every planning workflow that scales quietly depends on having that handle.

State: stored or re-derived

The second great difference is where “now” lives. In the log, the current plan does not exist anywhere. It must be derived — reconstructed by a reader who processes the entries, weighs their order, infers which questions were settled, and outputs a personal estimate of the plan. Every reader performs this derivation independently, which is the deep reason two members of the same group can hold different plans in good faith: the log is perfectly consistent as a history and perfectly inconsistent as a plan. It never disagrees with itself, because it never asserts anything; its entries merely speak, in order, forever.

In the object, the current plan is stored. Asking “when is it?” is not a research project but a lookup — open the record, read the field. The derivation was performed once, by whoever made the edit, and its result was saved where everyone reads it. This is the entire economic difference between the two structures: in a log, every reader pays the cost of deriving state, on every read, forever; in an object, the writer pays a tiny cost once, and every reader afterwards reads for free. Groups plan in chat because the first ten messages make derivation look cheap. The trap closes when the group grows and the derivation cost rises — more entries, more forks, more corrections — until every member is paying, on every read, a cost that a single stored field would have eliminated.

Derivation also fails differently: it fails privately. When a reader mis-derives the plan from the log, the error is invisible — their belief looks, from the inside, exactly like everyone else’s belief. Nobody can correct what nobody can see. An object’s state, by contrast, is public and singular: either the field says nine or it doesn’t, and two people looking at the same field cannot quietly disagree. Planning errors that in chat would surface at the venue door surface instead at the moment of reading, which is the only moment they are cheap to fix.

Notice the asymmetry in effort is not small — it is categorical. Every answer in the middle column is a project; every answer in the right column is a glance. The middle column is also probabilistic: its answers are beliefs about the plan, held with confidence proportional to how far the reader scrolled. The right column’s answers are the plan.

Referential integrity: what an RSVP points at

The most technical-sounding difference in this article is also the one with the most human consequences. When a guest responds to a plan, their response has to attach to something. In a chat, it attaches to a message — the thumbs-up lands on the bubble that proposed Friday, the “I’m in!” replies to the message that asked. The problem is invisible until the plan changes: the plan moves to Saturday, but the response is still attached to Friday’s message, which still exists, still says Friday, and still wears its applause. The answers didn’t follow the plan, because they were never attached to the plan. They were attached to a sentence that is now describing a dead version of it.

An RSVP attached to an event object points at the object’s identity, not at any statement about it. The plan moves to Saturday; the RSVPs move with it, automatically, because they were never pointing at Friday — they were pointing at the dinner. This property — that references survive changes in the thing they reference — is what lets commitment accumulate. A group chat’s responses decay every time the plan shifts, because each shift orphans the previous round of reactions; an object’s responses persist through shifts, which is the only reason a reliable headcount can exist at all.

The figure is the whole argument in one image. On the left, a poll in a chat: a genuinely useful tool, but its votes are bound to one message at one moment, anonymous, and frozen. On the right, the RSVP list of an event object: each answer bound to a person and to the event’s identity, updatable as reality shifts, rollable up into a count. The left is a snapshot of opinion; the right is a living ledger of commitment. The practical consequences of that difference — what each one does to your headcount — are unpacked in event RSVP vs. group chat reaction and in why “going” is different from answering a poll.

Why patches to the log never become an object

A fair question at this point: haven’t the messaging apps already solved this? Pins, polls, group descriptions, even in-app event listings exist, and each genuinely helps. But look at what each patch is made of. A pin freezes one entry and keeps it near the top: position is curated, but the entry is still an entry — immutable, tense-less, superseded by the first change. A poll aggregates a moment’s opinions and displays bars: state, but only of the question “what did people think then,” never “what is the plan now.” An announcement channel broadcasts with authority, but broadcasting is still appending. Every feature improves the stream’s usability without altering its nature: entries remain append-only, identity remains positional, the present remains derived. You cannot grow an object by improving a log, any more than you can make a ledger out of better-indexed diary pages. The object has to be introduced — a new thing, with its own identity — not summoned out of the thread.

The in-app event listing is the most interesting case, because it is a real object — inside one app’s walls. WhatsApp communities can carry events for their members; Discord servers have their own events; calendar invites are objects any mail app understands. These are honest improvements over the raw stream, and where an entire group lives inside one platform, they may be enough. The remaining gap is the one identity creates: an object locked to one app’s membership still can’t be the shared reference for a group that spans apps, or for the guest who belongs to no community at all. An identity that only one app can address is half an identity. The fuller account of why stream-native conveniences stay conveniences — told from the practical side, as a retrieval problem — is why messaging apps were never designed to be event databases; the present article is the structural half of that same argument.

Platform architectures say the quiet part out loud, too. Telegram’s own platform documentation — see core.telegram.org — describes chats as message streams with polls, pins and edits layered on top, and even its channels are formally one-to-many broadcast streams. The primitives are entries and ordering. Where the platform needs real objects, it introduces them as separate systems alongside the stream — which is exactly the argument: when the engineers need identity and state, they do not find them in the log. They build a new structure next to it.

The pair that works: think in the log, decide in the object

The conclusion you should not draw from any of this is that conversation is the enemy. The opposite: the stream is irreplaceable, because deciding is a social process and social processes are made of talk. The debate between Saturday and Sunday, the delicate discovery that half the group can’t afford the expensive place, the joke that becomes the event’s name — none of that can be hosted by a form. The log is where a group thinks. The mistake was never thinking in the log; it was filing the conclusions there.

The pattern that works is therefore a pair, not a replacement. The conversation proposes, argues, negotiates; each settled question is written once into the event object; the object’s address circulates back into the conversation as the standing answer. The two structures check each other’s weaknesses: the log can’t hold state, so it delegates state to the object; the object can’t host deliberation, so it borrows the log’s life. Groups that run this loop — talk, decide, record, share the address — stop experiencing planning as an argument with their own history. The conversation is how the group thinks. The event object is what the group decided.

The funnel above is what that looks like from the object’s side. Invited becomes decided, decided becomes committed, committed becomes present — each stage a change of state that the record absorbs as it happens. The log, watching the same week, registers only weather: bursts of enthusiasm, pockets of doubt, an argument about parking. Both accounts are true, and they are about different things. The plan’s progress is visible only to the structure that has state; the group’s experience is visible only to the structure that has talk. This is the design Ontaym is built around — an event page holding options, votes, RSVPs and final details, next to whatever conversation the group wants to have — not because chat is wrong, but because each half of planning needs its native shape.

The shape the web already agreed on

If all of this sounds abstract, notice how much of it the world quietly settled long ago. When machines need to understand an event, they do not read a transcript. The web’s shared vocabulary for events — schema.org’s Event type — describes them as objects with properties: a name, a start, a location, attendees. The response to an invitation has its own type — RsvpAction — modeling exactly the identity-bound commitment this article has been describing. Calendars made the same move decades earlier: an invite is an object with a stable identity you can accept, decline, or have rescheduled under you. None of these systems store an event as a sequence of remarks. The convergence is not fashion; it is the problem’s own shape asserting itself. An event is a thing with fields, identity and state, and every system that has to reason about events — search engines, calendars, ticketing, RSVPs — rediscovers that shape independently.

The group chat, meanwhile, will keep being what it is: a magnificent log, one of the best ever built. The failure this article has dissected was never the log’s fault. It was ours, asking a transcript to do a record’s job — asking speech to hold state, position to serve as identity, and a week of beautiful, chaotic talk to remember what we decided.

Frequently asked questions

Conclusion

Everything in this article reduces to one distinction, and it is worth stating with total plainness. A conversation is an append-only log of moments — honest, ordered, permanent, and always in the past tense. An event is an object — a small structure of fields with a stable identity and a stored present. The log is one of the best things software has ever built, and groups will never stop needing it. The object is the shape plans actually have, and groups will keep paying for its absence — in scrolling, stale facts, orphaned RSVPs, and quiet divergences between people who all read the same thread — until they give their plans the structure plans require.

The practical upshot is modest and total: give every real event its own object — a page with an address, holding the current facts — and let the conversation go back to being what only it can be. Debate in the log. Decide in the object. Share the address. That is the whole method, and the difference between a group that fights its history and a group that simply knows what it’s doing on Saturday.