Mostly, although there are still bugs and missing features. If you are a confident power user and you are happy to spend some time debugging things when they go wrong, then please try out Dendrite. If you are a community, organisation or business that demands stability and uptime, then Dendrite is not for you yet - please install Synapse instead.
No, although a good portion of the Matrix specification has been implemented. Mostly missing are client features - see the readme at the root of the repository for more information.
No, not at present. There will be in the future when Dendrite reaches version 1.0.
Monolith deployments are always preferred where possible, and at this time, are far better tested than polylith deployments are. The only reason to consider a polylith deployment is if you wish to run different Dendrite components on separate physical machines.
Check the Federation Tester. You need at least:
- A valid DNS name
- A valid TLS certificate for that DNS name
- Either DNS SRV records or well-known files
It should do, although we are aware of some minor issues:
- Element Android: registration does not work, but logging in with an existing account does
- Hydrogen: occasionally sync can fail due to gaps in the
sinceparameter, but clearing the cache fixes this
No, not yet. This is a planned feature.
Possibly - Dendrite does have some application service support but it is not well tested. Please let us know by raising a GitHub issue if you try it and run into problems.
Bridges known to work (as of v0.5.1):
Remember to add the config file(s) to the app_service_api config.
Yes, you can do this by disabling federation - set disable_federation to true in the global section of the Dendrite configuration file.
Please use PostgreSQL wherever possible, especially if you are planning to run a homeserver that caters to more than a couple of users.
Generally speaking, you should expect to see some CPU spikes, particularly if you are joining or participating in large rooms. However, constant/sustained high CPU usage is not expected - if you are experiencing that, please join #dendrite-dev:matrix.org and let us know, or file a GitHub issue.
A lot of users report that Dendrite is using a lot of RAM, sometimes even gigabytes of it. This is usually due to Go's allocator behaviour, which tries to hold onto allocated memory until the operating system wants to reclaim it for something else. This can make the memory usage look significantly inflated in tools like top/htop when actually most of that memory is not really in use at all.
If you want to prevent this behaviour so that the Go runtime releases memory normally, start Dendrite using the GODEBUG=madvdontneed=1 environment variable. It is also expected that the allocator behaviour will be changed again in Go 1.16 so that it does not hold onto memory unnecessarily in this way.
If you are running with GODEBUG=madvdontneed=1 and still see hugely inflated memory usage then that's quite possibly a bug - please join #dendrite-dev:matrix.org and let us know, or file a GitHub issue.
You may need to revisit the connection limit of your PostgreSQL server and/or make changes to the max_connections lines in your Dendrite configuration. Be aware that each Dendrite component opens its own database connections and has its own connection limit, even in monolith mode!