Notification digest feature for recipients

[evilaliv3]

Various adopters reported me back that in their work they would really benefit of a digest for notifications.

The collected requirements that need now to be discussed and simplified are:

• the possibility to enable the digest (per recipient)
• the possiblity to configure the period of the digest (per recipient; reasonable setting in hours)
• the possibility to selectively mark what should bypass the digest and scatter an immediate mail (e.g. new submissions)

\cc @NSkelsey @marceloomens @infosquatter @fpietrosanti

[NSkelsey]

@evilaliv3 Will this digest be sent in cleartext?

I think a good trade-off is to only send encrypted digests to receivers who have configured a PGP key. This assumes receivers use their PGP key for email and decrypting docs, but it is a good incentive to get journalists to use the right tools ;-)

[evilaliv3]

I got you point and i'm for it; anyhow I think that for now, t offer a framework capability the digest feature should by design, as other single email, be agnostic of the delivering mechanism.

Eventually what we can do for the future is to have different default templates as in past that in case PGP is used would allow to deliver more information inside the email.

[NSkelsey]

There are two ways I can see this feature being implemented.

1) Submission Content Summarized

Here a notification digest, really means a structured email with content pulled from submissions the recipient has received. Each listed submission could have some fields extracted and included in the email to include rich content.

While this is a feature typical of social media new aggregators, it is something we can put together easily. The scaffolding is all there. I actually think that the digest would look something like this:

Naturally this setup shares quite a bit of information about the platform to anyone who can observe the data in transit to the mailbox or to anyone who can view the recipient's mailbox.

2) Summary with no Content

In this setup, an email would be sent every time period about new events that have occurred within the platform. This would look a lot like Facebook's emails "A lot has happened sense you last logged in Frank." The summary would contain pretty much just this:

Warning 2 submissions are about to expire!
You have 5 new submissions.
You have 3 new files attached to the "West Berlin" tagged submissions.
You have 2 new comments.

[marceloomens]

In my ideal world we'd have digest notifications as in Nick's example (1) Submission content summarized, for receivers with a PGP key installed, with a fallback option as in (2) Summary with no content, for receivers without a PGP key.

I completely agree with @NSkelsey that such a feature would be an incentive to journalists to use the right tools (i.e. set-up encrypted email).

Even in the case of encrypted email (scenario 1), you might use the subject line to communicate the most important bit of "non-content" in plain text, i.e.

Subject: "GL-node 6 april '16: Warning, 2 submissions are about to expire!

--- PGP ENCRYPTED CONTENT ---

XYZ

-- END PGP ENCRYTPED CONTENT ---

In the case of Publeaks NL we have all receivers set up with PGP keys but almost none of them also use the key to send and receive encrypted e-mail. This feature would allow me to start rolling out PGP email to Publeaks receivers, but at the same time it would be useful (if possible) for receivers to be able to 'opt-out' of encrypted email even when they have a PGP key installed. In this way everybody gets use out of this notification digest system. Does that make sense?

I'd also like for @martijndebie and @olafvm to comment. Both are recipients here in the Netherlands.

[evilaliv3]

Thanks @marceloomens for the so valuable feedback!

I agree on all what proposed by you and @NSkelsey; the only concern here is that you may be misunderstunding what we can effectively put as content of the email. In fact soon there will be finally in place the client-side encryption so that the node would not have the content in plaintext so that the information that could go in the email is only on some metadata that will remain unencrypted (and that by research we will tacle day by day at protecting i hope)

• context of the submission
• number of comments
• number of files
• dates
• summary of the interactions. in term of numbers/timings but still what could be eventually be offered by analisis on the metadata that technically would not possible to encrypt.

@fpietrosanti what is your thinking in relation to client-side encryption?

[fpietrosanti]

Well, the only way to share the "content" (whereby we are speaking about "submission fields" and "additional information" and "messages") via PGP-encrypted email is to have a NON-json/pure-text copy of the "content being submitted", encrypted client-side, with all the PGP keys configured for the recipients in the notifications. Then, when the notification schedule make his cycle, send in the notification email a bunch of attachments, PGP encrypted with proper mime-type set, so that will be all-decrypted in-line by the email-client and displayed sequentially. But, that's not the Digest, it's the feature described at #1286 that require further research anyway, even without any client-side encryption.

[marceloomens]

Well, off course I'm sensitive to the fact that this may not be possible when end-to-end encryption is available, but then I don't know how far advanced you are with the implementation thereof.

[evilaliv3]

@marceloomens the end2end encryption remains the main goal so we have to keep in mind that and not implement something that could not be compatible. We want to make it happen as soon as possible and we cannot introduce something that adopters would start use and will block us to remove it later :(

@fpietrosanti i agree with you that the digest should be considered indipendently; but the digest will make use only of what available in plaintext. i do not condider interesting encrypting separate payloads that would be then sent encrypted separately as it will be more difficult of the issue that @marceloomens would like to have solved that is:

1. the receiver has all in the email summarized (and different encrypted files won't allow to summarize anything)
2. make it easier for the recipient to access material (and differen encrypted attached files won't allow that)

@marceloomens do you confirm this?

[fpietrosanti]

@evilaliv3 having multiple encrypted payloads to be sent separately as attachments may work, because attachment with content-type text/plain are usually visualized in email client as part of the email flow. Probably OpenPGP/MIME allow to do so, but it do require some testing more sophisticated than what i've done on #1286 to confirm if it's a viable solution

[evilaliv3]

may work with solving 1. not for solving 2.; e.g. does not allow contents to be summarized.

when bullets points exists in an argumentation by someone, answering separately helps the discussion to move forward.

[fpietrosanti]

@evilaliv3 My thought is that it "could" fix both 1. and 2. IF it works, because IF multiple encrypted attachment files of content-type text/plain are visualized as part of the email in a nested MIME objects, then the end-user experience will be "easier access for the recipient to the material". But i'm not sure, it would require testing to understand if it's doable / works, because it depends a lot on how PGP plug-in handle email client integration/decryption/visualization. MIME nesting is a nightmare and may just don't work.

[evilaliv3]

ah sorry i've versed the numbering above :). what i think is not doable is the 1 that is the content to be summarized :( for that i still think no solution exists.

[marceloomens]

In that case my suggestion would be to aim for the low-hanging fruit first, namely scenario 2 only, summary with no content.

[NSkelsey]

@marceloomens agreed. Implementing 1) seems like it would eventually just duplicate what is on the receiver's tip list in email. It is a separate issue if using the web page is too much on the recipient.

With the right design going with 2) could help us solve: #1201 #1155 #370 and #264

Additionally with some testing we could solve #190 and #139 as well.