fbrausse / ksc Goto Github PK

The current implementation uses the json_store to do 2 things:

• implement the Protocol store libsignal-protocol-c expects
• store additional information required to use the Signal server like username, deviceId, password (to connect to the server), signalingKey (to decrypt Envelopes sent by the server), but also contacts and groups.

This information is crucial, if it is corrupted the account (or device, if it is a multi-device account) is gone and - depending on what data is corrupted - the sessions with others are lost (and their messages will fail to decrypt) or the server will entirely refuse to speak with you or both.

All this information is in a single JSON file. The reason for this design in ksc is interoperability with the signal-cli software family which only has this storage option.

Unfortunately, on every message - sent or received - the JSON file has to be updated. This is prone to errors as all the information gets replaced. We already do an open(tmp-file), write, fsync, close, rename procedure each time, however, this only gives us atomicity, not durability. As Ted points out, fsync-ing the directory would provide durability in case of an unexpected crash (and can be implemented quickly).

However, there is the question of whether an approach like axc of using a transactional backend (SQLite in this case) might not be better than fiddling with JSON...

If the (internal) facil.io event-loop could either

• be exported as an interface via the FFI to Python and be used in urwid, or
• somehow be replaced by an external event-loop,

this would eliminate the need for synchronizing between threads and allow scli to use ksc as a pure library in a single-threaded fashion. urwid's requirements for its EventLoop do not seem to be very high, maybe the first option is viable?