<div dir="ltr">This isn't directly relevant to your UI question, but:<br><div><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">I'd think message senders should specify if messages should be archived<br>
by default, or maybe even sent straight to archive, or a separate<br>
mailing list tool, by passing the inbox... If a recipient overrides the<br>
senders non-request for archival then they get to specify such<br>
metadata.</blockquote><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not especially fond of the origin having strong control over recipients; I think it's an inappropriate reduction in the recipient's agency. Plus, it's really difficult to enforce in practice: look at how much of a problem Snapchat has had with screenshots. Once you've shared something, the cat's out of the bag, and from my point of view, instead of trying to rely upon concrete "do this / don't do this" rules (or even suggestions) created by the app UI, I'd much rather just force people to make explicit the social understanding behind that -- for example, to just straight up say "please don't share this" or "please don't save this". Otherwise you run into massive cultural localization problems, and just a mess of different things.<br></div><div class="gmail_extra"><br>Where this gets more interesting is when you're talking online data storage. The approach I'm fond of for this (and that I'm currently using [1]) is a kind of cooperative name binding. You use two primitives: the objects themselves, and the bindings. When an object has no remaining bindings, it gets garbage collected. The sender uploads an object, along with a binding, and delivers the object to recipients. The recipients can then bind to the object as well, but the hash of their public keys is included in the binding, so if the sender wants to force object deletion, s/he can pursue social/legal/etc means to force debinding. I personally think it's a nice compromise between sender and recipient agency -- but then again, I also have skin in the game. It does, however, create some interesting social pressures surrounding the public metadata link created between sender and recipient, but that's too far along the tangent to be appropriate here.<br><br>[1] <a href="https://github.com/Muterra/doc-muse">https://github.com/Muterra/doc-muse</a><br clear="all"></div><div class="gmail_extra"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br>Nick Badger<br></div><div><a href="https://www.ethyr.net" target="_blank">https://www.ethyr.net</a><br></div><div><a href="https://www.muterra.io" target="_blank">https://www.muterra.io</a><br></div><div dir="ltr"><div><a href="http://www.nickbadger.com" target="_blank">http://www.nickbadger.com</a><br><span><font size="1">PGP fingerprint 37B9 22FC 2E47 50AA E06B 9CEC FB65 8930 46F0 333A, listed at <a href="https://pgp.mit.edu/" target="_blank">MIT</a> and <a href="http://keyserver.pgp.com/" target="_blank">PGP</a></font></span><br></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Jan 7, 2016 at 10:59 AM, Jeff Burdges <span dir="ltr"><<a href="mailto:burdges@gnunet.org" target="_blank">burdges@gnunet.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Trevor mentioned the difficulty of building a nice user-interface for a<br>
mail reader at RWC yesterday.<br>
<br>
In the past, I've wondered if one should separate the mail receiving<br>
functionality from the mail archival functionality.  In other words,<br>
there would be two linked applications, one that reads incoming mail<br>
and one that accesses archived mail.<br>
<br>
I'm assuming an end-to-end encrypted mail system that's resistant to<br>
traffic analysis, and that does not retain messages by default, like<br>
Pond.<br>
<br>
I'd think message senders should specify if messages should be archived<br>
by default, or maybe even sent straight to archive, or a separate<br>
mailing list tool, by passing the inbox.  Asking that a message be<br>
archived asks the sender for metadata like either keywords, like<br>
ephemeral mailing list names, or a title.  If a recipient overrides the<br>
senders non-request for archival then they get to specify such<br>
metadata.  This metadata is preserved by replies.<br>
<br>
The question is : Can/should the interfaces be streamlined differently<br>
for the different activities of reading incoming mail and reviewing old<br>
messages?<br>
<br>
Of course, these two applications would interact rather tightly, like<br>
when you reply to an archived message, or send a private mail from a<br>
mailing list message.  It might even be that simply keeping two mail<br>
reader windows open with different configurations accomplishes the same<br>
goals better.<br>
<br>
If however there appears to be a worthwhile advantage to keeping the<br>
interfaces separate, then there might structural advantages in<br>
development where more user-interfaced developers focused on the<br>
archival reader did not need to worry much about security, and the more<br>
security conscious developers dealing with the inbox tool could<br>
port/copy the better user-interface decisions of the archival tool.<br>
<br>
Just thinking out loud,<br>
Jeff<br>
<br>
<br>_______________________________________________<br>
Messaging mailing list<br>
<a href="mailto:Messaging@moderncrypto.org">Messaging@moderncrypto.org</a><br>
<a href="https://moderncrypto.org/mailman/listinfo/messaging" rel="noreferrer" target="_blank">https://moderncrypto.org/mailman/listinfo/messaging</a><br>
<br></blockquote></div><br></div></div></div>