Building Fenrid, My Attempt at a Better Home for Online Communities

I'm Diyar, an 18-year-old developer from Türkiye.

I've been into computers, coding, Discord bots, websites, and small internet projects since I was around 13. At school, when something technical broke, I was usually the person people called over. I liked that. I liked figuring things out, fixing broken systems, and making software do something useful.

For the past 7 months (since Nov 2025), I've been building Fenrid, a community platform for gaming communities, creators, online groups and most importantly people who want privacy. The idea is simple to explain and hard to execute: familiar community chat, voice, events, giveaways, creator tools, gaming integrations, and private DMs that are encrypted before they reach the server.

Fenrid is still early. There is no giant team, no huge funding announcement, and no claim that it can already replace every Discord server on the internet.

The first version is heading toward a limited closed alpha with around 100 testers. That is intentional. I don't want to pretend every feature is finished or every edge case is solved before real communities touch the product.

This post is the honest version of what I'm building, why I'm building it, what already exists, what is planned, and where the tradeoffs are.

What is Fenrid?

Fenrid is a community platform for gamers, creators, online groups, and privacy-first power users.

The core product is built around real-time chat, voice channels, roles, permissions, profiles, moderation tools, media sharing, and direct messages with client-side encryption.

Around that core, Fenrid is also building the workflows communities usually handle with external tools: events, giveaways, creator profiles, discovery, analytics, boosts, and gaming integrations.

Some of these systems are already implemented or being tested internally. Some are planned for alpha. Some are longer term roadmap items. I will be clear about the difference throughout this post.

The simple label is "Discord alternative." That is useful because people understand the category quickly. But Fenrid is not trying to be a pure messenger, a Matrix clone, or a self-hosting-first protocol.

Fenrid starts as a hosted community platform with private by design DMs, gaming workflows, creator tools, and a public trust plan around open-sourcing the full codebase near public launch.

The first phase is a limited closed alpha with around 100 testers at most. The public launch target is Q3 2026.

Fenrid will have a free plan and paid plans called Surge, Flare, and Prime. Paid tiers are meant to fund infrastructure and unlock higher limits, cosmetics, better screen share quality, analytics exports, credits, boosts, and power-user workflows.

I want to keep the features people actually love as free or as affordable as possible.

But you know how this works.

A Discord-like app has real costs. Voice costs money. Storage costs money. Bandwidth costs money. Email costs money. Moderation and abuse handling cost money. If Fenrid is going to survive as a serious platform, it needs real revenue.

The goal is to charge for higher limits, convenience, cosmetics, creator workflows, and infrastructure-heavy features without turning the basic privacy promise into a luxury product.

Privacy should not cost extra. Encrypted direct messages belong in the core product.

Why Build This When Discord Is Free and Works Fine?

Discord works.

That is the first thing to admit.

It is fast, familiar, social, and already has the network. Friends are there. Communities are there. Bots are there. Server history is there. Staff teams already know the moderation tools. Creators already have invite links in their bios.

Trying to beat that with "we are an alternative" is weak.

I am not trying to compete with Discord's network effects with this.

If you are already on Discord and you trust it, you probably do not need Fenrid today.

Fenrid is for people who want a different set of guarantees from the beginning.

Some users want private conversations where the platform does not need readable message content in normal operation.

Some creators want events, giveaways, profiles, applications, analytics, and community campaigns without stitching together ten different services.

Some gaming communities want advanced voice features, session planning, tournament workflows, and game integrations to feel native.

Some people look at large proprietary platforms and wonder what happens when growth, policy, identity verification, monetization, moderation, and user trust all start pulling in different directions.

That tension became harder to ignore after reports that government ID photos tied to age-related appeals were exposed in a third-party breach.

Discord says hackers stole government IDs of 70,000 users

As more sites require IDs for user age verification, expect more such breaches to come.

Ars Technica

Fenrid is not built on Discord becoming unusable.

Fenrid is built around a more specific belief: online communities deserve familiar UX, but with stronger privacy defaults and better community operations built in.

