jdev - 2026-03-28

If anyone might be interested, I've been working on a hobby project xmpp client of my own, that aims to decouple gui and backend (the backend can run as a daemon that any language can talk to). Also, its aims to do advanced archive management - local cache can store disjointed regions of the remote archive. It supports server-side message search. It can jump to an arbitrary point in history fetching it from server as needed. E.g. here's a screenshot of this chat's history from 2020, made from a project that didn't exist a month ago

https://upload.yax.im/upload/ED1AEgPj4_uoC3DYQpDI7Erd/Screenshot_2026-03-28_15-48-19.png

the client itself is made in tcl https://github.com/pounceandmiss/tacky and an proof-of-concept alternative frontend in pyqt https://github.com/pounceandmiss/qtchat

> If anyone might be interested, I've been working on a hobby project xmpp client of my own, that aims to decouple gui and backend (the backend can run as a daemon that any language can talk to). Also, its aims to do advanced archive management - local cache can store disjointed regions of the remote archive. It supports server-side message search. It can jump to an arbitrary point in history fetching it from server as needed. E.g. here's a screenshot of this chat's history from 2020, made from a project that didn't exist a month ago Why not as a library? ↺

It can be used as a library as well. In fact, its own frontend can transparently switch between using it as a library (in process) or as a daemon (separate process or thread with a wrapper in process) ✏

Why I think daemon mode is beneficial is that any other language can speak to it in json from any other event loop.

the client itself is made in tcl https://github.com/pounceandmiss/tacky and an proof-of-concept alternative frontend in pyqt https://github.com/pounceandmiss/qtchat

so a new custom protocol between frontend and backend? Why not XMPP? cause you'll have to solve all the same problems

it's been tried before and ended poorly https://mail.gnome.org/archives/desktop-devel-list/2017-September/msg00047.html

It's always been interesting to me how much the telepathy people seemed to think it didn't go well. The best messaging stack I have ever used was telepathy based and it worked so well. But I guess maybe it was annoying to develop. Of course multi protocol is always hard that's part of why I personally prefer gateways. ✏

The issue is that you have to go with the lowest common denominator for some things, but then special case everything else - so its ends up being less effort just to special case everything, which defeats the main point

> so a new custom protocol between frontend and backend? I guess any library is a new custom protocol in a sense.

no, a library is not a protocol

you could argue any interface is a protocol in some sense of the word, but i'd personally assume its gotta be two or more processes communicating a stream of data

https://files.isekai.rocks/file_share/019d3541-872a-706b-b3ba-7aa47a11ac25/3417497a-0f1b-435d-8eb1-f9850da80a43.png

holy shit its me

>> so a new custom protocol between frontend and backend? > I guess any library is a new custom protocol in a sense. True ↺