doc changes

doc/impl-thoughts/E2EE.md

@@ -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]
             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:
-            - 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?
         - 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
@@ -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:
     - syncData (filterId, syncToken, syncCount)
     - 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
 
 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, ...
 
+room summary should gain a field tracking if members have been loaded or not?
 
 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?
         - 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?

doc/impl-thoughts/RELATIONS.md

@@ -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.
 
 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...

doc/impl-thoughts/ROOM-VERSIONS.md

@@ -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)?