The goal is not to convince everyone at once. The goal is to build something serious enough that the right communities can care first.

That is also why Fenrid is starting with a limited alpha instead of pretending everything can launch perfectly at once.

I've been interested in community tools, coding, Discord bots, and online platforms for years. But Fenrid itself has been actively built for about 7 months, since November 2025.

That matters.

Seven months of serious building does not magically produce a finished Discord-scale platform.

I know that.

If you're a developer, you probably know it too.

The plan is not to ship every idea at the same time and pretend it is all perfect. I could not do that even if I wanted to.

The plan is to get the core features into alpha, test them with around 100 people, learn where the product breaks, and then add the rest through feedback, time, and painful iteration.

A perfect launch is almost impossible.

A focused alpha is possible.

Who I Am

I am not writing this from the position of a big company with a polished launch machine behind it.

Fenrid is being built by one person right now: me.

That affects everything: speed, scope, tradeoffs, launch timing, the stack, mobile, open source, and how careful I have to be with promises.

It also forces honesty. If something is not ready, I should say it is not ready. If something is planned, I should call it planned. If something is a tradeoff, I should explain the tradeoff instead of hiding it behind a nice landing page sentence.

My Story, More or Less

2021-2022: Learning by Breaking Things

My early projects were experiments.

I started with Discord bots. Then small websites, random tools... Things I wanted to understand because I was curious.

I learned by making something, breaking it, fixing it, then realizing the fix created a different problem somewhere else. Pretty normal developer stuff, honestly.

This was also when I started noticing how messy online communities are behind the scenes.

A serious Discord server might need a moderation bot, a giveaway bot, a ticket bot, a form tool, a spreadsheet, announcement channels, external websites, payment links, and a few staff members who silently hold everything together.

At the time, I did not have a clear product idea.

I just kept noticing the same thing: communities use chat platforms for much more than chat.

2023-2024: From Small Projects to Serious Problems

Over time, the problems became more interesting than the projects.

Realtime systems. Permissions. Moderation. Abuse prevention. Privacy. Voice. Creator workflows. Why some platforms feel alive and others feel empty. Why some servers grow and others die after one week.

I started thinking less about individual features and more about the full system.

A community platform is not just a message list.

It is onboarding, trust, identity, voice quality, safety, moderation, discovery, events, private conversation, payment incentives, creator tools, and the thousand small details users only notice when they break.

That is where most alternatives struggle.

Another thing shaped how I looked at this problem locally: Discord was blocked in Türkiye in October 2024.

That did not magically create a replacement market overnight. If anything, it showed how hard this category is. A platform used by gamers, creators, students, friend groups, and communities can become unavailable, and still a strong local alternative does not appear instantly.

That says something.

For Türkiye, this creates a real local opening. But it is also a warning. People do not switch to a weak alternative just because the platform they use has problems. They switch when the alternative is good enough to trust with their actual communities.

That is the bar Fenrid has to reach.

2025: The Problem Becomes a Product

Fenrid started as a broader idea for an all-in-one community platform.

The direction changed over time. At first, I was thinking mostly about community infrastructure: chat, creators, events, giveaways, and growth tools. As I kept building, the privacy side became more important, the product became clearer, and Fenrid turned into something more focused.

The idea was never just "copy Discord with a different logo."

The idea was to build a platform where gaming communities and creators can chat, host events, run giveaways, manage profiles, grow through discovery, use voice, and keep private conversations encrypted by design.

That is when the stack started forming too.

Next.js and TypeScript for a fast web product. Supabase for auth, PostgreSQL database, and realtime during early development. Vercel and Cloudflare for deployment and infrastructure. LiveKit for voice. Stripe for payments. Cloudflare R2 for storage.

Practical choices.

Not final answers for every possible scale.

2026: Closed Alpha and the Hard Part

This is where Fenrid is now.

Fenrid LLC is registered in New Mexico. The product is still under development. The waitlist is open. The first alpha is planned to be limited, with around 100 testers at most.

That limit is intentional.

