Features
- exchangeable database
- in memory (e. g. for tests)
- trixnity-client-repository-exposed implements a database for trixnity-client with Exposed. This supports JVM based platforms only.
- trixnity-client-repository-indexeddb implements a database for trixnity-client with indexeddb. This supports JS (browser).
- trixnity-client-repository-room implements a database for trixnity-client with room. This supports JVM/Android and iOS.
- exchangeable media store
- in memory (e. g. for tests)
- trixnity-client-media-okio implements a file system based media store with okio. This supports JVM/Android/Native/NodeJs.
- trixnity-client-media-opfs implements a store with Origin private file system. This supports JS (browser).
- trixnity-client-media-indexeddb implements a store with indexeddb. This supports JS (browser).
- exchangeable crypto driver
- trixnity-client-cryptodriver-libolm using libolm.
- trixnity-client-cryptostore-vodozemac
using vodozemac. Includes migration from
cryptodriver-libolm.
- exchangeable authentication
- classic login
- OAuth2-based login
- extremely fast reactive cache on top of the database
- media support (offline, huge files, etc.)
- E2E support
- cross signing
- fallback keys
- room key backup
- room key requests (only between own verified devices and when key backup is disabled)
- dehydrated devices
- room list
- timelines
- room upgrades (invisible due to merged timelines and auto-join)
- user and room display name calculation
- asynchronous message sending without caring about E2E stuff or online status
- redactions
- relations:
- reply (without fallback)
- replace
- reaction via annotation
- thread (basic support, no separate timelines or client aggregations yet)
- notifications
- server discovery
- ... many more
Cache
Because reactive UIs are really common, Trixnity wants to give the UI access to data in a reactive way. There are only a few databases, that support listeners and this would limit support for multiple supported databases. That's why an intermediate layer based on Kotlin Flows has been introduced. This intermediate layer reads values directly from a generic database layer and also writes changes to it. The values are kept in this layer as long as they are subscribed. This means, that if someone else subscribes a value, he will immediately get the value without an additional database call. This goes so far, that even if there are no subscribers anymore, the value is kept a bit longer in this layer. If someone ask for the value (for example) 10 seconds later, there is – again - no database call needed.