Lately I've been working on some daemons and infra for making daemons so I can have backgrouded apps that I can talk to from the cli in multiple terminals instead of having to deal with single instance UI hassles.
Mainly I'm working to make a sort of alernative to libpurple which uses domain sockets between bridges instead of having all that stuff in a single app. I'll be taking hits with this IPC protocol, but I think the reslience and ease of use cross language will be worth it.
The thing that inspired me was actually the operation of my #matrix homeserver that has *all* the bridges. The different protocols being their own services has been great. All the extra stuff and needing to run a server has kinda sucked. The matrix data model is also hard to build lightweight clients for which has also been hard for progress.
Look, oplogs are great as a datamodel for mostly online systems that need full replication, but they aren't great for performance and being able to quickly show a user just the data they need in the moment right as they start the sync. Waiting for an entire sync is just not reasonable when your message volume gets high. This is why we need indexing at the protocol layer. Blogged about it here: https://blog.mauve.moe/posts/peer-to-peer-databases
Sidestepping all that will make things easier. My system uses a shared service that hosts an encrypted sqlite db that gets unlocked by the user during startup. The chat bridges hook into that for storing data and can do an rpc call to wait() for it to be unlocked before doing the rest of their init logic. I've become convinced SQL is just the easiest tool for this accross languages by a bunch of apps I've read the past few years like CoMapeo.
So, from here bridges and clients just need to know the rpc protocol, probably json rpc split by newlines since it's easy to parse in any language. Then HTTP servers for blobs like images since JSON sucks for binary data. Now I can use whatever language sucks the least for whatever alt client ecosystem.
Now from here we get into the dirty parts which is LLMs. The fact is that there are a lot of centralized chat apps with different data models and url layouts for their endpoints. My guess is that once I have a data model, I'll be able to convert a lot of the sdk example docs into using the system and my local Qwen3.8:27b setup. I'll still need to understand how they work but it might be less typing.
Anyway, once I have some of the bridges set up I'll work on my audio based notification daemon. I'll use one of thos TTS models that do "voice cloning" and use my voice with different affects so I can assign voices to specific chats or app sources. Kinda like how I use SpeakThat to have all my chats and email notifs right in my ear. But better because I can ditch android and have more customization than the apps give.