The alpha needs to answer boring but important questions.

Can users sign up without getting confused?

Can they understand the passphrase flow?

Can DMs encrypt and decrypt reliably?

Can voice feel good enough for gaming communities?

Can people create servers, channels, and roles without friction?

Can events and giveaways make sense as native features?

Can moderation tools survive real behavior instead of demo behavior?

The public launch target is Q3 2026.

Around that public launch, the plan is to open-source the full codebase, publish clearer security docs, and make the privacy-critical parts inspectable.

Closed alpha is for iteration.

Public launch is for public trust.

Fenrid's Backend

Fenrid's backend uses a pragmatic stack.

The current stack is:

• Next.js
• TypeScript
• Supabase for PostgreSQL Database, Auth, and Realtime
• Vercel for deployment
• Cloudflare for CDN, security, and R2 object storage
• LiveKit for voice, video, and screen sharing
• Stripe for payments

This is not an attempt to look clever.

It is an attempt to ship.

For a solo founder building an early community platform, managed infrastructure makes sense. Supabase reduces the amount of custom backend work needed for auth, database access, realtime flows, and iteration. LiveKit gives Fenrid a serious WebRTC foundation without making me build an SFU from scratch. Vercel and Cloudflare keep deployment and distribution simple enough to move fast.

I am not pretending this exact setup is the correct answer at 50,000 concurrent users.

It is the right answer for zero to early alpha.

The scaling plan is staged.

Early on, managed Supabase and managed LiveKit are acceptable. Once real concurrency appears, the plan is to isolate bottlenecks and self-host the pieces that need more control. Supabase Realtime can move to a self-hosted setup when needed. Voice infrastructure can move toward self-hosted LiveKit regions later. The API can eventually split from the Next.js app into a dedicated service layer, and realtime can move toward a gateway architecture if the product reaches that level.

The point is to avoid two mistakes.

Overengineering too early kills speed.

Ignoring scale forever kills the product.

Fenrid needs to do neither.

Fenrid's Frontend

The frontend is where users feel everything.

A chat UI looks simple until you build one.

Then you meet scroll bugs, unread state, optimistic updates, message edits, deletion behavior, mentions, attachments, reactions, replies, jump-to-message, code blocks, paste handling, media previews, keyboard weirdness, mobile layout problems, and realtime state that arrives out of order at the worst possible time.

Fenrid is web first right now.

The web client is built with Next.js and React because that gives the fastest path to a usable product with one codebase.

The message composer matters more than people think. Fenrid supports a rich text direction with markdown mode, mentions, code blocks, formatting, links, spoilers, quotes, tables, and media embedding.

A bad composer makes the whole product feel cheap.

A good composer disappears.

The same applies to encryption UX. If passphrase setup is confusing, users blame encryption. If recovery limits are unclear, users feel betrayed. If decryption errors look scary, trust drops instantly.

Frontend is where product trust becomes real.

The tradeoff is obvious: Fenrid does not have a native mobile app yet.

That is a real weakness.

Web first is both a constraint and a choice. It lets Fenrid move faster during alpha, but a serious community platform needs proper mobile and desktop experiences over time. Native mobile is on the roadmap. Desktop through Tauri or Electron is possible later.

For now, the priority is to make the core web product work before multiplying clients.

AI and How I Use It

Yes, I use LLMs while building Fenrid.

At this point, I think that is normal for developers. Technology moves fast, and if you refuse to use better tools out of pride, you will probably move slower than people who do.

But there is a huge difference between using AI as a tool and handing the whole project to AI.

I use LLMs for brainstorming, debugging faster, exploring tradeoffs, speeding up repetitive work, improving UI details, and getting unstuck when I need another angle on a problem.

That helped a lot. Without AI, building this much in 7 months would have taken much longer.

But speed is not the same as judgment.

AI can help in some cases, but the way you use it matters. Developers who rely on AI to replace their own understanding can lose mastery, especially around debugging. Developers who use it to ask questions, request explanations, and check their own understanding do better.

