To create an invite you:

# drop into mongo shell
docker compose exec database mongosh

# create the invite
use revolt
db.invites.insertOne({ _id: "enter_an_invite_code_here" })

That’s pretty jank.

Also - I’m getting pretty fed-up with self-hosting documentation that assumes very specific environments and goes into detailed configuration for that environment. Don’t tell me how to setup a server and how to enable/configure SSH and setup UFW as part of setting up your software. Just tell me how to setup your software and what ports it uses.

That fuck you mean? You can use these drives for any purpose you want.

Sounds like you haven’t taken the time to properly design your environment.

Lots of home gamers just throw stuff together and just “hack things till they work”.

You need to step back and organize your shit. Develop a pattern, automate things, use source control, etc. Don’t just file follow the weirdly -opinionated setup instructions. Make it fit your standard.

The last thing I want to see when I clock out is another terminal screen.

I’m reacting to this mostly. Self-hosters are a bit of an obnoxious blend of people who want turnkey-but-not-Google solutions and people willing to learn how to do things. People whining about “having to use a terminal” are generally in the former category.

Then don’t self host?

…it answers from the attached KBs only. If the fact isn’t there, it tells you - explicitly - instead of winging it.

So you’ve made a FAQ with a LLM interface? I could see that potentially being useful for cooperate “let our bot answer your questions” tools.

But the usefulness of AI isn’t just in “tell me a fact”. Like what would your AI give for "what functions would I use in Python to convert a utf16 string to utf8? Would the answer need to be in the KB already?

Apparently it doesn’t.

Section 1 says you’re using freedns.afraid.org though.

Aye - that’s another reasonable use of the phrase.

Ugh really? I haven’t seen that myself but that’s frustrating.

Non-containerized applications. Not in a container. It’s not complicated. Running “on bare metal” sounds cool but it’s a wildly inaccurate description. Containerized applications run on the system natively just like non-containerized applications. So if one of them runs “on bare metal” then then others do as well.

But historically “on bare metal” is used for embedded or micro-controllers where you don’t have an OS.

• Users will stop referring to non-containerized applications as “running on bare metal”

What “other technology” is going to make sure your API doesn’t have SQL injection and bad authentication vulnerabilities?

You know what? Rather than over-complicate things you can probably just check that filenames only contain a small set of white-listed chars. [a-zA-z-._] (and != ‘…’ or ‘.’) or something.

And one other nit-pick if you’re up for more code-review - your authentication logic should probably be inverted:

if !ok || user != session.config.username ||
				pass != session.config.password

I’d change that to be something like

if ok && user == session.config.username && pass == session.config.password {
   // do login
} else {
   // not auth
}

There’s a whole category of security errors where an exception in logic like that causes the code to skip the “you’re not allowed” logic and go right to the “you’re allowed!” block. It’s more of an issue with languages that support exceptions but it’s still considered a best practice generally (it’s also typically easier to read).

“Security” is not just “ssl”…

Ah - I missed that other parms were keys. Still - best practice is to sanitize all user inputs. Try throwing lots of file-path-like args at it to see what it does. it’s a historically tricky problem so there should be some libraries that help with it.

Happy 2026! And happy hacking!

You try using “…/…/…/…/…/etc/passwd” as the filename in your requests? I don’t see anywhere where ‘…’ is escaped or removed from file strings. Sending untrusted filenames directly to file operations without scrubbing and sanity checking is very dangerous and potentially allows a malicious user to read and overwrite any files the application has permissions for.

I think you should make it more clear in your docs that this is wildly insecure and should be restricted to “tinkering” usage only.

That said it seems like a fun project to write.

Ssh port forwarding and socks proxying. Unless they block port 22.

Edit: If they do block port 22 run ssh on port 443.

AI is so much faster than reading docs. And you get context specific responses that you can drill into. When used correctly it’s very useful.

This was using it… incorrectly though…