Living Museum of Learning
The Mailbox That Ate Its Own Message
Situation
For years, Donald's multiplayer games had relied on Apple's MultipeerConnectivity. It was beautifully simple when it worked: two nearby devices discovered each other, connected, and exchanged game packets.
But the real world had begun to disagree with the word nearby.
Two devices could be sitting almost next to each other and still fail to connect when Wi-Fi was unavailable. So Donald began building a tiny Internet backup: not a grand multiplayer platform, not an account system, not a matchmaking service—just a little bridge that could carry game packets between players.
The first version was almost comically simple.
There was one server mailbox.
A device would POST a message.
Another device would GET a message.
FIFO.
Done.
Or so it seemed.
Turning Point
The first real test exposed the problem immediately.
Both devices were polling the same global mailbox.
Donald watched a guest send a playerUpdate, only to discover that the guest itself could receive that packet back.
The iPad had eaten its own message.
"Did iPad take away all its own msg(s)? LOL"
Yes.
The mailbox had no idea who the message belonged to. It only knew that someone had put something into the queue and someone had asked for the next thing.
That tiny bug changed the architecture.
A multiplayer game cannot really have a single anonymous mailbox.
It needs a room.
And inside the room, it needs players and player-specific mailboxes.
Emergence
Instead of making the server understand Xiangqi, chess, Golden 24, moves, captures, or game rules, Donald kept the server deliberately stupid.
A room contains:
a unique room ID
a short four-letter join code
a host
a list of players
a mailbox for each player
A host creates a room.
A guest joins with the four-letter code.
Then packets are routed explicitly:
sender → recipient → packet
And for broadcasts:
sender → everyone else
The first production test created room BVBH with Donald, Rhea, and Cindy.
Donald sent:
hello-everyone
to *.
Cindy received it.
Rhea received it.
Donald did not.
Then Cindy sent:
hello-donald
directly back to Donald.
Donald received it.
The final test was almost poetic:
Donald polled his own mailbox after the broadcast.
{"message":null}
The mailbox did not eat its own message anymore.
Learning
The interesting lesson was not really about HTTP.
It was about discovering architecture through failure.
The original global FIFO was small and elegant—but it encoded an assumption that stopped being true as soon as there were two independent pollers.
The solution was not to make the server clever.
It was to give the messages enough identity to be routed correctly.
That led naturally to:
Room → Player → Mailbox
and:
senderID → recipientID → packet
The same mechanism can now serve a two-player Xiangqi game, a three-player Golden 24 game, or a future multiplayer game without the server knowing what game is being played.
Theme
When a simple abstraction meets reality, the bug can reveal the architecture.
What Is Possible
A tiny Node server with no database, accounts, matchmaking, WebSockets, or game-specific logic can provide a practical Internet bridge for multiplayer games.
How Does It Happen
Create a room, give it a short join code, associate players with the room, and route packets into explicit player mailboxes.
Why Does It Matter
A good abstraction is not the one that looks simplest before the first failure.
It is the one that survives contact with reality.