That matches how I try to use it: not as a replacement for engineering judgment, but as a tool for moving faster while still understanding what gets shipped.

How AI assistance impacts the formation of coding skills

Anthropic is an AI safety and research company that's working to build reliable, interpretable, and steerable AI systems.

anthropic.com

But some parts of a product should not be treated casually.

Backend systems, authentication, payments, abuse prevention, moderation, and especially E2EE are very easy to get catastrophically wrong. AI can help review, explain, or explore options, but it cannot replace careful engineering judgment there.

If I cannot explain what a piece of code does, I will not ship it.

If a change touches encryption or user trust, it needs extra care.

That is the line.

Encrypted Direct Messages

Direct messages are one of Fenrid's core privacy features.

The current DM system is designed so message content is encrypted on the client before upload. In the normal message flow, the server stores ciphertext and delivery metadata rather than readable DM plaintext.

The simplified version looks like this:

A user chooses a passphrase. Fenrid derives key material locally from that passphrase. The private key stays on the user's device. The public key can be stored server-side so other users can encrypt messages to them.

When a DM is sent, the client generates a fresh random message encryption key, encrypts the message with AES-256-GCM, then wraps that message key for the participants using X25519-based key agreement.

The current system uses:

• PBKDF2-SHA256 for passphrase-based key derivation (Argon2id is planned for a future upgrade)
• HKDF-SHA256 for expanding key material
• X25519 for key agreement
• AES-256-GCM for message encryption and key wrapping
• Fresh random message encryption keys for DM messages

This is different from ordinary database encryption.

The server should not need the plaintext message to deliver the DM.

Passphrase recovery is the painful part.

Fenrid currently uses deterministic re-derivation. If you use the same account and passphrase on another device, the same DM keypair can be derived again and checked against the stored public key.

That gives a practical recovery path without the server storing your private key.

The cost is simple: the passphrase matters a lot.

If you lose it, Fenrid cannot recover old encrypted messages for you.

That will annoy some users. It should also be said clearly before they need it.

What Encryption Does Not Protect

Encryption protects specific things from specific threats.

It does not make a platform anonymous, metadata free, abuse proof, or magically safe.

Fenrid's encrypted DMs are designed to protect message content from normal server-side access.

They do not hide all metadata.

Fenrid may still process information needed to operate the service, including account identity, server membership, DM existence, timestamps, delivery state, rate limits, reports, session information, IP-derived safety signals, and payment records.

Encryption also does not protect a compromised device. If malware, a malicious browser extension, or someone with access to your unlocked device can read messages after decryption, E2EE cannot fix that.

It does not stop the person you are talking to from screenshotting, copying, recording, or reporting messages.

It does not fix a weak passphrase.

It does not remove moderation needs.

Fenrid's current DM message design uses fresh per-message encryption keys, but it is not a full Signal-style double ratchet today. That means Fenrid should not claim the same forward secrecy and post-compromise recovery properties as a mature dedicated messenger protocol.

DM attachments also have a simpler encryption design than text messages today. Attachments are encrypted client side, but the current approach is more conversation scoped than the message path. That gives a practical encrypted file flow, with less granularity than a mature per-file ratcheted design.

That may change as the encryption system matures.

Server text channels are also outside the E2EE scope. Community channels need server-side permissions, moderation, search, discovery, integrations, and safety workflows.

The current E2EE scope is private messaging, DM attachments, and voice/media encryption direction.

If a privacy product refuses to explain its boundaries, you should not trust it.

Fenrid should be judged by the boundaries it is willing to explain.

Voice, Video, and Local Noise Suppression

Voice is not a side feature for gaming communities.

It is often the reason people open the app.

Fenrid uses LiveKit as the foundation for voice, video, and screen sharing. The goal is reliable voice infrastructure with client side media encryption, so media servers route encrypted packets instead of needing plaintext audio in normal operation.

Fenrid also includes local noise suppression using DeepFilterNet3.

This matters to me because noise suppression should not require sending raw voice somewhere else first.

