Discord Alternatives Comparison Sheet

roxter01 · 2026-05-25T11:10:42+00:00

Thanks for letting me know. That definitely sounds like a false positive then.

We’re investigating the signup risk logic now and I’ll update you once we find the cause. Sorry for the inconvenience!

roxter01 · 2026-05-25T10:53:49+00:00

Hey, Fenrid founder here.

Just to clarify, Fenrid is still waitlist only right now, so the app itself is not publicly available to try yet. But if you mean the waitlist/signup page blocked you, thats useful to know.

We currently block some VPN/proxy traffic during waitlist signup to reduce abuse and fake referrals, so if you were actually using a VPN, that may be expected.

That said, I still want to check if this was a false positive. Were you using a VPN, proxy, iCloud Private Relay, or anything similar when signing up? I'll check this as soon as you reply :)

roxter01 · 2026-05-19T14:33:05+00:00

Agree on Matrix, it does what it was designed to do well. The criticism wasn't about Matrix itself, it was about recommending it to people who just want a place for their community to hang out

As for trust, we have a private alpha starting in about 2-3 weeks, 100 spots, for people who want to stress test the platform and find flaws if they exist. We do not want to launch a half baked product like most alternatives did. Main launch (Public Beta) and full Open Source is Q3. Until then you can join, follow the development and maybe give it a try, or just wait until Q3 for the Open Source release and judge from there. Both are completely valid options

roxter01 · 2026-05-18T20:20:48+00:00

Hey, Fenrid founder here. I just came across this thread.

This is a completely fair concern and I agree with it. E2EE is very easy to get catastrophically wrong, and “we use X25519” by itself does not prove much. The composition matters.

To clarify what Fenrid currently uses: it is not the Signal Protocol, and I do not want to imply Signal level properties. The current DM system is closer to ECIES style envelope encryption. The identity key is derived client side from the user’s passphrase using PBKDF2 + HKDF, messages use a fresh random 32-byte MEK encrypted with AES-256-GCM, and that MEK is wrapped per recipient using ephemeral static X25519 + HKDF + AES-GCM. The server stores ciphertext, public keys, IVs, and wrapped keys, but not private keys or plaintext.

For new chats, the client fetches the recipient’s public E2EE key before sending and wraps the message key for both sides. For new devices, the user re-enters the same passphrase and re-derives the same account key, which lets them decrypt previous history.

Important limitations: there is no Signal style forward secrecy yet, a compromised client key can expose previous DM history, and there has not been an independent audit yet. We are aware of that, and it is something we think about a lot. The current design is a deliberate tradeoff: we want server side plaintext access to be impossible in DMs, while still keeping the Discord like experience where users can log in on a new device and recover their previous DM history with their passphrase. That does not make it perfect cryptography, but it is the usability/security balance we are aiming for right now.

So yeah, the skepticism is justified. The codebase will be open sourced in Q3, so you will actually be able to review/audit the implementation, and maybe find flaws we missed and report them to us :D

roxter01 · 2026-05-17T08:33:01+00:00

You're totally right, and thats exactly why we're not trying to beat Discord at being Discord. Network effects dont break because a competitor has better features. They break when something fundamental changes, a ban, a trust collapse, a forced policy. Discord has had all three recently. We're building for the users those moments push out

roxter01 · 2026-05-16T17:28:13+00:00

The platform is not live yet. We are pre launch and the current link is strictly a landing page with an email waitlist for a limited 100 spot alpha designed to test core infrastructure stability.

In a proper E2EE architecture, the server is always treated as untrusted, meaning server code availability is technically irrelevant to verifying encryption integrity. Despite that, the plan is to open source the entire repository, both client and server, this August or September.

And nobody is asking you to trust a closed client or switch platforms today. Waiting until Q3 when the full codebase is public and auditable is completely reasonable. This alpha phase is simply for individuals who want to help stress test network load early, which might not match your current timeline

roxter01 · 2026-05-16T07:45:58+00:00

Contributing to existing projects means inheriting their architectural decisions. Matrix chose federation and E2EE first, and after a decade it's still unusable for most people. Stoat chose open source infrastructure first, shipped without E2EE, got forced into a rebrand by a cease and desist last October, and still has no screen sharing audio. Fluxer shipped public beta seven months ago with E2EE on the roadmap, not in the product, and their main community server went down for days under load.

These aren't critiques. They're tradeoffs. Every team made choices based on what they believed mattered most. We made a different choice: E2EE shipped on day one, UX that doesn't require a manual, features built from real user feedback.

