wrote docs about how to do invites and e2ee

This commit is contained in:
Bruno Windels 2019-10-23 09:42:39 +02:00
parent 964e09bfd5
commit 738b8202be
4 changed files with 38 additions and 9 deletions

View file

@ -41,7 +41,7 @@
- DONE: send messages
- DONE: fill gaps with call to /messages
- build script
- DONE: build script
- DONE: take dev index.html, run some dom modifications to change script tag with `parse5`.
- DONE: create js bundle, rollup
- DONE: create css bundle, postcss, probably just need postcss-import for now, but good to have more options
@ -51,21 +51,27 @@
- deploy script
- upload /target to github pages
- offline available
- DONE: offline available
- both offline mechanisms have (filelist, version) as input for their template:
- create appcache manifest with (index.html, brawl.js, brawl.css) and print version number in it
- create service worker wit file list to cache (at top const files = "%%FILES_ARRAY%%", version = "%%VERSION%%")
- write web manifest
- delete sessions from picker & option to close current session and go back to picker
- DONE: delete and clear sessions from picker
- option to close current session and go back to picker
- accept invite
- member list
- e2e encryption
- sync retry strategy
- instead of stopping sync on fetch error, show spinner and status and have auto retry strategy
- create room
- join room
- accept invite
- leave room
- unread rooms, badge count, sort rooms by activity
- create sync filter
- lazy loading members
- DONE: create sync filter
- DONE: lazy loading members
- decide denormalized data in summary vs reading from multiple stores PER room on load
- allow Room/Summary class to be subclassed and store additional data?
- store account data, support read markers

View file

@ -62,6 +62,19 @@
## Megolm
- ??? does every sender in a room have their own megolm session (to send)? I suppose so, yes
- we need to pickle inbound and outbound sessions separately ... are they different entities?
- they are: OutboundGroupSession and InboundGroupSession
- should they be in different stores?
- e.g. we have a store for outbound sessions (to send ourselves) and one for inbound
- NO! the e2e implementation guide says specifically:
"It should store these details as an inbound session, just as it would when receiving them via an m.room_key event."
- wait, we probably have to store the session as BOTH an inbound and outbound session?
- the outbound one so we can keep using it to encrypt
- the inbound one to be able to decrypt our own messages? as we won't send a m.room_key to our own device
- so yes, we'll store our own outbound sessions. Riot doesn't do this and just starts new ones when starting the client,
but keeping this would probably give us better offline support/less network usage as we wouldn't have to create new megolm session most of the time
- and we store the inbound sessions (including the ones derived from our own outbound sessions) to be able to decrypt all messages
- create new megolm session
- create new outbound group session
- get megolm session id and key, put in m.room_key event
@ -70,6 +83,7 @@
- receiving new megolm session
- listen for m.room_key device message
- decrypt using olm
- create inbound group session
- store megolm session
- encrypt megolm message
- decrypt megolm message

6
doc/invites.md Normal file
View file

@ -0,0 +1,6 @@
# Invites
- invite_state doesn't update over /sync
- can we reuse room summary? need to clear when joining
- rely on filter operator to split membership=join from membership=invite?
-

View file

@ -5,14 +5,17 @@ view hierarchy:
SessionView
SyncStatusBar
ListView(left-panel)
RoomTile
SwitchView
RoomPlaceholderView
RoomView
MiddlePanel
ListView(timeline)
event tiles (see ui/session/room/timeline/)
ComposerView
RightPanel
SessionStartView
SessionPickView
LoginView
SessionPickView
ListView
SessionPickerItemView
LoginView
```