Go to file
Dan f05ce478f0
Implement Push Notifications (#1842)
* Add Pushserver component with Pushers API

Co-authored-by: Tommie Gannert <tommie@gannert.se>
Co-authored-by: Dan Peleg <dan@globekeeper.com>

* Wire Pushserver component

Co-authored-by: Neil Alexander <neilalexander@users.noreply.github.com>

* Add PushGatewayClient.

The full event format is required for Sytest.

* Add a pushrules module.

* Change user API account creation to use the new pushrules module's defaults.

Introduces "scope" as required by client API, and some small field
tweaks to make some 61push Sytests pass.

* Add push rules query/put API in Pushserver.

This manipulates account data over User API, and fires sync messages
for changes. Those sync messages should, according to an existing TODO
in clientapi, be moved to userapi.

Forks clientapi/producers/syncapi.go to pushserver/ for later extension.

* Add clientapi routes for push rules to Pushserver.

A cleanup would be to move more of the name-splitting logic into
pushrules.go, to depollute routing.go.

* Output rooms.join.unread_notifications in /sync.

This is the read-side. Pushserver will be the write-side.

* Implement pushserver/storage for notifications.

* Use PushGatewayClient and the pushrules module in Pushserver's room consumer.

* Use one goroutine per user to avoid locking up the entire server for
  one bad push gateway.
* Split pushing by format.
* Send one device per push. Sytest does not support coalescing
  multiple devices into one push. Matches Synapse. Either we change
  Sytest, or remove the group-by-url-and-format logic.
* Write OutputNotificationData from push server. Sync API is already
  the consumer.

* Implement read receipt consumers in Pushserver.

Supports m.read and m.fully_read receipts.

* Add clientapi route for /unstable/notifications.

* Rename to UpsertPusher for clarity and handle pusher update

* Fix linter errors

* Ignore body.Close() error check

* Fix push server internal http wiring

* Add 40 newly passing 61push tests to whitelist

* Add next 12 newly passing 61push tests to whitelist

* Send notification data before notifying users in EDU server consumer

* NATS JetStream

* Goodbye sarama

* Fix `NewStreamTokenFromString`

* Consume on the correct topic for the roomserver

* Don't panic, NAK instead

* Move push notifications into the User API

* Don't set null values since that apparently causes Element upsetti

* Also set omitempty on conditions

* Fix bug so that we don't override the push rules unnecessarily

* Tweak defaults

* Update defaults

* More tweaks

* Move `/notifications` onto `r0`/`v3` mux

* User API will consume events and read/fully read markers from the sync API with stream positions, instead of consuming directly

Co-authored-by: Piotr Kozimor <p1996k@gmail.com>
Co-authored-by: Tommie Gannert <tommie@gannert.se>
Co-authored-by: Neil Alexander <neilalexander@users.noreply.github.com>
2022-03-03 11:40:53 +00:00
.github Make complement go fast (#2240) 2022-03-01 16:03:54 +00:00
appservice Merge both user API databases into one (#2186) 2022-02-18 11:31:05 +00:00
build Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
clientapi Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
cmd Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
docs Update systemd example to set LimitNOFILE 2022-02-25 17:35:10 +00:00
eduserver Remove OutputKeyChangeEvent consumer on keyserver (#2160) 2022-02-08 18:13:38 +01:00
federationapi MSC2946: Spaces Summary (round 2) (#2232) 2022-03-01 13:40:07 +00:00
internal Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
keyserver Skip flakey test for now 2022-03-02 11:38:13 +00:00
mediaapi Media endpoints on /v3 (#2242) 2022-03-02 11:35:35 +00:00
roomserver Remove unnecessary error line (#2237) 2022-03-01 14:39:06 +00:00
setup Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
syncapi Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
test/wasm Add startup testing for Wasm Pinecone build (#1910) 2021-07-20 12:14:58 +01:00
userapi Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
.dockerignore Docker Hub (#1053) 2020-05-21 13:02:28 +01:00
.gitignore Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
.golangci.yml Increase gocyclo complexity to 25 (and remove all but 2 golint directives related to it) (#1783) 2021-03-03 14:35:57 +00:00
are-we-synapse-yet.list Update are-we-synapse-yet (#2018) 2021-10-25 10:08:02 +01:00
are-we-synapse-yet.py Allow partial test runs (#2076) 2021-12-20 10:26:23 +00:00
build-dendritejs.sh Add startup testing for Wasm Pinecone build (#1910) 2021-07-20 12:14:58 +01:00
build.sh Various updates for renaming the master branch to main 2022-02-08 16:16:01 +00:00
CHANGES.md Version 0.6.4 (#2212) 2022-02-22 16:55:08 +00:00
dendrite-config.yaml Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
go.mod Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
go.sum Update NATS Server to v2.7.3 2022-03-02 10:36:20 +00:00
LICENSE Add Apache Version 2.0 license and headers to all golang files 2017-04-21 00:40:52 +02:00
q.sqlite Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
README.md Require Go 1.16 (#2122) 2022-01-28 16:24:01 +00:00
run-sytest.sh Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
show-expected-fail-tests.sh Fix newlines between white/blacklist test names in buildkite annotations (#1003) 2020-05-04 14:48:49 +01:00
sytest-blacklist Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
sytest-whitelist Implement Push Notifications (#1842) 2022-03-03 11:40:53 +00:00
test-dendritejs.sh Add startup testing for Wasm Pinecone build (#1910) 2021-07-20 12:14:58 +01:00

Dendrite Build Status Dendrite Dendrite Dev

Dendrite is a second-generation Matrix homeserver written in Go. It intends to provide an efficient, reliable and scalable alternative to Synapse:

  • Efficient: A small memory footprint with better baseline performance than an out-of-the-box Synapse.
  • Reliable: Implements the Matrix specification as written, using the same test suite as Synapse as well as a brand new Go test suite.
  • Scalable: can run on multiple machines and eventually scale to massive homeserver deployments.

As of October 2020, Dendrite has now entered beta which means:

  • Dendrite is ready for early adopters. We recommend running in Monolith mode with a PostgreSQL database.
  • Dendrite has periodic semver releases. We intend to release new versions as we land significant features.
  • Dendrite supports database schema upgrades between releases. This means you should never lose your messages when upgrading Dendrite.
  • Breaking changes will not occur on minor releases. This means you can safely upgrade Dendrite without modifying your database or config file.

This does not mean:

  • Dendrite is bug-free. It has not yet been battle-tested in the real world and so will be error prone initially.
  • All of the CS/Federation APIs are implemented. We are tracking progress via a script called 'Are We Synapse Yet?'. In particular, presence and push notifications are entirely missing from Dendrite. See CHANGES.md for updates.
  • Dendrite is ready for massive homeserver deployments. You cannot shard each microservice, only run each one on a different machine.

Currently, we expect Dendrite to function well for small (10s/100s of users) homeserver deployments as well as P2P Matrix nodes in-browser or on mobile devices. In the future, we will be able to scale up to gigantic servers (equivalent to matrix.org) via polylith mode.

If you have further questions, please take a look at our FAQ or join us in:

Requirements

To build Dendrite, you will need Go 1.16 or later.

For a usable federating Dendrite deployment, you will also need:

  • A domain name (or subdomain)
  • A valid TLS certificate issued by a trusted authority for that domain
  • SRV records or a well-known file pointing to your deployment

Also recommended are:

  • A PostgreSQL database engine, which will perform better than SQLite with many users and/or larger rooms
  • A reverse proxy server, such as nginx, configured like this sample

The Federation Tester can be used to verify your deployment.

Get started

If you wish to build a fully-federating Dendrite instance, see INSTALL.md. For running in Docker, see build/docker.

The following instructions are enough to get Dendrite started as a non-federating test deployment using self-signed certificates and SQLite databases:

$ git clone https://github.com/matrix-org/dendrite
$ cd dendrite
$ ./build.sh

# Generate a Matrix signing key for federation (required)
$ ./bin/generate-keys --private-key matrix_key.pem

# Generate a self-signed certificate (optional, but a valid TLS certificate is normally
# needed for Matrix federation/clients to work properly!)
$ ./bin/generate-keys --tls-cert server.crt --tls-key server.key

# Copy and modify the config file - you'll need to set a server name and paths to the keys
# at the very least, along with setting up the database connection strings.
$ cp dendrite-config.yaml dendrite.yaml

# Build and run the server:
$ ./bin/dendrite-monolith-server --tls-cert server.crt --tls-key server.key --config dendrite.yaml

Then point your favourite Matrix client at http://localhost:8008 or https://localhost:8448.

Progress

We use a script called Are We Synapse Yet which checks Sytest compliance rates. Sytest is a black-box homeserver test rig with around 900 tests. The script works out how many of these tests are passing on Dendrite and it updates with CI. As of January 2022 we're at around 65% CS API coverage and 92% Federation coverage, though check CI for the latest numbers. In practice, this means you can communicate locally and via federation with Synapse servers such as matrix.org reasonably well. There's a long list of features that are not implemented, notably:

  • Push
  • Search and Context
  • User Directory
  • Presence
  • Guests

We are prioritising features that will benefit single-user homeservers first (e.g Receipts, E2E) rather than features that massive deployments may be interested in (User Directory, OpenID, Guests, Admin APIs, AS API). This means Dendrite supports amongst others:

  • Core room functionality (creating rooms, invites, auth rules)
  • Federation in rooms v1-v7
  • Backfilling locally and via federation
  • Accounts, Profiles and Devices
  • Published room lists
  • Typing
  • Media APIs
  • Redaction
  • Tagging
  • E2E keys and device lists
  • Receipts

Contributing

We would be grateful for any help on issues marked as Are We Synapse Yet. These issues all have related Sytests which need to pass in order for the issue to be closed. Once you've written your code, you can quickly run Sytest to ensure that the test names are now passing.

For example, if the test Local device key changes get to remote servers was marked as failing, find the test file (e.g via grep or via the CI log output it's tests/50federation/40devicelists.pl ) then to run Sytest:

docker run --rm --name sytest
-v "/Users/kegan/github/sytest:/sytest"
-v "/Users/kegan/github/dendrite:/src"
-v "/Users/kegan/logs:/logs"
-v "/Users/kegan/go/:/gopath"
-e "POSTGRES=1" -e "DENDRITE_TRACE_HTTP=1"
matrixdotorg/sytest-dendrite:latest tests/50federation/40devicelists.pl

See sytest.md for the full description of these flags.

You can try running sytest outside of docker for faster runs, but the dependencies can be temperamental and we recommend using docker where possible.

cd sytest
export PERL5LIB=$HOME/lib/perl5
export PERL_MB_OPT=--install_base=$HOME
export PERL_MM_OPT=INSTALL_BASE=$HOME
./install-deps.pl

./run-tests.pl -I Dendrite::Monolith -d $PATH_TO_DENDRITE_BINARIES

Sometimes Sytest is testing the wrong thing or is flakey, so it will need to be patched. Ask on #dendrite-dev:matrix.org if you think this is the case for you and we'll be happy to help.

If you're new to the project, see CONTRIBUTING.md to get up to speed then look for Good First Issues. If you're familiar with the project, look for Help Wanted issues.

Hardware requirements

Dendrite in Monolith + SQLite works in a range of environments including iOS and in-browser via WASM.

For small homeserver installations joined on ~10s rooms on matrix.org with ~100s of users in those rooms, including some encrypted rooms:

  • Memory: uses around 100MB of RAM, with peaks at around 200MB.
  • Disk space: After a few months of usage, the database grew to around 2GB (in Monolith mode).
  • CPU: Brief spikes when processing events, typically idles at 1% CPU.

This means Dendrite should comfortably work on things like Raspberry Pis.