Mauve 👁💜 @mauve@mastodon.mauve.moe

I'm going to be trying something new with this by releasing this for free for nerds that can install from github/npm, but charging a small fee when I publish in the major app stores. Does five bucks USD sound reasonable?

Just published this tool for managing tunnels between devices using #p2p networking. Kinda like tailscale but without the need for central services. Desktop app release is incoming later this month. https://www.npmjs.com/package/setkamost

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.

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.

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.

https://github.com/RangerMauve/mind-goblin/commits/default/

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.

Qwen 3.8 27b is scary good! At least at more routine stuff where I tell it what to do.

How people react to the term "computer toucher" tells me a lot about how deeply I can get into the details of my technical interests. If it's amused confusion then I hold back the freak levels. If they're unphased I might talk about data structures

I'm pretty excited to build some utilities for these bone conducting headphones with a camera. From the reversing I've done on their app it's been pretty funky. It does file transfer over wifi direct! So freaking insecure (from what I can see) but it'll be fun!

I'm excited for winter because it will get dark and empty sooner and my fave tunnels to paint in will stop being flooded.

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.