---
# System prepended metadata

title: Communications

---

# Communications


## Matrix server evaluation @ 07.30.2021
#### Current Synapse v. 1.39.0
#### Current Dendrite v. 0.4.1
#### Current matrix-js-sdk v. 12.1.0 & types v. 11.0.1

Observations:
* **Documentation** - the server specification in [Matrix](https://matrix.org/docs/spec/client_server/r0.6.1) doesn't correspond to the servers full capabilities
    * Group entities & assigning rooms to groups - not listed in the documentation but part of **Synapse** latest version capabilities as seen in [here (searchterm: `admin/rooms`)](https://github.com/matrix-org/synapse/blob/4b965c862dc66c0da5d3240add70e9b5f0aa720b/synapse/rest/client/v2_alpha/groups.py) and in the **clients** capabilities as seen in [here (searchterm: `addRoomToGroup`)](https://github.com/matrix-org/matrix-js-sdk/blob/develop/src/client.ts)
* [**Room tagging**](https://matrix.org/docs/spec/client_server/r0.6.1#room-tagging) - not a good method for distinguishing rooms, both performance wise and could obstruct decoupling in the future 
* **Synapse** vs **Dendrite**
    * Similar setup - both use PostgreSQL databases, environment setup (registration secrets, user registration, etc.)
    * Production readiness
        * Synapse is prod. ready and used as the server for matrix.org. 
        * Dendrite is in **beta** since Oct. 2020 - ready for early adopters, works well for (10s/100s of users), has an 'Are We Synapse Yet' index which when met might indicate readiness for adoption. Has polylith mode which enables scalability
    * Scalability
        * Synapse - can support 50k+ concurrent users as mentioned [here](https://matrix.org/blog/2020/11/03/how-we-fixed-synapses-scalability), can be scaled using [python workers](https://github.com/matrix-org/synapse/blob/master/docs/workers.md)
        * Dendrite - has [polylith](https://github.com/matrix-org/dendrite/blob/master/docs/INSTALL.md) mode which operates with kafka
    * API - **Dendrite** does **NOT** support groups/communitites which impact needs to be evaluated




## Candidate Platform - Matrix
Observations:
* **Conceptual model**: homeserver with rooms which then replicate their content depending on the users that are members
    * Really simple, but super powerful - and elegant. 
* **Key repositories**:
    * **Synapse**: original homeserver implementation, python
    * **Dendrite**: newer (gen 2) homeserver implementation, Go
    * **Sydent**: Identity server, python
* **Organisations**: 
    * Split between non-profit foundation + commercial entity
        * Element is from the commercial entity
        * Used to be called Victor, Riot
* **License**: Apache 2.0, so fine

### Research ideas
* **Decentralized storage**: For decentralisation Cherrytwist will need to have a way to store encrypted data that is used within a Challenge. 
    * The homeserver conceptual model might be worth exploring for this
    * Also explicitly part of their longer term vision, so could collaborate
* **Identity management**: for going live Cherrytwist will also need a production grade identity server. 
    * Again there may be pieces of the Matrix platform that could be worth evaluating in that context 
    * e.g. update the CT server to accept authentication from a Matrix identity server next to Demo Auth / AAD. 

### Evaluation (Day 1)
- was able to run Synapse in a docker container (no issues)
- investigated 3 repositories **vector-im/element-web**, **matrix-react-sdk**, **matrix-js-sdk** where
    - all of the repositories are populated in a mixture of ts/js files and coding styles without a clear reason why this was done
        - no clear convention is followed
        - concepts around modern js development are in most cases not in place
        - typescript restrictions are barely in place (allowing almost everything that can be done in a .js file, but able to frame it as a .ts one)
    - attempted running **element-web** against own **synapse** instance
        - default client parameters don't seem to work
        - tried configuring the application but due to lack of documentation abandoned
    - attempted extracting **matrix-react-sdk** integration from **element-web**
        - **matrix-react-sdk** CANNOT be directly integrated in a standard/blank react application
        - seems immature at this point
        - attempted setting it up then abandoning the idea for now
    - attempted extracting **matrix-js-sdk** integration from **matrix-react-sdk**
        - managed to send a message from own react app using **matrix-js-sdk**
        - found that SSO is part of the matrix client of **matrix-js-sdk**
        - will take significant effort to integrate a standalone js-sdk instead of react-sdk while trying to replicate all the functionality the element-web-client has

### Evaluation (Day 2)
- filed an [issue](https://github.com/vector-im/element-web/issues/16966) on [vector-im\element-web](https://github.com/vector-im/element-web) repository
- encryption/decryption almost in place

### Evaluation (Day 3)
- hit a brick wall in the build process where avoiding ejecting (CRA) the application is not an option anymore
- starting development of an adapter/facade package for matrix-react-sdk with intention of making it usable without the knowledge of all build intricacies

### Evaluation (Day 4)
- evaluating different scenarios
    - integrating matrix-react-sdk: complex solution that does not have documentation, code quality is questionable
    - integrating matrix-js-sdk: simpler solution, works almost out of the box, documentation is scarce