The flow I want is simple: process the microphone locally, reduce noise on the device, encrypt the media, then send it through the voice infrastructure.

That makes DeepFilterNet3 more than an audio quality feature for Fenrid. It is part of the privacy direction for voice.

The point is to avoid turning voice cleanup into another server-side processing step.

For gaming communities, this matters.

A voice channel might be a six hour ranked session, a tournament lobby, a staff meeting, a Minecraft civilization event, or a late night call where nobody wants to think about the technology at all.

If voice is bad, the product is bad.

The tradeoff is that LiveKit is currently managed infrastructure. Long term, Fenrid can move toward self hosted LiveKit regions for more control and cost management.

For now, managed LiveKit lets Fenrid ship a real voice experience faster.

Events, Giveaways, and Why Chat Is Not Enough

Fenrid is being built as more than a chat product.

Chat is the center, but community work happens around it.

Gaming communities run tournaments, LFG sessions, Minecraft "2 week phases", Roblox activities, CS2 tournaments, community nights, and private server sessions.

Those events need descriptions, dates, participant limits, application forms, approvals, reminders, announcements, and sometimes public discovery.

In Fenrid, events belong to parent servers. Permissions decide who can create and manage them. Discovery is optional. A private community can run private events without touching the public discovery feed.

That matters.

Discovery should help communities grow. It should not become a requirement for normal community life.

Giveaways follow the same logic.

A giveaway can be a creator campaign, community reward, launch moment, stream event, or growth loop.

Fenrid's giveaway direction includes parent server binding, permission checks, public or private visibility, requirements, winner selection, and integrity rules.

The key word is integrity.

If users join a giveaway, the host should not be able to quietly change the prize after people commit. If terms change before a lock threshold, users should know. If a giveaway with active participants is deleted, that should leave an audit trail. If a winner is not selected manually, the system should be able to resolve it automatically after a reasonable period.

This is where Fenrid starts becoming community operations software.

Creator Tools and Community Discovery

Creators are not just users with bigger avatars.

They have operational problems.

They need to centralize their audience, run events, announce campaigns, reward members, verify identity, manage collaborations, understand engagement, and avoid depending entirely on whichever algorithm decides whether they exist that week.

Fenrid's creator direction includes profiles, verification, social links, active campaigns, events, giveaways, analytics, and follower or community management.

Some of this belongs in the early product. Some of it will come later if the core community platform works.

That difference matters.

I do not want this post to read like every planned idea is already finished. Fenrid is still heading toward closed alpha. The first job is to make the core community product work: chat, DMs, voice, roles, and onboarding.

Discovery comes with its own problems.

Every public discovery surface attracts spam, scams, low effort promotion, manipulation, fake giveaways, and content nobody wants to moderate.

Fenrid's discovery is planned to be opt-in, rule based, and ranking aware.

Credits and boosts are planned to help promote events or communities, but paid visibility should not crush quality. Engagement, freshness, server trust, verification, and abuse signals matter too.

A boring paid listing should not permanently outrank something people actually care about.

That is the principle.

The exact ranking system will change with real usage because discovery cannot be fully designed in a vacuum.

Shared Channels and Game Integrations

Shared Channels are a planned way for communities to collaborate without merging into one giant server.

The idea is controlled bridging.

Two or more servers can link a specific channel. Messages in that shared space appear across the connected communities, while each server keeps its own identity, roles, rules, and moderation.

This is not full federation.

It is a product level collaboration tool.

That makes it more limited, but easier to understand and safer to ship.

Gaming integrations follow the same idea.

Fenrid should feel built for gaming communities, not like a generic workplace app with a darker theme.

One planned example is Minecraft live status and launcher integration. A server can show player count, latency, and status inside Fenrid, with join flows that reduce friction between community chat and the game itself.

Small integrations like that matter.

They create moments where users feel the product understands their world.

Safety and Moderation

Privacy and safety are often framed like enemies.

I do not think that framing is useful.

A platform that ignores abuse will fail. A platform that uses abuse as an excuse to collect everything will betray its users.

Fenrid has to handle both sides honestly.

