# 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