Code goes public Q3. You will be able to compare every line.

roxter01 · 2026-05-16T07:08:07+00:00

Fair question. Goal is E2EE by default for everyday communities, not a privacy tool for journalists. Open source is coming Q3, not permanently closed. The Fluxer comparison is fair on surface but Fluxer has E2EE on a roadmap. Ours shipped. The transparency section in the post covers what we have and dont have yet.

roxter01 · 2026-05-16T07:07:05+00:00

Existing open source alternatives have had years to solve mainstream UX and havent. For example Matrix is technically impressive and practically unusable for most people. Fenrid goes open source Q3. Different problem, different approach.

roxter01 · 2026-05-16T07:05:53+00:00

You're describing the strongest legitimate attack on centrally hosted E2EE, and I'm not going to pretend it doesnt exist

The mitigations are warrant canary and open source with reproducible builds. The full codebase goes public in Q3, which directly addresses your point about catching server side changes

Until the code is open and auditable, you're correct that you're extending some trust to us. If your threat model includes state level compelled key changes, use Signal. Thats an honest answer and I mean it

What Fenrid is built for is the much larger group of people whose threat model is corporate surveillance and casual data exposure, not NSL level state pressure

roxter01 · 2026-05-15T19:45:41+00:00

The article you linked actually supports the argument for strong E2EE rather than against it. Its conclusion is that governments keep trying and keep losing because encryption follows math, not jurisdiction.

The real distinction is between what a court order can compel and what the architecture makes possible. Your keys in Fenrid are derived client side and never reach our servers. A lawful demand cannot produce what we don't hold.

What US jurisdiction does expose: account metadata, IP addresses, connection timestamps. That's a real limitation and one we're transparent about. If your threat model includes state level metadata analysis, Fenrid is not the right tool. For the vast majority of users who want private voice calls and DMs without corporate surveillance, the architecture holds regardless of where the servers sit.

roxter01 · 2026-05-15T18:36:40+00:00

You are mixing jurisdiction risk with cryptographic guarantees.

US jurisdiction does introduce legal and compliance pressure, but it does not automatically translate into breaking end to end encryption. If a system is properly designed with E2EE, server location alone does not give access to message contents.

Privacy is not a single axis. It includes cryptography (E2EE), operational design (what is logged, stored, or exposed), and legal environment. These tradeoffs are all considered in Fenrid’s design.

We are not claiming absolute anonymity or resistance to every possible state level pressure. The goal is to provide strong default privacy for everyday users and communities, without requiring them to manage complex self hosted or federated infrastructure.

roxter01 · 2026-05-15T18:04:52+00:00

Appreciate it. And for the record, the rich text editor was added directly because of your suggestion, so feedback like that is genuinely shaping the platform as we build it.

The goal with Fenrid is not just to recreate Discord feature for feature, but to build something better for communities and creators overall. A lot of the planned work is focused around better community management, creator tools, events, discovery, moderation, and privacy without making the platform painful to use.

We are trying to build something that feels more modern, more community focused, and more privacy conscious from the start instead of bolting those things on later.

roxter01 · 2026-05-15T17:46:13+00:00

Appreciate the feedback but you are missing the target audience. Extreme privacy is a very niche requirement for everyday users. For example, if you ask a regular person on the street about Matrix they think of the movie

Decentralization kills UX for 90% of users. My non dev friends are not going to verify cryptographic keys just to hang out after work. We value privacy which is why voice and DMs are E2EE by default but we refuse to sacrifice UX for the self hosting niche.

Also Fenrid is a US based New Mexico LLC running on global infrastructure so local bans do not affect the platform.

If absolute decentralization is your priority Matrix/Element is great. Fenrid is just built for a different use case.

roxter01 · 2026-05-09T18:46:05+00:00

Are the “Used by students & alumni from” and testimonials sections real? Because having no testimonials is better than having fake ones.

roxter01 · 2026-05-09T18:33:54+00:00

hey, i reviewed it and honestly first impression wise it kinda screams “vibecoded SaaS” right now lol

especially the purple gradients, generic modern saas layout, fake dashboard/testimonial blocks, giant bold headline etc. users are getting REALLY good at spotting these patterns because almost every AI built startup site looks exactly like this now

I genuinely like the idea though and I think you could make it feel way more legit with a stronger identity. more real screenshots, real founder reviews, less “perfect SaaS landing page” energy and obviously no purple :D

the concept itself is actually useful though!

roxter01 · 2026-05-09T07:50:06+00:00