To be honest, public server channels are not end-to-end encrypted. They can support standard moderation and safety systems: reports, kick, ban, timeout, mute, role permissions, rate limits, audit logs, upload rules, and media scanning where appropriate.

For known illegal content, including CSAM, public media handling can use hash matching systems and formal reporting processes where legally required and operationally supported.

Encrypted DMs are different.

If Fenrid cannot read encrypted DM content in normal delivery, it also cannot silently scan that content on the server in normal delivery.

That is the tradeoff.

If a user reports an encrypted DM, the reporting flow can include decrypted material provided by the reporting user from the client. The server does not need a secret backdoor to every DM for that to work.

That distinction matters.

Public server safety, user reporting, metadata based abuse signals, account level rate limits, and community moderation tools all still matter.

Encryption protects message content from the server in normal operation. It does not protect users from reports, moderation, or consequences when they abuse the platform.

Closed Alpha

Fenrid's first alpha is limited by design.

Around 100 testers at most.

That is small, but small is the point.

With 100 testers, I can watch what breaks, fix the product quickly, and change flows without affecting thousands of users. With 10,000 users, every broken decision becomes expensive.

The alpha is testing the core loops:

• account creation
• waitlist and onboarding
• server creation
• channels and roles
• encrypted DM setup
• message sending and decryption
• voice quality
• local noise suppression
• moderation actions
• profiles
• and other core features

The alpha is not a growth stunt.

It is a control mechanism.

A community platform should not scale confusion. It should earn scale after the core experience works.

Closed During Alpha, Open at Launch

This is the tension I expect privacy focused users to notice first.

Fenrid is privacy-first, but the alpha is closed source.

That deserves a direct answer.

During closed alpha, the product is changing quickly. Authentication, encrypted messaging, realtime flows, moderation, abuse prevention, onboarding, pricing, and product architecture are still moving.

Opening everything during this stage would not automatically create useful trust. It could create noise around unstable code, increase maintenance burden, and expose operational abuse prevention details before the platform is ready.

But closed-source alpha is not the long term trust model.

Around the Q3 public launch, the plan is to open-source the full Fenrid codebase.

That means the web client, backend routes, realtime logic, E2EE worker, client-side crypto utilities, security documentation, threat model, and responsible disclosure policy should become publicly inspectable.

This matters because Fenrid is making privacy claims.

If a product says private DMs are encrypted before they reach the server, people should be able to inspect the code path responsible for that claim. If a product says it is building a serious community platform, developers should be able to look at the architecture and judge it honestly.

That does not mean self-hosting will be fully supported on day one.

Open source and self-hosting are related, but they are not the same thing.

Making the code public is one job. Supporting third-party deployments, writing operator docs, making setup scripts reliable, handling migrations, documenting abuse-prevention assumptions, and helping people run their own instances is a much bigger job.

Fenrid's first open-source milestone is transparency.

Self-hosting may come later, but I do not want to promise full production-ready self-hosting before I know I can support it properly.

People should hold Fenrid accountable for the Q3 open-source plan.

If Fenrid reaches public launch and there is still no real code transparency, criticism would be fair.

Hosted First. Not Matrix. Not Self-Hosting First.

Self-hosting is valuable.

I understand why people care about it. Running software yourself can reduce dependence on a single provider, give communities more control, and make long term access less fragile.

Fenrid does not start there.

The first version is hosted-first because Fenrid depends on systems that are harder to coordinate in a fragmented setup: discovery, creator verification, payments, giveaway integrity, abuse prevention, CSAM handling for public content, event ranking, moderation consistency, and a simple onboarding experience.

Matrix and federation solve a different set of problems.

They also create hard UX and moderation problems. Identity, spam, compatibility, discovery, and trust become much harder when many servers with different policies interact.

Fenrid may explore federation-like ideas later, especially around Shared Channels and cross community collaboration.

But the first product is not a protocol-first network.

Fenrid's initial promise is simple: a hosted privacy-first community platform where private conversations are designed to be encrypted by default.

