-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Download and decrypt messages #40
Comments
after a sync occurs, we want to as a background task, always download any new messages, decrypt them, and display them in the conversation view for each source. this is in contrast to #19, which will be for downloading files upon request by the user. the reason for the difference is that files may be large (up to 500MB, which can take up to 120 mins over Tor) and we only want to do it on demand. |
As an update, I'm working on this issue in https://github.com/freedomofpress/securedrop-client/tree/download-messages. Messages are downloading, decrypting, and being stored appropriately, but I'm not sure how we're going to thread messages and replies (and indeed how we're going to order messages themselves). |
@joshuathayer I can help some with clarifying how threading/ordering shall work (assuming you're referencing how messaging will surface to users in the GUI, vs how they're tagged on the backend?). There are many little elements in this prototype that are either out-of-date (such as use of the term "2FA" as a field label) or buggy/incorrect (such as the off-alignment of Source names and the preview text after loading, in the left pane), but demonstration of ordering and read/unread are current, here: https://projects.invisionapp.com/prototype/SD-JWS-088-cjnm38nxi007ovk01z0umki2p/play/3813e8cf Will compose some rules to clarify logic in the ordering as a follow-up comment for further clarification, if in fact how things are shown to the user is the gist of your question @joshuathayer. |
Use types-redis<4, drop cryptography and other dev dependencies
In #34 we have dummy messages in the conversation view for now. We should add logic to fetch messages (both replies from journalists and messages from sources), decrypt them, and store the decrypted messages on disk.
Note: this has a dependency on the decryption logic in securedrop-workstation repo (this decryption occurs in another VM), so needs to be done in Qubes once we have the scaffolding in place to test, i.e. #161 is implemented. Then we'll need to provide mocks / dummy data for people developing in non-Qubes OSes
The text was updated successfully, but these errors were encountered: