<div dir="ltr"><div class="gmail_default" style="font-size:small">So, I have completed the specs for DARE: Data At Rest Encryption. There is a message format and a container format. I am now working on applying those to the design of the Mathematical Mesh in the hope I can simplify greatly.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">When I first proposed the Mesh I realized that if Alice is going to join her laptop and her phone together in some sort of personal PKI, I was going to require some form of 'postbox' service to allow messages to pass between the devices in a fluent way. It is not possible to expect two consumer devices to communicate directly as peers. It is not possible to expect a consumer to have a server. So I ended up with an untrusted cloud service to act as a dead drop.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">By 'untrusted' I mean that the cloud service has no confidential data that is not encrypted and has no control over the user's actions other than refusing service. So if I am using Google as my sole service provider and get into a row with them and they drop me, I can simply create a new account on Yahoo, synchronize my profile and continue with almost no interruption. Since my contacts all know my profile fingerprint, all I need to do is send out an (automated) contact update notice and I am back in business. They can talk to me and I can talk to them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Having developed the Mesh concept, I then started defining applications based on the Mesh capabilities and specified these as separate services. I now realize that was a mistake. Users should only have to worry about one type of service and one type of account. Separating the Mesh profiles from other types of application data does not help, it only hinders.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Here, my applications are of two basic types, one is an application that makes an existing infrastructure such as SMTP mail or SSH secure and easy to use by managing key information. The second is entirely new applications that make use of the three key cryptography I use.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So in the new approach, Alice has a Mesh profile that is hers and she controls absolutely. She can use a single Mesh profile to connect to Mesh services offered by multiple sites and create multiple accounts at a single site that are all linked to one profile. If Alice wants to connect a new device to her profile, she can use any of her accounts for this purpose. Every Mesh application service has to support the subset of messages that enable devices to be connected to a profile.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I also noticed that most of my Mesh applications consist of nothing more than synchronizing a set of discrete objects across a set of devices, for example usernames/passwords, calendar entries, contacts entries, SSH client and host descriptions, email account descriptions. In the new approach, I have a single protocol that synchronizes a 'catalog' of such objects (and updates thereof) across the devices.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Messaging applications are very similar with the important proviso that the request to append a message to a catalog comes from a third party which I may or may not wish to grant that access to. So I have a series of layered message types:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">1) Connection request</div><div class="gmail_default" style="font-size:small">2) Text only message</div><div class="gmail_default" style="font-size:small">3) Message with attachments</div><div class="gmail_default" style="font-size:small">4) Task item (calendar entry, task entry, buy this at Costco entry)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Connection requests should be short but not too short and allow just enough information to know if someone is a person I want to add.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Task items and other messages that might interrupt me are obviously going to require authorization. At minimum they have to be a contact but I suspect I will require rather more personally!</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I have not yet considered synchronous messaging but one feature that I have always wanted is 'callback when free' integrated into the system. So if I want to talk to someone, rather than set up an appointment, I ping them and if they are busy, my request goes in their queue and when we are both free, we are connected automatically.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Make sense?</div></div>