That is already hard enough.

Pricing and Sustainability

Fenrid needs to make money.

Voice infrastructure costs money. Storage costs money. Bandwidth costs money. Email costs money. Moderation and abuse handling cost money. Development time costs money too, even when the founder is solo.

The planned paid tiers are:

• Free
• Surge, $4.99/month
• Flare, $9.99/month
• Prime, $24.99/month

Server boosts are planned separately.

Paid plans can increase limits and unlock power-user features: larger attachments, better screen share quality, more credits, profile customization, analytics exports, event tools, server boosts, cosmetics, and priority features.

The important line is this:

Privacy should not cost extra.

Encrypted direct messages should not be locked behind Prime.

Fenrid should make money by charging for higher limits, convenience, customization, infrastructure-heavy features, and creator workflows, not by selling basic privacy back to users.

No ads.

No selling user data.

A sustainable platform needs revenue, but the revenue model should not fight the privacy promise.

Frequently Asked Questions

Is Fenrid just another Discord clone?

Fenrid uses familiar patterns because familiar patterns reduce friction.

Servers, channels, roles, DMs, and voice rooms are useful concepts. People already understand them. Changing those patterns just to look different would make the product harder to use for no good reason.

The goal is not to make users relearn community software from zero.

The difference is the product direction: encrypted private messaging, local voice processing, creator tools, events, giveaways, discovery, gaming integrations, analytics, and a public trust plan around opening the full codebase near public launch.

A familiar interface can still serve a different product philosophy.

Fenrid should feel easy to understand on day one, then prove that it makes different choices where those choices actually matter.

Is Fenrid open source?

Not during closed alpha.

The plan is to open-source the full Fenrid codebase around the Q3 public launch. That includes the web client, backend code, E2EE worker, client-side crypto utilities, security docs, threat model, and responsible disclosure policy.

That does not mean production-ready self-hosting will be supported immediately. The first goal is code transparency. Self-hosting requires more work: deployment docs, migrations, setup scripts, operational assumptions, abuse-prevention guidance, and long-term maintenance.

Can I self-host Fenrid?

Not at first.

Fenrid starts hosted-first. Self-hosting may be explored later, but I do not want to promise it before the product is ready for that operational burden.

Self-hosting sounds simple until you have to support updates, abuse prevention, discovery, creator verification, payments, moderation policy, storage, voice infrastructure, and operator documentation.

How is Fenrid different from open-source and self-hosted alternatives?

Some alternatives start from control: open source, self-hosting, federation, and operator freedom.

That is valuable.

Fenrid starts from a different place: a hosted community product with encrypted private communication, gaming workflows, creator tools, events, giveaways, and a carefully limited alpha before public launch.

The plan is still to open-source the full codebase around public launch. But Fenrid is not starting as an operator-first project.

It is starting as a product-first community platform.

That means the first question is not "can someone run this entire stack themselves tomorrow?"

The first question is "can real communities use this without the product falling apart?"

Is Fenrid end-to-end encrypted?

The current E2EE scope is private messaging, DM attachments, and voice/media encryption direction.

DM text messages are designed around client-side encryption before upload. The server stores ciphertext and delivery metadata rather than readable plaintext in the normal DM flow.

Server text channels are not E2EE.

Metadata still exists.

Fenrid should not be described as "everything is encrypted." That would be misleading.

Does Fenrid have forward secrecy?

Fenrid's current DM messages use fresh per-message encryption keys, but the system is not a full Signal-style double ratchet today.

That means Fenrid should not claim the same forward secrecy and post compromise recovery properties as Signal.

This is one of the current tradeoffs. The early goal is encrypted DMs with practical passphrase based recovery, then a stronger design as the product matures.

What happens if I lose my passphrase?

Fenrid cannot recover old encrypted DMs for you if the passphrase is lost.

That is the cost of not storing the private key server-side.

The UX needs to make this very clear. Privacy that surprises users at the worst possible moment is bad privacy.

