mirror of
https://github.com/matrix-org/dendrite
synced 2024-12-30 01:43:44 +01:00
a97b8eafd4
* Use a fork of pq which supports userCurrent on wasm * Use sqlite3_js driver when running in JS * Add cmd/dendritejs to pull in sqlite3_js driver for wasm only * Update to latest go-sqlite-js version * Replace prometheus with a stub. sigh * Hard-code a config and don't use opentracing * Latest go-sqlite3-js version * Generate a key for now * Listen for fetch traffic rather than HTTP * Latest hacks for js * libp2p support * More libp2p * Fork gjson to allow us to enforce auth checks as before Previously, all events would come down redacted because the hash checks would fail. They would fail because sjson.DeleteBytes didn't remove keys not used for hashing. This didn't work because of a build tag which included a file which no-oped the index returned. See https://github.com/tidwall/gjson/issues/157 When it's resolved, let's go back to mainline. * Use gjson@1.6.0 as it fixes https://github.com/tidwall/gjson/issues/157 * Use latest gomatrixserverlib for sig checks * Fix a bug which could cause exclude_from_sync to not be set Caused when sending events over federation. * Use query variadic to make lookups actually work! * Latest gomatrixserverlib * Add notes on getting p2p up and running Partly so I don't forget myself! * refactor: Move p2p specific stuff to cmd/dendritejs This is important or else the normal build of dendrite will fail because the p2p libraries depend on syscall/js which doesn't work on normal builds. Also, clean up main.go to read a bit better. * Update ho-http-js-libp2p to return errors from RoundTrip * Add an LRU cache around the key DB We actually need this for P2P because otherwise we can *segfault* with things like: "runtime: unexpected return pc for runtime.handleEvent" where the event is a `syscall/js` event, caused by spamming sql.js caused by "Checking event signatures for 14 events of room state" which hammers the key DB repeatedly in quick succession. Using a cache fixes this, though the underlying cause is probably a bug in the version of Go I'm on (1.13.7) * breaking: Add Tracing.Enabled to toggle whether we do opentracing Defaults to false, which is why this is a breaking change. We need this flag because WASM builds cannot do opentracing. * Start adding conditional builds for wasm to handle lib/pq The general idea here is to have the wasm build have a `NewXXXDatabase` that doesn't import any postgres package and hence we never import `lib/pq`, which doesn't work under WASM (undefined `userCurrent`). * Remove lib/pq for wasm for syncapi * Add conditional building to remaining storage APIs * Update build script to set env vars correctly for dendritejs * sqlite bug fixes * Docs * Add a no-op main for dendritejs when not building under wasm * Use the real prometheus, even for WASM Instead, the dendrite-sw.js must mock out `process.pid` and `fs.stat` - which must invoke the callback with an error (e.g `EINVAL`) in order for it to work: ``` global.process = { pid: 1, }; global.fs.stat = function(path, cb) { cb({ code: "EINVAL", }); } ``` * Linting |
||
|---|---|---|
| .. | ||
| alias | ||
| api | ||
| auth | ||
| input | ||
| query | ||
| state | ||
| storage | ||
| types | ||
| version | ||
| README.md | ||
| roomserver.go | ||
RoomServer
RoomServer Internals
Numeric IDs
To save space matrix string identifiers are mapped to local numeric IDs. The numeric IDs are more efficient to manipulate and use less space to store. The numeric IDs are never exposed in the API the room server exposes. The numeric IDs are converted to string IDs before they leave the room server. The numeric ID for a string ID is never 0 to avoid being confused with go's default zero value. Zero is used to indicate that there was no corresponding string ID. Well-known event types and event state keys are preassigned numeric IDs.
State Snapshot Storage
The room server stores the state of the matrix room at each event. For efficiency the state is stored as blocks of 3-tuples of numeric IDs for the event type, event state key and event ID. For further efficiency the state snapshots are stored as the combination of up to 64 these blocks. This allows blocks of the room state to be reused in multiple snapshots.
The resulting database tables look something like this:
+-------------------------------------------------------------------+
| Events |
+---------+-------------------+------------------+------------------+
| EventNID| EventTypeNID | EventStateKeyNID | StateSnapshotNID |
+---------+-------------------+------------------+------------------+
| 1 | m.room.create 1 | "" 1 | <nil> 0 |
| 2 | m.room.member 2 | "@user:foo" 2 | <nil> 0 |
| 3 | m.room.member 2 | "@user:bar" 3 | {1,2} 1 |
| 4 | m.room.message 3 | <nil> 0 | {1,2,3} 2 |
| 5 | m.room.member 2 | "@user:foo" 2 | {1,2,3} 2 |
| 6 | m.room.message 3 | <nil> 0 | {1,3,6} 3 |
+---------+-------------------+------------------+------------------+
+----------------------------------------+
| State Snapshots |
+-----------------------+----------------+
| EventStateSnapshotNID | StateBlockNIDs |
+-----------------------+----------------|
| 1 | {1} |
| 2 | {1,2} |
| 3 | {1,2,3} |
+-----------------------+----------------+
+-----------------------------------------------------------------+
| State Blocks |
+---------------+-------------------+------------------+----------+
| StateBlockNID | EventTypeNID | EventStateKeyNID | EventNID |
+---------------+-------------------+------------------+----------+
| 1 | m.room.create 1 | "" 1 | 1 |
| 1 | m.room.member 2 | "@user:foo" 2 | 2 |
| 2 | m.room.member 2 | "@user:bar" 3 | 3 |
| 3 | m.room.member 2 | "@user:foo" 2 | 6 |
+---------------+-------------------+------------------+----------+