mirrors/vector-im-hydrogen-web
1
0
Fork 0
mirror of https://github.com/vector-im/hydrogen-web.git synced 2024-12-22 19:14:52 +01:00
Code Issues Projects Releases Wiki Activity

doc changes

Browse Source
This commit is contained in:
Bruno Windels 2020-06-24 22:43:46 +02:00
parent e2c8b5e595
commit b96b68a11e
3 changed files with 19 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/impl-thoughts/E2EE.md
View File

@ -14,7 +14,7 @@
- key [room id, user id] so we can easily get who is in a room by looking at [room id, min] -> [room id, max] - key [room id, user id] so we can easily get who is in a room by looking at [room id, min] -> [room id, max]
should the display name also be part of the key so the list is sorted by name? or have a sorting field of some sort should the display name also be part of the key so the list is sorted by name? or have a sorting field of some sort
- index on: - index on:
- user_id (to see which rooms a user is in, e.g. to recalculate trust on key changes) - [user_id, room_id] to see which rooms a user is in, e.g. to recalculate trust on key changes
- [room id, display name] to determine disambiguation? - [room id, display name] to determine disambiguation?
- for just e2ee without showing the list in the UI, we can do with only some of these things. - for just e2ee without showing the list in the UI, we can do with only some of these things.
- implement creating/loading an olm account - implement creating/loading an olm account
@ -236,7 +236,7 @@ other:
we should adjust the session store to become a key value store rather than just a single value, we can split up in: we should adjust the session store to become a key value store rather than just a single value, we can split up in:
- syncData (filterId, syncToken, syncCount) - syncData (filterId, syncToken, syncCount)
- serverConfig (/versions response) - serverConfig (/versions response)
- serialized olm account - serialized olm Account
so we don't have write all of that on every sync to update the sync token so we don't have write all of that on every sync to update the sync token
new stores: new stores:
@ -252,7 +252,9 @@ outbound-megolm-sessions
we should create constants with sets of store names that are needed for certain use cases, like write timeline will require [timeline, fragments, inbound-megolm-sessions] which we can reuse when filling the gap, writing timeline sync, ... we should create constants with sets of store names that are needed for certain use cases, like write timeline will require [timeline, fragments, inbound-megolm-sessions] which we can reuse when filling the gap, writing timeline sync, ...
room summary should gain a field tracking if members have been loaded or not?
main things to figure out: main things to figure out:
- how to decrypt? what indices do we need? is it reasonable to do this without having all EncryptionUser/devices in memory? - how to decrypt? what indices do we need? is it reasonable to do this without having all EncryptionUser/devices in memory?
- big part of this is how we can find the matching olm session for an incoming event/create a new olm session - big part of this is how we can find the matching olm session for an incoming event/create a new olm session
- can we mark some olm sessions as "spent" once they are too old/have used max messages? or do we need to look into all past olm sessions for a senderKey/device?

4
doc/impl-thoughts/RELATIONS.md
View File

@ -12,3 +12,7 @@ SendQueue will need to pass the non-sent state (redactions & relations) about an
Also, related ids should be processed recursively. If event 3 is a redaction of event 2, a reaction to event 1, all 3 entries should be considered as updated. Also, related ids should be processed recursively. If event 3 is a redaction of event 2, a reaction to event 1, all 3 entries should be considered as updated.
As a UI for reactions, we could show (👍 14 + 1) where the + 1 is our own local echo (perhaps style it pulsating and/or in grey?). Clicking it again would just show 14 and when the remote echo comes in it would turn into 15. As a UI for reactions, we could show (👍 14 + 1) where the + 1 is our own local echo (perhaps style it pulsating and/or in grey?). Clicking it again would just show 14 and when the remote echo comes in it would turn into 15.
wrt to how to store relations in indexeddb, we could store all local ids of related events (per type?) on the related-to event, so we can fetch them in one query for *all* events that have related events that were fetched in a range, without needing another index that would slow down writes. So that would only add 1 query which we only need to do when there are relations in the TimelineReader. what do we do though if we receive the relating event before the related-to event? An index would fix this mostly ... or we need a temp store where we store unresolved relations...

11
doc/impl-thoughts/ROOM-VERSIONS.md Normal file
View File

@ -0,0 +1,11 @@
- add internal room ids (to support room versioning later, and make internal event ids smaller and not needing escaping, and not needing a migration later on) ... hm this might need some more though. how to address a logical room? last room id? also we might not need it for room versioning ... it would basically be to make the ids smaller, but as idb is compressing, not sure that's a good reason? Although as we keep all room summaries in memory, it would be easy to map between these... you'd get event ids like 0000E78A00000020000A0B3C with room id, fragment id and event index. The room summary would store:
```
rooms: {
"!eKhOsgLidcrWMWnxOr:vector.modular.im": 0x0000E78A,
...
}
mostRecentRoom: 0x0000E78A
```
if this is not on an indexed field, how can we do a query to find the last room id and +1 to assign a new one?
how do we identify a logical room (consisting on a recent room and perhaps multiple outdated ones)?