- Entry date
- 15 February 2022
- Category
- Tooling
- Access
- 🔓 Public
A small XMPP client, built to answer one question: how do two processes actually talk to each other in real time?
- SleekXMPP
- protocol library used
- Feb 2022
- built and working
Honest evaluation
The narrow claim — a working, protocol-correct XMPP client — was fully met; no larger claim was ever made for it.
What would prove or disprove it further
What would prove or disprove it further: there's little left to test on the claim as stated — it's already a working, end-to-end protocol round trip. The more interesting falsifiable question sits downstream, in the WebSocket and MQTT work this entry is credited with informing: does that later work actually show measurable design continuity from this client's connection-and-auth handling, or is the lineage closer to folklore than fact? That's checkable directly, by comparing the codebases.
The evidence — full reasoning behind the verdict
Verdict: proven. The claim this report actually makes is narrow — a working, protocol-correct XMPP/Jabber client, sending and receiving messages over a real federated protocol — and that claim is exactly what the client delivered.
Connect, authenticate, send, receive: all confirmed against a real XMPP server rather than a mocked one. The honest bar for "a small utility that works" was cleared in full, and nothing beyond that bar — a UI, persistence, multi-user rooms — was ever claimed for it.
Not every entry in this archive is ambitious. Some are small, deliberate reps of a skill that turns out to matter a great deal later — this is one of them.
What it was
A messaging client built against XMPP (the Jabber protocol), using Python's SleekXMPP library, capable of sending messages over a real federated protocol rather than a proprietary API.
What we built
ResearchA working XMPP client — connect, authenticate, send a message, receive a message — over the open XMPP/Jabber protocol. Nothing more elaborate than that: no UI beyond what was needed to prove the protocol round-trip worked, no persistence layer, no multi-user rooms.
What we learned — including the honest negative(s)
XMPP is a federated, real-time protocol older and more standardised than most of what came after it, and working with it directly — rather than through an SDK that hides the protocol — is a useful, unglamorous rep of a question that recurs constantly in this portfolio: how do two processes actually talk to each other in real time? WebSockets later, MQTT for train communications later still, all of it is a variation on the same problem this small client first made concrete.
The honest edge is that this was never meant to be more than that: a small utility, not a product. It's kept in the record for completeness — an honest data point in the timeline — not because it represents ambition or a commercial direction.
Where it went / status
Finished and shelved in early 2022. It was never developed further and there was no plan for it to be. Its value shows up downstream, not in itself: the real-time-messaging instinct it exercised resurfaces in the WebSocket layers built for later platforms and in the MQTT layer used for real-time train communications in the safety-critical rail work that came years after.
It's a small entry by design, and it stays in the record for exactly that reason: not every rep needs to be ambitious to be useful. Sometimes the smallest, most complete example of a pattern is the clearest one to point back to later, once the pattern has grown into something much bigger.
What is still open — kept visible
The honest edges, next to the wins. This is what turns 🔬 into 🟢 — honestly.
- A small utility, not a product — it sends messages over XMPP, nothing more.
- Kept in the record for completeness, not for ambition; there was no plan to develop it further.
Sources
- vocabotics project audit — XMPP Messenger / aaconvert (Python, SleekXMPP), Feb 2022vocabotics internal project history · as of February 2022