I still don't have a great setup for audio based coding. ed seems cool in theory but I need a better way to make bigger edits at the ast level and have a better way to integrate with LSP level info for my linters and compiler errors. Swithing is still a bit annoying between these tools. Maybe an alias for sed that handles muli line find and replace and then auto runs my linters could work? That's basically how my llm harness works and how I navigate with graphical editors when I code.
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.
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.
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.
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.
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
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.
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.
@jcsteh @TheQuinbox @mew My ebook reader has pauses in between paragraphs from rendering the next bit of speech that drive me bonkers. Currently figuring how to stream some text in this neural net based TTS so it can be actually passable. 😭
At my organisation, Copilot for MS Teams transcription (or whatever it’s called) is now disabled org-wide because there was a scare based on the fact that Copilot “hallucinated” something that was not said at this meeting, which was then actioned by a non-attendee as a real point.
Thankfully, whatever this was, was caught before it was fulfilled/implemented by someone who does governance checks, but hahah it’s really darkly comic to think that we could have done something that nobody asked for and nobody wanted because Microsoft’s shitbot inserted it in a transcript
Occult cyberpunk. Yap with me about decentralized systems, wearable computing, and biohacking.