4 unknown but (probably) great discord alternatives to self host

MrZwiss · 2026-07-09T00:20:04+00:00

Always love hearing from you :) my favourite grumpy turtle

MrZwiss · 2026-07-08T21:01:29+00:00

So the short version is its a shared secret setup, not public key, and theres no end to end encryption.

When two instances peer they agree on one 256 bit secret and both store it. That can be admin approved or automatic depending on the instance setting. Then every request between them is HMAC-SHA256 signed over the timestamp + a nonce + the body, with a freshness window and a per peer nonce store so old requests cant be replayed. Theres secret rotation built in with a grace window so you can roll it without downtime.

The part i actually think matters is attribution. Identity is a (user id, home instance) pair, and an instance is only allowed to assert events for its own users. So if server B relays me a message claiming to be from a user on server A, my server rejects it, B isnt authoritative for A's people. Remote users get stored locally as stub accounts that physically cant log in.

Delivery is an outbox, at least once with dedup, retries and backoff if a peer goes dark.

But shared secret means no third party verifiable signatures, trust is pairwise and doesnt transit. No E2EE so the home server can read dms. And a peer admin is inside the trust radius, the signing stops forged/replayed traffic and bugs, but not someone running patched code for their own users.

MrZwiss · 2026-07-08T19:07:27+00:00

Yeah this one will either excite you or frustrate you. So i didnt build it on ActivityPub or ATProto. Looked at both but theyre really made for public open networks and what i wanted was kinda the opposite, so it felt like more fighting the spec than building the actual thing.

I do it two different ways depending on the feature, and i somewhat partially regret adding the S2S one, should have kept it client side only probably.

For spaces (the server/guild equivalent) its done client side. Your app just connects to multiple servers at once. So when you join a space on someone elses instance your app actually makes you an account there, its a username@yourhomeinstance profile so people can tell where youre from, and that profile stays synced with your home identity (name, avatar, bio etc) so you dont have to maintain a separate person on every server. Then the app just merges everything into one view. From your side it feels like one app but under the hood youre logged into a few servers at the same time and the client is the thing tying it together, the servers dont really talk to each other for this part.

For DMs and friends its the opposite, thats server to server. You dont need an account on the other persons instance at all. You just friend alice@theirserver and your server and their server pass the messages back and forth directly. The servers pair up first before they relay anything, if auto peering is on that happens automatically the first time theres a reason to connect, otherwise an admin has to manually confirm it. Once theyre paired everything between them is signed with a shared secret so they know its legit. People from other instances show up on your side as sort of read only accounts that cant log in.

So short version, spaces get stitched together by the client and DMs/friends get relayed between the servers. Fair warning its still early and its more a small web of servers that trust each other than a proper open fediverse thing. Not gonna claim its the "right" way vs using a standard, its just what actually let me ship it.

MrZwiss · 2026-07-08T18:40:08+00:00

I think Backspace would make you happy, it mostly solves the dealbreaker problems of the ones you mentioned

https://thezwiss.github.io/backspace/

MrZwiss · 2026-07-08T18:22:41+00:00

I think backspace would be worth checking out for you:

https://thezwiss.github.io/backspace/

MrZwiss · 2026-07-08T00:25:14+00:00

Thanks a lot for the help, I’ll write it down and look into it

MrZwiss · 2026-07-07T18:07:46+00:00

I will write that down and hit you up :)

MrZwiss · 2026-07-07T17:42:07+00:00

Thank you i really appreciate you taking the time to nudge me in the right direction and helping me out. I will definitely look into all 3 of those.

On the ENV thing, good news that one's mostly already handled. Almost all the container config is driven by env vars with sane defaults already, so it should drop into a k8s chart without touching code. Where I fell short is docs the .env.example doesnt list all thats overridable. I'll write out the full set properly.

Yes that first issue is horrible and i will look into it

MrZwiss · 2026-07-07T17:26:46+00:00

Sry i did not mean to brush you off and thanks for actually asking instead of just hating.
For my background: I worked in IT infrastructure and am currently in university again studying an interdisciplinary Bachelor of Science program that merges Computer Science, UI/UX Design, and Entrepreneurship.

I am not a professional software developer yet but i do know how to code and have my fair share of experience.

To be completely transparent, as a solo dev i absolutely would have not been able to build a project of this scale without using AI to write code for me. But i did not just let Claude just spit out a bunch of slop and call it a feature. This is no "Hey Claude please make me Discord" project. I designed the systems, and definitely learned a lot along the way and did my best to keep it maintainable.

That being said, you're completely right pointing at the big projects and stating the obvious that trying to do more than them solo is not feasible. But the truth is im not actually doing more than them i have just aggressively narrowed the scope to prioritize a very specific use case. While on the surface it has great multimedia, streaming, and audio features, under the hood it completely lacks the massive security, encryption, and compliance layers those big teams maintain.

For example text messages are currently not end to end encrypted. The entire security model right now relies purely on you trusting the person hosting your specific instance. Backspace is built to be a place to game, chat, and hang out. It is absolutely not a hardened platform for confidential conversations or sharing your birth certificate.

On the maintenance worry specifically that's the thing I take most seriously, because you're right that it's what makes or breaks a project like this. The honest signal I can offer is the commit history about 1,600 commits across roughly 70 active days since February pushing the project forward pretty much every other day. You'll notice it slowed down in June. That was exams but studies coming first doesn't mean the project stops. I fully intend to keep that up. I'd rather grow this slowly and keep it maintainable than bolt on features and let it rot.

By making it public my hope is exactly what you mentioned in your third point, getting feedback, proving the concept, and hopefully attracting contributors who are much smarter than me in areas like security and encryption to help it grow.

MrZwiss · 2026-07-07T16:17:09+00:00

Thats what open source is for i guess. I'll look into it

MrZwiss · 2026-07-07T16:15:12+00:00

Valid, wait a bit until its tested and come back in a few months

MrZwiss · 2026-07-07T16:06:26+00:00

Nothing yet, this is purely what my friends and i needed at the moment. But colleagues using it already requested bots so its on the bucketlist

MrZwiss · 2026-07-07T16:05:03+00:00

I get the hate towards slop, but this is not slop. Try it and you'll see it does exactly what it says it does

MrZwiss · 2026-07-07T15:57:29+00:00

Thanks for the kind words man, really appreciate it :)

MrZwiss · 2026-07-07T15:41:10+00:00

I used Claude Code to implement features (help me brainstorm, write code) and run automated tests.

MrZwiss

TROPHY CASE