> I also try to make sure my server has useful bots, a small thing but every bit of utility and differentiation with proprietary services helps.
Can you share more about this? I hadn't thought about this, but that's an advantage over SMS, though I don't have good ideas for bots my friends/family would enjoy.
> For that reason I bridge everything and always meet people where they are and constantly show off to them that even if they sms/telegram/WhatsApp/messenger/slack/discord/signal me then I get it in one app with no tracking or ads on my physical phone that I carry in my pocket.
How do you bridge SMS/WhatsApp to Matrix? Something like Beeper?
I tried Snikket and ejabberd on the server and found Snikket way easier to use.
I haven't tried any Snikket clients because I'm tinkering with web apps to start and it looks like Snikket doesn't have a web client yet outside of the admin portal.
I really like that Snikket allows me to create invitations without relying on SMTP. I love having it just as a URL I can send however I want.
I wish I kept better notes on my Snikket onboarding because I did run into a few hiccups.
I find the concept of "Circles" unclear because I don't understand how it differs from regular users. Thinking about it more, I'm assuming the idea is that I might have a family group and a college friends group, but I don't want my dumb college friends messaging my mom even though they're all on the same server?
My more superficial note is that I find the admin UX a little rough. It feels a little early 2000s design where everything is a form submit when there could be more JS interactivity (and this is coming from someone who hates JS frameworks but likes minimalist JS like htmx). And there are four top-level admin actions, and one of them is "Invitations" but that seems to duplicate everything available to me under "Users."
Yeah, no web client yet, but we're working on a web app (it exists already, but doesn't do end-to-end encryption fully yet, also no video calls). My primary use case for Snikket was displacing things like WhatsApp where web usage is (in my experience) rare, so the focus has been on mobile apps.
Circles - yes, you got it. Initially we launched without circles, and some people complained they couldn't invite friends to their server without those friends mixing with their family members by default. I wasn't sure at first, but now even use this feature myself for e.g. a "Games night" circle. You can read more about the feature here: https://snikket.org/service/help/features/circles/
And yes, I totally get what you mean about the web dashboard. We're toying with replacing it at some point (partly because the backend is Python, and it uses over 2x the RAM of the chat server when idle!).
> I'm happy to test crazy new ideas and throw out what doesn’t work well. It was able to wire & test a huge change to Mumble that added better noise cancelling; I use my beta build of it nearly every day.
To me, this is a negative and mostly irresponsible use of AI.
OP dumped a huge PR (edit: not actually huge) on the Mumble maintainers,[0] which didn't match project conventions. He left a bunch of unresolved conversations with Claude that are hard to follow because it looks like an insane person having a conversation with themselves.
Then, the Mumble maintainers gave him pretty polite, patient feedback, and he just ignored it. No follow up for going on three months. Granted, the maintainers left the PR in the queue for four months, so it's not like OP is the slowest link, but I definitely wouldn't point to this as a win when there's basically no traction on the PR or any indication this will be merged.
Edit: radlad is correct that the PR is not "huge" at ~300 LOC. I was reading on my phone and didn't check the PR size and mistakenly trusted OP's assessment of "huge."
I dunno - it looks funny, and can definitely add to the "noise" versus the signal of the PR. But it also demonstrates to the maintainers what level of input the contributor had versus simply posting the first thing Claude came up with. (And can be helpful as a maintainer to see how the contributor is thinking about the problem.)
The maintainers clarified they'd prefer a single "all-in" commit, and OP hasn't (yet) addressed that.
Also, unless I'm misreading this PR, it's 270 lines added, 20 removed. I certainly wouldn't call that "huge."
I thought it was pretty common? Pre-LLMs I've always opened PRs to self-review before asking anyone to review it (sometimes leaving myself comments), now I'm also having an agent review it and leaving its own comments that I might answer, seems like a very normal thing to do.
I do ensure these self-conversations are resolved so that the PR is clean when I ask other reviewers to have a look, and I don't think I'd do that on an open-source project. But I'm very much shrugging at this practice.
I think what OP did is poor practice. From the maintainer side, how are they supposed to know when the PR is ready for review? Are the maintainers expected to keep checking in on the contributors' threads with themselves to make sure everything is wrapped up?
To me, there's two things you can mean with a PR:
- Open a normal PR: I personally attest to the quality of the code, and I'm ready for the maintainer to review/merge it.
- Open a draft PR: I have questions about proceeding and want to show you a work in progress to give context.
Any kind of intermediate work to prepare it for the maintainers should happen in a fork, not adding noise in the official repo. When you're done experimenting in the fork, then it can go to the main repo.
A single binary accomplishes most of those things just fine. Only thing it doesn't get you is isolation, but you can isolate things if you want even then (for example, FreeBSD jails are dead easy to set up).
ok, so you're just using a container with a different name? You can put the single binary in a container and call it a jail if it makes you feel better.
Well yes, but that's the point entirely - you can easily put a binary into a docker container, or a jail, or on a VM. But when something is shipped as 5 different docker containers it is MUCH harder to extract it into something you can run without docker or in a different configuration (like sharing a postgres instance between multiple applications).
One distribution method is flexible and can be deployed however you want, the other prescribes solutions and makes any customization difficult.
I'm confused. The original post said "why docker compose? a single binary dominates any docker compose", (I assumed dominates here means wins over because it wouldn't make sense otherwise?) someone replied giving the additional benefit of containerization, then someone replied to that saying you get all those benefit from single binaries, and if you want the system isolation you can use a freebsd jail, which is like saying "if you want the benefit of containers you can use containers"
Most applications do ship in a single container. whether it's a single binary inside, or a bunch of python or js files or shell scripts is a separate issue. If there is a dockerfile then you know how to build the container. a single binary is easier to build the container for yourself, assuming you also know the binary dependencies of that single binary. Like maybe ffmpeg or yt-dl cli on the path?
Applications that ship as a list of containers are a completely different problem. Those applications are either a victim of their own success, or have developers that come from a particular background.
I've never felt hindered by docker. It's pretty flexible. If I need even more flexibility I'm reaching for k8s, where I am still containerizing any single go binaries
Are you saying it's hard to edit a docker compose file? Being one service or 5 doesn't really make things more complex. I often point servers at my own postgres container instead of spinning up an extra one (so just remove that from the compose for example). That's kind of the entire point of compose, it's so flexible.
All my home server apps are in /apps/app-name/ all have a docker config... All data and configurations are mounts under that directory or to my library. It's really straight forward.
I don't have to hunt for different configuration files, each app has what it needs.
I can spin down, move and get back up in a minute or two. All in a consistent way to the platform.
The overhead for Docker isn't near a full vm, it's maybe 2-3% if that.
>The overhead for Docker isn't near a full vm, it's maybe 2-3% if that.
Interesting, I run audiobookshelf bare metal on my old laptop that only has 8gb of ram. I've considered using a docker container but my experience using rancher for work is that it sits there chewing up 4GB of ram on my company MBP.
Maybe I'm wrong but I've never seen the point in a self hosted app running in a container when it seems much lighter to just run the app?
I don't use Docker but I love reading the compose file when a project has it. It is the quickest way for me to get a high level idea of this project's architecture. It's the best documentation :)
This. Docker compose is so great that you don’t even need to use it, for it to be useful. It can describe so well the dependencies your system needs (alongside proper documentation).
It’s the unified interface for me. Updates, logs, service management, network routing, config and storage mapping are all uniform and I don’t have to wrangle many slightly different implementations of each. Isolation from installed packages is a nice bonus.
I too prefer the Docker compose route. If you give me a single binary, I'll go out of my way to run it inside a compose stack.
I manage my home server with a script that presumes the service is running on a compose stack. So I can run stuff like `stack freshrss restart`. I don't want to touch my scripts, I just add the compose file to some expected path and the script finds it based on naming conventions.
for long-running services, I've never taken the time to learn something reliable like systemd. with Compose, I can see everything I need to know in one yml file and the commands to go with it. I also don't have to really understand any dependencies or their own configuration and can cleanly remove everything associated with that service with a few commands.
You can use systemd and docker compose together. A systemd service is a single config file that runs the commands you give it, including `docker-compose` commands. Everything else about your service is still orchestrated via docker, and you can still run commands against the running containers just like before.
A big win with very little effort is systemd starting your docker compose service on boot. You have your systemd config file set `ExecStart` to call your docker-compose command, throw the config file into your systemd folder, and tell systemd to enable it. Docker compose handles the rest.
I use Docker Compose so that I don't have to care if the daemon is a single binary or a whole stack: I can use the same setup for everything, and deploying an entire new thing in a maintainable way is quick and easy. Each app's startup/shutdown is managed using the same templated systemd unit, and Traefik handles the routing and Let's Encrypt cert creation and renewal.
Basically I want things reliable and low-maintenance and this setup gives me that.
I like to have consistent architecture across all my services, and I like to see and configure everything in (mostly) one place. If you're running a single go binary, sure do whatever, but if you're running a go binary, and a *arr stack, and a bookmarking service, home assistant, frigate, etc, it gets out of hand pretty quickly.
You trade a bit of upfront setup (I mean barely now in the age of LLMs) for easier automation and flexibility down the road. I use docker compose to run my local dev stack and qa envs, but then can do whatever I want with the containers for prod. Google Cloud Run, Amazon, whatever. Right now I do just actually use docker compose behind nginx in prod, but I've used basically the same docker compose setup for all my projects that aren't large distributed systems in the last 10 years. And when the system gets too big, I refactor it into k8s, but k8s is overkill for like 99% of my personal projects and like 75% of my professional projects.
I’ve been a die hard native package or static binary proponent for a long time. I still hold that there are real advantages.
As podman has improved and compose stacks have improved, I’ve conceded that containers simplify deployment and updates and isolation, and at this point I find for me the benefits more than outweigh the hassles.
Instead of crafting a set of ansible plays that do all the manual native installation steps, I have a relatively lightweight ansible rig that reads containers and relationships desired from a manifest in inventory, then builds or modifies compose files, then just deploys. Much less futzing. And I’m more likely to keep things up to date regularly as a result
Or, increasingly, dispatch codex to handle it for me
In this way I update home assistant across multiple instances now like magic. I don’t even dread it a little anymore
Some isolation is nice. I say some because I’m told it’s security is not to be trusted, but I still like that even a non nefarious binary has ootb boundaries on what state will persist.
docker isolation is nice just as a management boundary. It's nice to be sure applications don't accidently shit all over each other. Like an application that decides to clear /tmp because reasons, or 2 random ones that both store temp state in a /tmp/state.dat for some odd reason.
My favorite is applications that conflict on ports. So you go to change the port an application is listening on, the docs say PORT env var so you set it, but it doesn't work.
You look through the code (and this is before LLMs) but the config is just a labyrinth of values flowing from god knows where. So you search the repo for PORT and eventually find a PR from 2 weeks ago that changes PORT to ENDPOINT, so you set ENDPOINT, but it still doesn't work.
Then you find an issue that was opened last night that the new `ENDPOINT` value doesn't load from env vars because it conflicts with another ENDPOINT_ prefix on another value, instead you need to create a config.toml and set an `endpoint =` in that, so you do that.
Then you realize that creating an empty config.toml has now overridden all the previously defaulted values into nulls or empty strings, instead you need to run `foo config-defaults > config.toml` and go edit the endpoint one.
Only to realize that there is a secret that the tool uses to encrypt an ephemeral session. if you don't specify one, the tool would auto generate one on startup. The only downside is restarting it logs your client out which isn't a big deal. But now that you switched to config.toml you must set some value there and it can't be empty
Then you're just wondering why the hell did I want to change the port?
Docker isolation is likely good enough if you keep your kernel up to date and aren't allowing 3rd parties to run code. If you are running a CI service or something you need micro VMs. But to host your nextcloud server, docker is good enough, it's unlikely someone will both exploit nextcloud and the kernel if you are keeping them up to date.
Not OP, but i prefer a single binary on docker, at least i know it won't fuck up my filesystem when i do something stupid with it.
Or at least i can reinstall any time i want, because i know it won't leave any trash in my filesystem and when reinstalling, it won't reuse those outdated files
I don't expect the model to be trained on the latest features of the harness, but I think the harness should ship with its own docs so that the model can quickly search local docs rather than search online page by page for docs that don't necessarily match the local harness.
I didn't want to complain about OpenCode too much because it's open-source and kind of the scrappy underdog to Claude/Codex, but I do find its multitasking support pretty limited. I have to specifically remind it to spin up subagents, and when it does, it'll do 2-3 tasks in parallel and then wait until all of them finish. It can't seem to inspect tasks in progress, and if a subagent dies or hangs, the main agent can't seem to retrieve any information from it, even though I as the human can look at the session and see what happened.
Are you doing anything special to make OpenCode multitask well?
I'm using opencode v2, if it matters.
I don't have any special skills / prompts for subtasks. Instead, I found new models (I usually have sol or opus as my main model) have the tendency to trigger subtasks, even to a level I need to ask it "please do this task XYZ yourself". The only special prompt I gave is just something like "please use gpt sol or luna for subtasks, base on your judgement".
And in my experience it can handle more than 5 async subtasks out of the box
I'm confused about opencode's v1/v2 split. The docs say v2 is here, but their Github is only v1.x.[0] And the docs don't really explain why v2 is better, but there's a long list of things I have to do to migrate,[1] so I haven't been that eager to pull the trigger, especially since I can't tell if they consider it alpha/beta/release.
If you use Nix it's a flake so super easy to run too.
Seconded that v2 has much better background shell + subagent management: it's now much more eager to appropriately spawn either of them on its own, and does so in a way that is asynchronous, i.e it doesn't block the conversation and you can examine them by pressing down arrow at the prompt box.
I'm confused how you see this article as a complaint about Pi. I only mention Pi at the very end to say it's one of the agents I've tried. I checked it out, found it too barebones for me and moved on, but I understand why some people prefer it. The existence of Pi isn't a counterargument to, "Why don't agents support development workflows that should be commonplace?"
The point is that pi ticks several of your wishes (e.g. knowing its own capabilities without searching the web). And it's easy to extend. I don't know Typescript, but I just ask Pi to extend itself with feature X, and it does it.
I think knowing its own capabilities is the only thing Pi does out of the box that matches my wishlist.
But I'm still kind of puzzled by this critique. Isn't it kind of like saying, "Why are you complaining about the agent? The C programming language exists, so you can use that to create any agent you want."
Your analogy is flawed; my critique is at somebody with a printer annoyed they can't get it to print its own instruction manual, so they've drafted one with a pen and are passing it around for feedback.
Why aren't you using the printer?
If you can't use the printer, why do you believe that other people should believe your ideas about the printer are worth listening to?
Feed your blog post to pi - have it implement it - and you will realize pretty quickly that a lot of them are flawed. This would have costs you about the same time as writing this blog post.
I'd rather be reading the blog post that comes after you reflect on what you got wrong and right. Better yet, the blog post after you've iterated enough that you believe your ideas are right.
I don't care for your hand drawn instruction manual on how to use the printer.
> my critique is at somebody with a printer annoyed they can't get it to print its own instruction manual, so they've drafted one with a pen and are passing it around for feedback.
> Why aren't you using the printer?
You've lost me. Didn't you establish that the printer can't print its own instruction manual? How would I use the printer to print the instruction manual when it can't do that? And can you spell out for me how this relates to my critique of agents?
If this is about my gripe that agents have to search online for their docs, that's my most minor grievance because they can still access their docs. I just think it's a dumb time tradeoff that they don't ship docs alongside their binaries because if the docs were locally available, the agents could search them faster and guarantee the docs matched the binary.
> Feed your blog post to pi - have it implement it - and you will realize pretty quickly that a lot of them are flawed. This would have costs you about the same time as writing this blog post.
I never made the claim that Pi could implement these features trivially. If your claim is that Pi can do this so easily, you should be the one feeding my blog to Pi and showing me the results.
I'm confident that Pi could not implement all the features I described in the time I spent on this blog post (about five hours), so I have no reason to waste five hours trying, but if you're confident I'm wrong, you're welcome to spend your own five hours disproving me.
You didn't just give a critique of agents, you made an actual wish list on how to improve them.
You are self-assured enough to think you know better, articulate enough to write down what it ought to do.
I'm stuck because i do not know how to talk to you. I can empathize with people not mentally flexible enough to use these tools that feel stuck. Thinking about workflows is not trivial. I can argue with people who do build their own workflows; about our experiences what works and what doesn't and why.
Your frustratingly falling in between. You obviously have ideas, but you didn't bother to have them meet reality and get refined by it, yet you seem to want others to consider their merit - as though that's a good use of their time.
In the analogy the printer does work.
I'm needling you - since you've claimed my attention to show me your draft of the manual - to turn the damn thing on before we continue discussing the merit of your ideas.
I dont know how long that's going to take you the first time, but once you've found ideas that do survive contact with reality - instead of presuming they will - you can delete the code and absolutely rebuild them from scratch with pi in 5 hours.
Or - if you're happy to - i'll politely bikeshed the color of the title or something and move on.
I think most people are criticizing your overall stance. Your whole post is "Agents can't do this" and "Agents can't do that."
If I wrote a blog post complaining that "Programming languages don't let me do memory management", would you not think it's fair to respond with "What are you talking about? Have you heard of C?"
> I think most people are criticizing your overall stance. Your whole post is "Agents can't do this" and "Agents can't do that."
My take is that agents don't do the expected thing out of the box. I acknowledge that you can extend some agents and customize them, but I'm saying that it's sort of silly that the features I think most people want don't exist as default, out of the box standards.
> If I wrote a blog post complaining that "Programming languages don't let me do memory management", would you not think it's fair to respond with "What are you talking about? Have you heard of C?"
I don't think that's a fair comparison because C does let you do memory management out of the box. I think the better comparison is like, "Go doesn't let you do pattern matching," and the response is like, "Why don't you just patch Go to let you do pattern matching and maintain your own fork of Go?"
I wanted to do this but I found it hard to secure it in a way that anyone can join meeting links I send but I'm the only one who can create meetings. It seems like Jitsi intentionally makes this hard so that you buy their hosted plan instead. Have you found a good solution?
Authentication and securing meetings is a point of friction in Jitsi. I wouldn't go that far to call it intentional. But if it is - I'm okay with that. Since it's open-source, somebody have to make money to keep developing software and pay bills at the same time.
On many occasions I found it annoying that auth cookies expire after a day or less. And the most confusing thing for me is that it doesn't work well with 1Password, so I had to type my passwords like a caveman.
I solved it in few ways:
* I added common rooms to the bookmarks so I can quickly host them
* I added another user for my partner so she can host meetings too.
* Since it's open source, I changed the code so that auth cookies stay active for 30 days, instead of 1 day.
* Just this morning I've been exploring mobile version of Jitsi meet, where you can click on room name in 'Recents' and join quicker. This is a win for non-technical members of our family.
> I also try to make sure my server has useful bots, a small thing but every bit of utility and differentiation with proprietary services helps.
Can you share more about this? I hadn't thought about this, but that's an advantage over SMS, though I don't have good ideas for bots my friends/family would enjoy.
> For that reason I bridge everything and always meet people where they are and constantly show off to them that even if they sms/telegram/WhatsApp/messenger/slack/discord/signal me then I get it in one app with no tracking or ads on my physical phone that I carry in my pocket.
How do you bridge SMS/WhatsApp to Matrix? Something like Beeper?
reply