connected
disconnected

user changed status
user changed display name (DB ack)
user started typing
user paused typing
user resumed typing
user stopped typing

friend changed status
friend changed display name
friend started typing
friend paused typing
friend resumed typing
friend stopped typing

message received from friend - realtime & delayed (DB ack)
message sent to friend (DB ack)
message was delivered to friend
message was queued for offline delivery

added friend
removed friend
received friend request
accepted friend request
rejected friend request



## Security levels
==================

Low: Unauthenticated other party
Normal: Authenticated other party, history readable by any new device
High: Authenticated other party, no logs/history

## OLM
======

All public keys are published.

Ed25519 fingerprint keypair: Signing messages(?), device identification
Curve25519 identity keypair: Shared secret establishment, Olm session establishment
Curve25519 one-time keypairs: Olm session establishment but only single-use (offline messages?)

Megolm key: Group message encryption, via AES256 and HMAC-SHA256 derivation, derived after each sent message
Ed25519 Megolm signing keypair: Signing messages, specific to each Megolm session, public key shared with each praticipant

KEY GENERATION EVENTS
---------------------

First device start: (via olm_create_account)
	Fingerprint keypair
	Identity keypair

When needed as one-time keys run out: (via olm_account_generate_one_time_keys and olm_account_mark_keys_as_published)
	One-time keypairs

Group chat creation:




--

FOR LATER:

what if the DB breaks before a message-receipt notification is processed? the message will forever look unreceived?


---

react-hot-loader@4.4.0-1:
  version "4.4.0-1"
  resolved "https://registry.yarnpkg.com/react-hot-loader/-/react-hot-loader-4.4.0-1.tgz#2774f7fd0e62a9756f71a817acfc603b4152c0d0"
  integrity sha512-0dlxQMQ4ndEzV4h1u/GfHgM7U6HXR4C7PIQ9sy59Lr0O8zCygj6lGf9HMfOEHSsO8+p2dVR0DbKbfZAMKImVLQ==
  dependencies:
    fast-levenshtein "^2.0.6"
    global "^4.3.0"
    hoist-non-react-statics "^2.5.0"
    prop-types "^15.6.1"
    react-lifecycles-compat "^3.0.4"
    shallowequal "^1.0.2"
    source-map "^0.7.3"


-------

Broken hot-reloading:
  - Exported components
  - Redux-connected components

Working hot-reloading:
  - Everything else (including when referenced *from* a broken component!)

-------

Important project-wide FIXMEs before deployment:
- Verify that all client-side logicHandler validation code has a server-side equivalent

-------

Long-term improvements:
- Find a more optimized hooks API for Redux, so that we don't have to re-render the entire tree every time the store contents change.

------

Attached vs. Detached request/form state  
- Attached: Request/form state is related to a particular resource (eg. deleting an existing resource)
    Should be stored within the resource itself? As it should affect all UIs for that resource.
- Detached: Form state for free-standing forms that are not associated with any particular resource (yet), and that therefore can't usually conflict with other forms, eg. "create new resource" forms.
    Should be stored in separate FormState data, since the state is only relevant to the specific form. Possibly could be scoped, though? If the same "create X" form exists for multiple resources... maybe could be done with statePath?