[messaging] Mail UIs

[Nick Badger]

This isn't directly relevant to your UI question, but:

I'd think message senders should specify if messages should be archived
> by default, or maybe even sent straight to archive, or a separate
> mailing list tool, by passing the inbox... If a recipient overrides the
> senders non-request for archival then they get to specify such
> metadata.


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.

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.

[1] https://github.com/Muterra/doc-muse

Nick Badger
https://www.ethyr.net
https://www.muterra.io
http://www.nickbadger.com
PGP fingerprint 37B9 22FC 2E47 50AA E06B 9CEC FB65 8930 46F0 333A, listed
at MIT <https://pgp.mit.edu/> and PGP <http://keyserver.pgp.com/>

On Thu, Jan 7, 2016 at 10:59 AM, Jeff Burdges <burdges at gnunet.org> wrote:

>
> Trevor mentioned the difficulty of building a nice user-interface for a
> mail reader at RWC yesterday.
>
> In the past, I've wondered if one should separate the mail receiving
> functionality from the mail archival functionality.  In other words,
> there would be two linked applications, one that reads incoming mail
> and one that accesses archived mail.
>
> I'm assuming an end-to-end encrypted mail system that's resistant to
> traffic analysis, and that does not retain messages by default, like
> Pond.
>
> I'd think message senders should specify if messages should be archived
> by default, or maybe even sent straight to archive, or a separate
> mailing list tool, by passing the inbox.  Asking that a message be
> archived asks the sender for metadata like either keywords, like
> ephemeral mailing list names, or a title.  If a recipient overrides the
> senders non-request for archival then they get to specify such
> metadata.  This metadata is preserved by replies.
>
> The question is : Can/should the interfaces be streamlined differently
> for the different activities of reading incoming mail and reviewing old
> messages?
>
> Of course, these two applications would interact rather tightly, like
> when you reply to an archived message, or send a private mail from a
> mailing list message.  It might even be that simply keeping two mail
> reader windows open with different configurations accomplishes the same
> goals better.
>
> If however there appears to be a worthwhile advantage to keeping the
> interfaces separate, then there might structural advantages in
> development where more user-interfaced developers focused on the
> archival reader did not need to worry much about security, and the more
> security conscious developers dealing with the inbox tool could
> port/copy the better user-interface decisions of the archival tool.
>
> Just thinking out loud,
> Jeff
>
>
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160107/b38a0569/attachment.html>