Core conversation
Communities, channels and categories, direct messages, friends, reactions, attachments, search, presence and in-app notifications.
Roadmap
The labels below separate what works today, what is built but still off by default, and what is only an idea. They reflect the state of the code: if a capability is off by default, backed by a single provider, or only a setting and a name, it is described that way.
Shipped
These are implemented and available today. The features page covers them in detail.
Communities, channels and categories, direct messages, friends, reactions, attachments, search, presence and in-app notifications.
Roles and permissions, invites, reports, warnings, timeouts and bans, appeals, announcements, and a platform administration surface.
Registration with optional approval, two-factor authentication, email verification and recovery, data export and account deletion.
Docker and manual installs, SQLite or MySQL, mail through SMTP or an API, public discovery, bots and webhooks, themes, and the desktop app.
In progress
These have real code behind them and are deliberately off by default. They stay off until the work is finished.
The room and signalling model exist behind one provider, with participant limits, optional screen sharing and stage channels. It is off by default and there is no second provider. Turn it on if you want to test it; do not plan a product around it yet.
The flag and the delivery plumbing exist and default to off. Notifications are dependable in-app today. A notification that reliably wakes a backgrounded phone is a different piece of work, and it is not done.
Planned and exploratory
Something here may change shape or may not arrive. Treat it as direction, not as a schedule.
Instances are independent today, and there is a global sync setting and the beginning of a shared vocabulary for connecting them. A working federation of separate instances does not exist yet.
Continued work on the everyday surfaces: message editing and history, richer notification controls, and the small things that make a long conversation easier to follow.
More of the deployment lifecycle in one place: clearer upgrade and backup guidance, and fewer places where an operator has to read the source to find out what a setting does.
Not currently planned
Trycord is software you run. There is an official instance, but the architecture does not assume a single company in the middle, and that is not going to change into the usual arrangement.
There is no advertising surface and no plan to build one. An instance's data belongs to the instance, and there is no mechanism to send it anywhere else.
Have a say
If something here matters to you, or you think the ordering is wrong, the support page explains where to say so.