I want the setup and warning flow to be as clear as possible: choose a passphrase you will not lose, understand what it protects, and understand what Fenrid cannot recover for you later.

This is one of the hardest UX problems in encrypted products. Strong privacy is only useful if normal people can understand the consequences.

How does Fenrid handle moderation with encrypted DMs?

Public server channels and encrypted DMs are handled differently.

Public server content can support normal moderation, reporting, rate limits, audit logs, and platform safety systems.

Encrypted DMs are not scanned by the server in normal delivery because the server does not have the plaintext. If a user reports an encrypted DM, the reporting flow can include decrypted material provided by that user from the client.

When is launch?

The first step is closed alpha with around 100 testers.

The target for public launch is Q3 2026.

That is a target, not a promise that every planned feature will be perfect by then. The alpha will decide what is ready, what needs more work, and what should be delayed.

Why not wait until everything is ready?

Because everything will never be ready at the same time.

A community platform has too many moving parts: chat, DMs, voice, moderation, onboarding, events, creator tools, discovery, mobile, safety, infrastructure, and trust.

If I wait until every idea is perfect, Fenrid will never reach real users.

The better path is to launch a focused alpha, test the core with around 100 people, fix what breaks, and expand from there.

That is slower than hype.

It is also more honest.

Will there be a mobile app?

Yes, but not first.

Fenrid starts web first because that is the fastest way to build, test, and iterate with limited resources. A native mobile app is part of the longer term direction. React Native or Flutter are both possible paths.

A serious community platform needs mobile. I am not ignoring that. I am sequencing it.

What about bots and integrations?

Bots and integrations matter a lot.

Many communities rely on bots for moderation, roles, tickets, logging, giveaways, music, analytics, and automation.

Fenrid's first step is to build native tools for the most common workflows. Webhooks and APIs can follow. A full bot ecosystem should come after permissions, abuse controls, and platform stability are ready.

A rushed bot API can become an abuse machine.

Does Fenrid support federation?

No, not today.

Fenrid is product-first, hosted-first, and focused on a consistent user experience. Federation may be explored later, but Fenrid is not starting as a federated protocol.

What Comes Next

The next step is the closed alpha.

That means real users, real bugs, real confusion, real feedback, and probably a lot of things I thought were obvious turning out to be unclear.

That is the point.

The alpha will focus on the core product:

• servers
• channels
• roles
• DMs
• passphrase setup
• encryption reliability
• voice
• noise suppression
• profiles
• onboarding
• performance

After that, Fenrid moves toward public launch.

The public launch target is Q3 2026. Before then, I want clearer security documentation, a threat model, a responsible disclosure policy, and a public release of the full codebase.

The rest will come through feedback and time.

Native mobile, deeper creator tools, stronger discovery, more integrations, larger scale infrastructure, and possible self-hosting research are all important. But trying to ship every one of those perfectly on day one would be stupid.

The alpha should prove the core.

Then the product can earn the right to expand.

Closing Thoughts

If it is not obvious by now, I deeply care about this.

Fenrid is early.

It is unfinished.

It has real tradeoffs.

It does not have native mobile yet. It is not self-hostable yet. It is closed-source during alpha, with the full codebase planned to open around public launch. Its current encryption design is practical, not a perfect final messenger protocol.

I am saying all of that now because I would rather be honest early than sound impressive and get exposed later.

Still, I think this is worth building.

Online communities are not just message feeds. They are friend groups, creator audiences, staff teams, game servers, events, giveaways, inside jokes, late night calls, support systems, and sometimes entire social lives.

They deserve tools that understand that.

Fenrid is my attempt to build one.

Not perfectly.

Not all at once.

But seriously.

And I do not want to build it alone in a vacuum.

If this sounds interesting, your help will always be appreciated. You can join the waitlist, or join our Discord server. Yeah, I know... just until Fenrid is ready to be our home :)

With your help, Fenrid can grow stronger. More importantly, it can grow together with the people it is meant to serve.

If you want to reach me directly, you can join the server like I said, or send me an email.

Thank you for reading all the way through.

See you in Fenrid!