forked from mystiq/hydrogen-web
wrote docs about how to do invites and e2ee
This commit is contained in:
parent
964e09bfd5
commit
738b8202be
4 changed files with 38 additions and 9 deletions
18
doc/TODO.md
18
doc/TODO.md
|
@ -41,7 +41,7 @@
|
||||||
- DONE: send messages
|
- DONE: send messages
|
||||||
- DONE: fill gaps with call to /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: take dev index.html, run some dom modifications to change script tag with `parse5`.
|
||||||
- DONE: create js bundle, rollup
|
- DONE: create js bundle, rollup
|
||||||
- DONE: create css bundle, postcss, probably just need postcss-import for now, but good to have more options
|
- DONE: create css bundle, postcss, probably just need postcss-import for now, but good to have more options
|
||||||
|
@ -51,21 +51,27 @@
|
||||||
- deploy script
|
- deploy script
|
||||||
- upload /target to github pages
|
- upload /target to github pages
|
||||||
|
|
||||||
- offline available
|
- DONE: offline available
|
||||||
- both offline mechanisms have (filelist, version) as input for their template:
|
- 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 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%%")
|
- create service worker wit file list to cache (at top const files = "%%FILES_ARRAY%%", version = "%%VERSION%%")
|
||||||
- write web manifest
|
- 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
|
- create room
|
||||||
- join room
|
- join room
|
||||||
- accept invite
|
|
||||||
- leave room
|
- leave room
|
||||||
- unread rooms, badge count, sort rooms by activity
|
- unread rooms, badge count, sort rooms by activity
|
||||||
|
|
||||||
- create sync filter
|
- DONE: create sync filter
|
||||||
- lazy loading members
|
- DONE: lazy loading members
|
||||||
- decide denormalized data in summary vs reading from multiple stores PER room on load
|
- 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?
|
- allow Room/Summary class to be subclassed and store additional data?
|
||||||
- store account data, support read markers
|
- store account data, support read markers
|
||||||
|
|
14
doc/e2e.md
14
doc/e2e.md
|
@ -62,6 +62,19 @@
|
||||||
|
|
||||||
|
|
||||||
## Megolm
|
## 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 megolm session
|
||||||
- create new outbound group session
|
- create new outbound group session
|
||||||
- get megolm session id and key, put in m.room_key event
|
- get megolm session id and key, put in m.room_key event
|
||||||
|
@ -70,6 +83,7 @@
|
||||||
- receiving new megolm session
|
- receiving new megolm session
|
||||||
- listen for m.room_key device message
|
- listen for m.room_key device message
|
||||||
- decrypt using olm
|
- decrypt using olm
|
||||||
|
- create inbound group session
|
||||||
- store megolm session
|
- store megolm session
|
||||||
- encrypt megolm message
|
- encrypt megolm message
|
||||||
- decrypt megolm message
|
- decrypt megolm message
|
||||||
|
|
6
doc/invites.md
Normal file
6
doc/invites.md
Normal 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?
|
||||||
|
-
|
|
@ -5,14 +5,17 @@ view hierarchy:
|
||||||
SessionView
|
SessionView
|
||||||
SyncStatusBar
|
SyncStatusBar
|
||||||
ListView(left-panel)
|
ListView(left-panel)
|
||||||
|
RoomTile
|
||||||
SwitchView
|
SwitchView
|
||||||
RoomPlaceholderView
|
RoomPlaceholderView
|
||||||
RoomView
|
RoomView
|
||||||
MiddlePanel
|
MiddlePanel
|
||||||
ListView(timeline)
|
ListView(timeline)
|
||||||
|
event tiles (see ui/session/room/timeline/)
|
||||||
ComposerView
|
ComposerView
|
||||||
RightPanel
|
RightPanel
|
||||||
SessionStartView
|
|
||||||
SessionPickView
|
SessionPickView
|
||||||
|
ListView
|
||||||
|
SessionPickerItemView
|
||||||
LoginView
|
LoginView
|
||||||
```
|
```
|
||||||
|
|
Loading…
Reference in a new issue