<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 4, 2022 at 1:59 AM Natanael <<a href="mailto:natanael.l@gmail.com">natanael.l@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den fre 4 nov. 2022 02:06Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 1, 2022 at 9:40 PM Rick Smith <<a href="mailto:me@cys.me" rel="noreferrer" target="_blank">me@cys.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Nov 1, 2022, at 1:12 AM, William Allen Simpson <<a href="mailto:william.allen.simpson@gmail.com" rel="noreferrer" target="_blank">william.allen.simpson@gmail.com</a>> wrote:<br>
> <br>
> We're talking past each other.  <br>
<br>
Correct. <br>
<br>
> This is a usability issue.<br>
<br>
I’d say it’s a threat issue. If you perceive no threat when plaintext resides on a third party server, then you are correct for that situation: it is entirely a usability issue.<br></blockquote><div><br></div><div><br></div><div style="font-size:small">OK so I am going backwards and forwards on this because I have this end-to-end secure platform that was originally designed to support end-to-end secure social media and a James Bond villain has just bought out my favorite social media platform.</div><div style="font-size:small"><br></div><div style="font-size:small">So of course, end-to-end secure EVERYTHING:</div><div style="font-size:small"><br></div><div style="font-size:small"><a href="https://www.ietf.org/archive/id/draft-hallambaker-everything-00.html" rel="noreferrer" target="_blank">https://www.ietf.org/archive/id/draft-hallambaker-everything-00.html</a></div><div><br></div><div><div style="font-size:small">But, but...</div><div style="font-size:small"><br></div><div style="font-size:small">In order to build a user base, the application has to provide backwards compatibility so people can use one app to interact with Mastodon, Twitter and EVERYTHING. And that means that there will be encrypted and public forums through one tool.</div><div style="font-size:small"><br></div><div style="font-size:small">And even if it is just EVERYTHING, there will be completely public feeds on it and so there will be red and black merged.</div><div style="font-size:small"><br></div><div style="font-size:small">I am thinking that the more sustainable approach is one app for red and black social media but with distinctive UI chrome to identify which mode you are in. Something like the Black border for InPrivate window in Edge/Chrome.</div></div></div></div></div></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I have plenty of ideas on the UX part of this. There's numerous concepts already in use in apps that have similar concerns, like "vaults" which needs an extra PIN to unlock, different backgrounds on messages marked sensitive, etc. </div></div></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">I am thinking different backgrounds / window frames with user ability to choose.</div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto">If you for example look at the MS Teams documentation for GDPR and other legal compliance features, the sensitivity of data of different types can vary a lot and you might have retention requirements for one channel and deletion requirements for another channel and strict requirements to not mix the two (which might be enforced by filters/alerts on different types of customer data).</div><div dir="auto"><br></div><div dir="auto">A universal solution needs to support defining many different types of channels / rooms / interfaces with different access controls and UX and retention / deletion policies. </div><div dir="auto"><br></div><div dir="auto">Slightly off topic, it might just be a good idea to treat chats / asynchronous inboxes / collaborative document editing as different sides of the same coin, since it's all just different ways to express ideas over a network. For example, I've already mentioned an idea of a messenger built on top of a distributed database with document editing, which would allow you to do things such as link ephemeral chats with persistent documents on which you record and edit and organize quotes from the conversation which you want to keep. </div></div></blockquote><div><br></div><div class="gmail_default" style="font-size:small">That is exactly what my proposal is proposing. The only difference between asynchronous and synchronous is the use of a presence service as opposed to a mailbox.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">As LISP folk know, lists are a powerful base structure, can use them to represent pretty much anything. Blockchain is simply an append only log with some structured cryptography. Mesh DARE simply goes one stage further and adds incremental encryption to incremental authentication.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The draft mentions an annotation service where people comment on docs but collaborative editing of a doc is another obvious approach. </div></div></div>