Matrix: a new specification for federated realtime chat
Matrix: a new specification for federated realtime chat
Posted Feb 21, 2015 7:58 UTC (Sat) by eternaleye (guest, #67051)In reply to: Matrix: a new specification for federated realtime chat by Arathorn
Parent article: Matrix: a new specification for federated realtime chat
I'd argue that even with PFS, history sync is meaningful for a few reasons:
- Storage - if the client is only storing fixed-size keys, rather than variable-sized records, small clients (like phones) will be able to keep more history
- Reliability - fixed-size keys can trivially be saved as a packed array, either of keys or of {timestamp, key} tuples (for searching efficiency), while variably-length messages require more complex (and failure-prone) storage
- Verification - if the messages are encrypted using AEAD (and they should be!), keeping the key allows you to revalidate that yes, this _is_ the same message that was originally sent.
- Simplicity - keeping the behavior of history sync the same even with PFS reduces the number of corner cases to handle in the code (and possibly the protocol).
- Sharing - you want to show someone a past message, and you want them to trust that it actually happened when you say it did (and possibly the context, which are just more messages). If the server still has it, this is trivial: Send them the message identifier and the key, and let them fetch it themselves. This allows treating keys as read-capabilities for historic messages, which is a useful tool indeed.
Posted Feb 22, 2015 23:46 UTC (Sun)
by Arathorn (guest, #101018)
[Link]
Matrix: a new specification for federated realtime chat