I think my philosophy when making software is that it should work for people with zero money or no bank account / credit card.
I know it's not a popular mindset to be in since money and profit is everything in the tech world.
I think it comes from growing up as a kid with no disposable income or access to anything but my shitty computer.
I'd rather support people with almost nothing than people with latest and greatest tech gizmos and spare cash for subscription services. 😅
LLM stuff
I haven't had much of a need for skills so far because the models are pretty capable even with minimal prompting and I found that skills often fill up the context more than is strictly necessary. I was thinking for ergonomics I'd have users define skills in their "documents" folder to make it more intuitive for graphical interface users.
LLM stuff
I've recently added support for AGENTS.md so I don't need to tell it how I want to do testing and code style checking every time and generally save some extra file reads whenever it starts a new feature. Next I'm gonna play with "skills" so I can load up commonly used instructions instead of repeating myself.
LLM stuff
I think part of this is that I've gotten better at working within it's limitations and strengths as I've been updating my "agent" to be more effective.
LLM stuff
The scary part here is just how long it can remain coherent as its contexts fills up. Even 3.6 would get confused quite quickly and need to be compacted after a few hours. This thing managed to ingest files from like three codebases and still have space for generating a weird setup for testing a react-native component.
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.
Occult cyberpunk. Yap with me about decentralized systems, wearable computing, and biohacking.