Skip to content
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

Closed
redshiftzero opened this issue Oct 17, 2018 · 3 comments
Closed

Download and decrypt messages #40

redshiftzero opened this issue Oct 17, 2018 · 3 comments

Comments

@redshiftzero
Copy link
Contributor

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

@redshiftzero
Copy link
Contributor Author

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.

@joshuathayer
Copy link
Contributor

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).

@ninavizz
Copy link
Member

ninavizz commented Nov 1, 2018

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants