# RFD 0001: Redwood Chat

> [!NOTE]
> This is a draft RFD document describing the planned design of Redwood Chat. To give feedback, check out the [Redwood Chat Discord](https://discord.gg/RCxcM4x8JE). You can also see code [on GitHub](https://github.com/redwood-chat).

The "chat platform" space is a crowded one, with many existing offerings, free or commercial, open or closed source, centralized, federated, or peer-to-peer. This variety exists because of historic path dependency, technical complexity, and diverging values weighing tradeoffs for which there is no singular objectively correct answer.

Despite the variety of options available, I believe there is a gap which ought to be filled. Namely, a platform which meets alll of the following requirements:

- __End-to-end encrypted__: All chats are encrypted such that only the participants in the chats can read their contents.
- __User-controlled identity__: Users maintain tight control over their identification and personas disclosed to servers.
- __High-quality moderation support__: Community administrators have rich and powerful features to defend their communities against spam, harassment, bigotry, threats, and other unacceptable conduct.
- __High performance and polish__: The overall system runs as quickly as possible, supported both by an architecture which minimizes opportunities for error, and rigorously-built servers and clients which prioritize snappiness.
- __Open source licensing, open governance, non-commercial__: The software is open source (uses a license on the OSI license list), and the project itself is "open governance" and non-commercial.

In the remainder of this RFD I will lay out the motivation, values, architecture, key technical decisions, and basic roadmap for a new chat platform which I am calling "Redwood Chat." This is only the starting point of the design of this new platform, and I invite others to participate in both shaping the design of the system, and in building it out.

## Assessing Other Chat Platforms

Before we dive into the details of Redwood Chat itself, it's worth pausing to assess the deficiencies of existing platforms. This assessment is not meant to denigrate these other platforms or the work of the people who contribute to them. Each makes differing choices for technical, business, or values-based reasons which make sense for their goals, and this assessment of those choices is inherently subjective based on the values I bring to the space.

### Discord

That said, let's begin with Discord. Discord is perhaps the most popular option in this space today. It's a commercial product which makes its money through a microtransaction-based model; creating Discord servers (Discord's name for its distinct communities) is free, as is participating in a Discord server, and Discord makes their money by selling "Nitro," a virtual currency which can be used for enhancements on user's accounts, or donated to servers to enable enhancements on those servers.

Discord has been very successful, and shines with the snappy performance of its clients and the power of its moderation systems. On the other hand, Discord has some limitations. While its audio/video chats are end-to-end encrypted (using a protocol Discord developed called "DAVE"), text chats are not. Additionally, the company's profit motive is an ongoing concern for many Discord users. Just recently, in January 2026, Discord filed for its Initial Public Offering (IPO), indicating it intends to become a publicly-traded company. For communities which have grown and ingrained themselves on Discord's platform, there are serious fears about actions the company may take post-IPO to support its stock price and please investors. Since Discord is closed source and does not offer meaningful options for migrating communities away, Discord users may face substantial challenges leaving the platform, and lack the ability to shape Discord to work how they want as they would be able to do with an open source alternative.

### Matrix

Speaking of open source alternatives, the leading platform in this space is Matrix. Matrix is a chat platform based on a decentralized protocol, very unlike Discord's centralized architecture. In Discord, all chat messages flow through Discord-controlled servers before being sent out to users' clients. In Matrix, users register with a "homeserver," and when they join a community hosted on a Discord server, messages from that community will be sent to their homeserver, which syncs the remote state to resolve a "local" view of the chat. While this architecture provides some significant benefits (every server involved in a Matrix community maintains a full copy of the history of that community), it also introduces substantial challenges. For instance, differing servers may not maintain consistent views of the state of a community in which they both participate.

Matrix's decentralized nature, along with historic technical debt, has meant that it has faced significant challenges adopting end-to-end encryption. Matrix did not begin with end-to-end encrypted chats, and eventually added them via the addition of custom Matrix-specific protocols called Olm and Megolm. These protocols face significant limitations compared to more modern options (particularly the Messaging Layer Security \[MLS\] protocol), including lack of forward secrecy, and have also been found to have significant implementation issues in practice which have lead to serious violations of the end-to-end encrypted guarantee. While these have been fixed in newer versions of the protocols, the transition to more secure versions has been slow and inconsistent across Matrix clients. Moreover, while Matrix has begun a transition to MLS, which is both more secure and faster than Olm and Megolm, this adoption is incomplete and has been slowed by the need to adapt MLS's design to Matrix's decentralized (homeserver to homeserver) architecture.

Matrix's decentralized design also leads to additional complexity in the UX of Matrix clients, and more failure modes which manifest themselves as messages failing to send, messages appearing out of order, messages being replayed, and other kinds of surprising failures. Finally, the quality of Matrix clients, even the flagship client Element, is lacking compared to alternative chat platforms.

### Other Commercial Chat Platforms

There are many further options in the space, but I will spend less time addressing their deficiencies. First, there are more commercial options for chat platforms, including Slack, Mattermost, and Rocket.Chat, which are disqualified from consideration by many communities due to their pricing. This is unsurprising and likely desirable for the companies behind these products, which explicitly market themselves as enterprise collaboration tools, and not general consumer social platforms.

### Other Open Source Chat Platforms

There's also a long-tail of open source Discord alternatives, such as Stoat, Chatto, Fluxer, Nerimity, Sharkord. These can be great, but they're also all relatively immature and __do not feature end-to-end encryption__.

There are also two options which are interesting but also pursuing more substantially different designs in this space. First, there's Zulip, which organizes chats into "topics," offering a very different user-experience from what I'll call the Discord-likes in this list. Then there's Roomy, a newer ATProto-adjacent chat platform which bridges the concepts of a chat app and a document-editing app. It's new, and seems very interesting, but again is sufficiently different to be counted as its own concept.

Finally, there's IRC, the conceptual predecessor to all the platforms listed in this section. While IRC still exists, and there remain strong proponents of it, I believe its usability difficiencies are severe enough to disquality it from consideration. IRC users do not receive messages sent when they are not actively online, unless they operate a "bouncer," a piece of infrastructure which remains live on an IRC chat and collects messages on your behalf. Any platform which requires its users to operate infrastructure to meet minimum usability requirements is not fit for general consumer use. IRC is also not end-to-end encrypted.

So in short: while all of these options exist, there is not one which fully addresses the five needs identified at the start of this RFD: 1) end-to-end encryption, 2) user-controlled identity, 3) high-quality moderation support, 4) high performance and polish, and 5) open source, open governance, and non-commercial.

## Terminology

There is one more thing to do before diving more deeply into Redwood Chat: define some terminology. Unfortunately for us, Discord has muddied the meaning of the term "server" in this space, so it's worth being very clear about what "server" and other related words mean in this document and for Redwood Chat more broadly.

### Server

A "server" in Redwood Chat is an application, deployed by an administrator, that hosts communities. It is __not__ the communities themselves, unlike what communities are called on Discord.

### Community

A "community" is a collection of users and channels, generally organized around a shared purpose.

### Channel

A "channel" is a single chat stream.

## Design Goals

The major goals of Redwood Chat, which will drive both its design and implementation are:

### Privacy

First, all chats on Redwood Chat must be end-to-end encrypted. End-to-end encryption is important for everyone; people deserve to enjoy the same level of privacy in their remote, technology-facilitated communications as they have when meeting as a group face-to-face.

We will not offer unencrypted chats on Redwood Chat, as permitting end-to-end encrypted chats alongside unencrypted chats is a recipe for potentially disastrous user error, where messages intended for an encrypted chat are sent to an unencrypted one.

Some may question the value of providing end-to-end encryption for group chats, as any participant in the chat (any of the "ends") may choose to disclose those chats to a third-party. This is a question of how much participants in a chat trust each other, and is distinct from the important question of how much they trust (or whether they should have to trust) the operator of their server. Without end-to-end encryption, users _must_ trust their server operator with their messages, which is often a much more challenging proposition than trusting chat participants. We leave it up to users how big a group is "too big," or how trustworthy their community members are.

Second, the design of Redwood Chat beyond the chats themselves should aim to protect user privacy as much as possible. Users should control their own identity information, how much they disclose to users, and what personas are made known to servers which host the communities they use. As we will discuss later on, Redwood Chat will be built with ATProto as an identity system for users. Data published to user's Personal Data Services (PDS's) in ATProto is inherently _public_, so we must be judicious in the design of Redwood Chat when determining what data, if any, will be published to a user's PDS.

### Performance

Chat platforms live or die based on how well they get out of the way of users communicating. While chat can be asynchronous in nature, users expect to be able to communicate live with each other without issue, just as they would if they were speaking in person. This must be supported both in the design of the protocols between Redwood Chat servers and clients, and in the implementation of those servers and clients as well. On the server, we will seek to minimize latency in ferrying messages between users. On clients, we will seek to minimize the time to render updates to the user or respond to user action.

### Moderation

Moderation will be a first-tier concern in the design and implementation of Redwood Chat. Communities of any meaningful scale need moderation features to protect themselves from spam, illegal content, harassment, threats of violence, brigading, and much more. While we hope communities are first and foremost places for people to get along and have fun, we know that conflict among community members is inevitable, as are malicious actions from outside operators.

This also includes support for audit logs of moderator actions, which are essential for providing transparency and accountability for moderators themselves.

### Familiarity

Redwood Chat will be built for people who like Discord, and who want and expect a Discord-like experience. It should feel familiar for users from Discord, although it is not guaranteed to be exactly identical. This includes affordances familiar to Discord users like community invite links, easy client sign-in, and other UX niceties which make common user flows as seamless as possible.

### Ease of Operation

For many pieces of software, operating infrastructure to run them can be a full-time job. It is easy for configuration complexity to take hold, or for projects to not take seriously the experience of operators configuring, deploying, updating, and debugging their software over time. Redwood Chat will value and pay close attention to the quality of this experience, ensuring minimal configuration with strong usable defaults, a smooth first-deployment experience, easy self-updates which minimize impact to hosted communities, and clear and useful documentation for debugging server issues when necessary.

### Security

End-to-end encryption is a high bar for a chat platform. Achieving it is not simply a matter of deploying a "secure protocol" such as Messaging Layer Security, but also involves taking seriously the quality of the implementation of that protocol, being proactive in responding to computing advances which challenge that security, and more generally taking seriously the need to proactively assure the security of the system through code review, testing (especially fuzz testing where possible), and security audits.

For Redwood Chat in particular, we will pay close attention to the integration of post-quantum cryptographic algorithms into MLS. MLS today uses entirely "classical" cryptography, and the nature of the software means we are absolutely susceptible to "collect now, decrypt later" attacks, where attackers gather end-to-end encrypted chat data and wait for the arrival of a cryptographically-relevant quantum computer which can crack the encryption. There is active work on MLS itself to support post-quantum key encapsulation with ML-KEM, the key-encapsulation algorithm recommended by the U.S.'s National Institute for Standards and Technology (NIST), as well as active work to integrate ML-KEM into OpenMLS, a Rust-language implementation of the MLS standard. We will watch both closely so we can integrate support for ML-KEM as soon as is practical.

### Legal Compliance Support

Unfortunately, one major challenge of operating any social communication infrastructure today is the issue of legal compliance. The internet is inherently trans-national, and there exist a variety of laws across countries which apply to these kinds of platforms. While Redwood Chat cannot and will not be responsible for guaranteeing legal compliance with all applicable laws for its operators, we can and should do our best to make compliance easier.

This includes but is not limited to issues such as: the proper handling of data being exported from Redwood Chat servers, which may be subject to disclosure requirements to users included in the export; providing default user agreements which may be replaced, along with notices of the risks of such a replacement; including mechanisms for users to self-label accounts as belonging to automated bots, as well as administrator labelling of such accounts; providing clear configuration mechanisms for setting data retention policies; and support for integrating age verification checks.

Note that none of this indicates _approval_ of the relevant laws, and is only intended to help limit the legal liability of Redwood Chat operators. The laws exist whether we want them to or not.

### Credible Exit

One of the challenges of any hosted platform, even one where the underlying software is open source and modifiable, is that the users of that platform become locked-in and unable to move, or at least would forfeit important data such as message history if they do relocate.

Redwood Chat will include first-class support for cross-server migrations, whether done cooperatively (with the support and live interaction of the server from which a community is migrating), or adversarially (without the support of that server), and will strive to retain and transfer as much community data as is possible in both contexts.

This capability is essential as a check against possible tyranny by server operators whose interests are no longer aligned with the communities they host, or for communities which want to exercise their right to relocate for other reasons.

## Architecture

It's worth now diving into the high-level architecture of Redwood Chat. Many other technical decisions are downstream of these architecture choices, and so getting them right is extraordinarily important.

### Servers Host Communities

Redwood Chat is explicitly _not_ a federated system. Servers host communities, and are the authoritative source for the state of messages in those commmunities' channels. This is purposefully unlike Matrix's federated design, and avoids issues of consistency that arise in Matrix where differing servers may produce inconsistent understandings of the "current state" of a community's chats.

Communities migrate choose to migrate from one server to another, but migration is always a temporary, short-term state, and the end result is always that the server which has been migrated to becomes the authoritative owner of the state of the community.

### Users Connect to Many Servers With Clients

Users can connect to arbitrarily-many servers, and arbitrarily-many communities within those servers, with a single client.

### Identities Are Controlled By Users with ATProto

Identity in Redwood Chat is delegated to the Authenticated Transfer Protocol (ATProto), an open protocol which underlies the Bluesky social network, along with other platforms such as Leaflet, Flashes, Streamplace, Germ, and Roomy. Users authenticate to servers via OAuth with their Personal Data Server (PDS).

This enables servers to avoid handling user credentials and simplifies login to disparate servers for users.

If users want to maintain multiple accounts, for example to have distinct and unlinkable personas which they present to different servers, such as a professional account and a personal account, they can. Clients will provide seamless multi-account support.

## Technology

Next, while there remain many smaller design decisions to resolve for Redwood Chat, we can identify some initial technology choices.

### Messaging Layer Security (MLS) for End-to-End Encryption

Messaging Layer Security is a protocol for high-performance end-to-end encryption for large groups. We choose it here as our mechanism for achieving E2EE instead of the Signal Protocol because MLS is better designed to handle large groups. In MLS, key material for group operations is structured into a tree, compared to the Signal Protocol's user-to-user mapping. This means many MLS group operations can be performed in $O(log(n))$ time, where $n$ is the number of group members, where Signal requires $O(n^{2})$ time.

### ATProto for Identity

As mentioned in the architecture section, ATProto is the mechanism of choice for handling identity in Redwood Chat. This means Redwood Chat clients and servers will need to properly handle OAuth authentication to users' PDS's.

### Rust for All Code Except UI Code

Rust will be used for all logic in Redwood Chat's server and client code except for UI rendering. Rust is a great language for code which has both strict performance requirements and needs to be high assurance. Since Redwood Chat will inherently be handling untrusted input from users in the form of chat messages, the protections afforded by Rust's memory safety are especially important.

Rust also has the benefit of having libraries available for both MLS (in the form of the OpenMLS project), and ATProto (in the form of the Atrium libraries). Both of these help to reduce the technical lift needed for implementations.

The tooling the Rust ecosystem, especially for testing, is also especially appealing. Tools like `cargo-nextest`, which provides a powerful alternative test harness over the default language-provided harness, and `cargo-insta`, which offers support for snapshot testing, will help to increase the assurance we have that code produced for Redwood Chat is correct before it is shipped to users.

### Svelte for Web UI Code

For the Web UI, which will be the first client UI developed for Redwood Chat, we will use Svelte. Svelte is being chosen particularly for its better baseline performance relative to React. Given our ambitious rendering performance goals for Redwood Chat clients, we believe Svelte is the wiser choice of the two.

## Minimum Viable Product

While we've identified an ambitious set of goals and features to implement in Redwood Chat, it's important to be realistic and set a reasonable Minimum Viable Product which can be shipped to users and become the basis for further iteration.

While this is a _very_ minimal set of features, it includes the essentials and does not compromise on our core requirements, in particular we would be shipping full identity control via ATProto-based authentication along with end-to-end encrypted messages in this MVP.

### Redwood Server

We will build a deployable server application with supports user authentication with ATProto, hosts communities, and contains text channels whose chats are end-to-end encrypted with MLS.

### Redwood Web Client

We will build a web-based client which can authenticate users to servers, let them join communities, and supports sending and receiving messages which are end-to-end encrypted with MLS.

## Minimum Viable _Project_

Any open source project isn't made solely of software, it is also its own community which requires care. In this section we lay out the minimum expectations, processes, and materials which must be made to set the Redwood Chat project off on the right foot.

### Establish an RFD Process

To ensure changes to Redwood Chat's design are considered well and open to community feedback, we will establish a Request for Discussion (RFD) process, wherein proposals are made in the form of written documents, submitted publicly for comment, and then either accepted or rejected based on community and project leadership review.

This document will actually be the first such RFD, though it does not lay out the specifics of the RFD process itself and must be followed by an RFD which does.

RFDs also form an historic record, enabling interested parties and project contributors to review why prior decisions were made.

### Create a Project Website

The project must have a website to host documentation and blog posts, and to link to the various accounts and other communication venues controlled by the project. The documentation in particular is extremely important, and must be written and maintained actively for all of Redwood Chat's relevant constituencies, including: end-users of Redwood Chat clients, operators of Redwood Chat servers, and maintainers of the Redwood Chat software.

### Create Project Social Media Accounts

The project must have social media accounts, through which infomation about the project, including the release of new versions or notices of major proposals which require broad community feedback, may be shared.

At the minimum, the project should have accounts on Bluesky and Mastodon. The choice of what Mastodon server to use remains an open question, though I (Andrew) have had positive experiences with Hachyderm.

The project will never create an account on X (formerly Twitter).

### Create a Project Discord Server

Until Redwood Chat has been developed enough that we can operate our own chat server to host project discussions, we should maintain a Discord server. This Discord server is not and should never be treated as a replacement for documentation, but instead as a complement to it. It will host both discussions among maintainers about the project, as well as offering a place for Redwood Chat users and server operators to ask questions about the software.

Whenever the project becomes able to transition its community to a Redwood Chat server, it will do so and the Discord will be decomissioned.

### Establish Basic Project Governance

While currently the project is, by nature of being brand new, under the sole governance of its creator (myself, Andrew Lilley Brinker), it will not remain so. The intent for the project is to transition to governance by a Core Team comprised of a group of contributors, and with a defined process for becoming part of this Core Team.

The specifics of this design are left for later determination, but we commit now that whatever eventually governance design is adopted must project four powers, which we identify as the Four Powers of Open Governance:

- __The Power to Speak__: An open governance project must empower people without formal authority in the project to have their voices heard in a project-visible venue where they will be safe.
- __The Power to Contribute__: An open governance project must empower people without formal authority in the project to submit contributions which may be accepted.
- __The Power to Govern__: An open governance project must empower people without formal authority in the project to gain formal authority in the project. All standards and processes for gaining this authority must be public and followed by existing wielders of project authority.
- __The Power to Hold Accountable__: An open governance project must empower people without formal authority in the project to remove individuals with formal authority through a publicly-defined process.

None of these powers should be construed to contradict the requirements of the project Code of Conduct. Individuals who are found to have violated the Code of Conduct severely do not retain the powers promised by the requirements of open governance.

This governance will be established once there are sufficient trusted contributors to form an initial "Core Team," who will be selected by Andrew based on their ethics, technical competence, and alignment of values with the values of the project.

### Establish a Project Code of Conduct

The project must establish and enforce a Code of Conduct. The project believes strongly in avoiding the harms of the paradox of tolerance, and will not tolerate intolerance in its community spaces. Individuals who violate the Code of Conduct will be handled according to its guidance, and individuals will be kept free to report violations per the process.

## Beyond the MVP

While we've defined the MVP for both the product and project, we should also identify priority items to develop after the MVP is complete.

### Audio / Video Chats

Discord's support for audio/video chats has been key to its success, and support for them is a requirement for any credible Discord replacement. At the same time, they represent a source of additional technical complexity, and should not be pursued until they can be integrated in a way which meets the performance and security expectations of Redwood Chat.

To that end, when we do implement support for audio/video chats, we will want to ensure they are end-to-end encrypted, likely by adopting the [DAVE protocol](https://github.com/discord/dave-protocol/blob/main/protocol.md) developed by Discord for their own audio/video chats.

### Direct Messages

Many chat systems, including Discord, offer the ability to send Direct Messages to users. In our architecture, there is some additional complexity, as DMs would be tied to specific servers, so without some mechanism in the client users could end up with multiple DM chats between each other, each running through a different server. Resolving this may involve offering some mechanism for syncing server and community membership information between clients, which would need to be designed in a way which meets the security and privacy requirements we've laid out for Redwood Chat.

### Native Mobile Clients (iOS and Android)

While we're prioritizing a web client first in our roadmap, we will of course want to have mobile clients which meet the same requirements we've defined for the web, performance and familiarity especially. The technical choices for how these should be implemented are left to be resolved later, particularly whether they should be done as wrappers around the web-based client, or as native apps written in their target platforms' languages of choice.

## Legal

Finally, it is worth laying out the basic intellectual property choices made for the project. These are intended to preserve the openness of the project's source code, and protect contributors, server operators, and users alike.

### Copyright

Source code for the Redwood Chat project will be licensed under the GPL v3. No Redwood Chat project will ever require a Contributor License Agreement (CLA) for contributions. Redwood Chat projects _will_ require signoff on a Developer Certificate of Origin, by which contributors assert that they have the legal right to make the contributions they are making.

Prose for the Redwood Chat project will be licensed under the terms of the Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International license (CC BY-NC-SA 4.0). This requires that reusers credit the source of the material, and can adapt, remix, and build on the material for non-commercial purposes only, and so long as the adapted material is licensed under identical terms.

These choices are made to protect the non-commercial nature of the project, and to protect against future relicensing.

### Patents

The GPL v3 is designed to protect against patent claims made based on contributions from contributors. No contributor should contribute code which violates existing patents. The Redwood Chat project will work to ensure that the software it produces is not encumbered by patents.

### Trademarks

No trademarks currently exist for names or logos related to the Redwood Chat project. If trademarks were established in the future, the goal with them would be to defined permitted users in a manner which empowers the community around Redwood Chat to use them to promote and discuss the project, while preserving the trademarks as is required under U.S. trademark law.

This could include, if determined to be in the project's best interest, transferrence of any future trademarks to an open source software foundation, to help ensure neutrality and protection of the trademarks by exploitation or protection for commercial purposes.

## Conclusion

Redwood Chat is a new and ambitious project, and there is an enormous amount of work to do to make it into a reality, and to achieve the goals set out in this document. At the same time, I believe it represents a real opportunity to build a credible Discord replacement which ensures user privacy and protects user freedoms.

It will be a long road ahead to build this system, and there remain many decisions, both in the design of the system and in its implementation. We will need help. If you agree with the values and vision laid out in this document, please get involved. We want this to be a community effort, and your voice and knowledge are valuable. Come help us make this dream a reality!