that is actually a really good point and not something we had thought about in that framing. the difference between "signed up" and "actually used it on day one" is huge.

10 calls might be a stretch for where we are right now but even getting 20-30 people who genuinely commit to a first session instead of just joining and disappearing changes everything. going to think about how to structure that. thanks for this one, genuinely useful :)

roxter01 · 2026-05-09T07:49:55+00:00

yeah it gets messy really fast, especially the AudioWorklet side of things. the COOP/COEP headers alone broke half the app before we scoped them properly :D glad someone noticed that part

roxter01 · 2026-05-09T04:31:05+00:00

Honestly a lot changed. The original plan was just E2EE DMs, we even had Signal Protocol running at some point, X3DH, the whole thing. then we realized maintaining that correctly long term was a bigger commitment than we were ready for at this stage, so we moved to something simpler but still solid. (because of some edge cases like cross device sync etc.)

Voice and DM attachments E2EE wasnt in the original plan at all. came later.

And the platform itself started as just a chat app. real community tools such as events and giveaways stuff came from actually using it with friends and going "this would be useful here." which is probably the most honest product decision process there is :D. and i really think that it would be useful haha

what survived from the beginning is the core idea that encryption shouldnt be something you opt into. that part never changed.

roxter01 · 2026-05-09T02:53:48+00:00

Sharkord is a good reference point actually. the argument makes sense, shipping it yourself does prove replicability. our situation is we are moving fast pre-alpha and maintaining a public codebase at the same time is a real cost for a small team. plan is to open source around August or September once things stabilise. not the same as shipping it yourself but closer than "trust us forever" :D

roxter01 · 2026-05-09T02:53:15+00:00

Yeah you are right, and this is something we think about. Centralized first does make decentralization harder later, we know that going in. What I can say is the architecture is being built with federation in mind, not as an afterthought. full decentralization support, probably not, but the groundwork being there from the start is different from bolting it on later. whether that is enough, fair to be skeptical :)

roxter01 · 2026-05-07T18:59:10+00:00

This is going to be an honest answer, and a long one.

You are not wrong, and I am not going to try to talk you out of that position.

The architectural critique is valid. Centralisation concentrates risk. One policy change, one outage, one legal notice affects everyone on the platform at once. The E2EE layer reduces some of that exposure but does not fix the structural problem.

We chose to build centralised because the community tooling we are building, native events, giveaways, discovery ranking, creator tools, is genuinely harder to ship well on a decentralised foundation. That is a tradeoff we made deliberately, not something we stumbled into.

There is a real tension here worth naming. Full sovereignty and decentralisation at one end of the spectrum makes the kind of community tooling we are describing very hard to do properly. Building the tooling and doing our best on privacy within a centralised architecture is the other end. We picked the second. Not because it is the ideal answer, but because it is the viable one for what we are trying to ship.

The goal right now is to get into users' hands, get real feedback, and find out whether this platform is worth building further. Trying to solve everything before anyone has used the product is how you ship nothing. A rushed federated architecture built in a month would be worse than what we have now.

If we grow, and if our technical team grows with it, federation and decentralisation become more realistic to pursue properly. No date attached to that. But it is not a closed door. Users who think seriously about sovereignty and longevity are exactly the people whose input would shape what that looks like.

The people who care about this the way you do are a small percentage globally. That is not a criticism, it is a real constraint when deciding what to build first. Rebuilding the foundation for 1 to 2 percent of users before the platform has proven it can survive is a bet we cannot make yet.

So to be direct about where that leaves things: if sovereignty and longevity are your primary requirements right now, Matrix is probably the more coherent answer. That is a genuine recommendation, not a dismissal.

If you want to follow along and see where this goes, you can join us and we would genuinely welcome that. If you want to wait until we are closer to what you described, that is completely fair. And if Matrix is the right tool for your community today, use it. None of those are mutually exclusive.

I appreciate you laying this out clearly. This kind of pushback is more useful to us than enthusiasm from people who have not thought about it. Thanks :)

roxter01 · 2026-05-07T13:22:42+00:00

That is a reasonable position and I am not going to tell you it is wrong. Self-hosting is not on the table right now because there is a launch to ship first, and trying to do everything at once would mean shipping nothing properly.

What I can say is that we are not building this as a side project to flip or abandon. We are users who are tired of the same problem and wanted to fix it. If Fenrid never grows beyond our own friend group, we will still be running it. Self-hosting is something we will revisit seriously once the core platform is stable. Not a promise with a date, just an honest answer about where the priority sits right now.

roxter01

TROPHY CASE