<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">I have restarted work on the Mesh after a short holiday. The revised architecture document should be ready in a fortnight. There is one very critical piece of infrastructure I haven't mentioned yet, the naming system. I suggest that people read the whole post before reacting rather than assuming that I am the usual sort of capitalist despot.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The Mesh is a Threshold Key Infrastructure which is basically a PKI but making use of the fact that we can split private keys into shares etc. I have tried to minimize the need for a service element and to minimize the degree to which the user needs to trust the service element. But the Mesh incorporates an asynchronous messaging capability which necessarily requires some sort of service to act as a dropbox to which messages can be posted for later collection. I call this a Mesh Service Provider.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Alice and Bob are probably capable of running their own MSPs, they have been doing crypto together for over 40 years after all. But most users won't. They are going to have to outsource their MSP provision to some third party. And I think that is completely OK, most of us outsource SMTP email service these days. What is not OK is the SMTP model where the email address is tied to the service provider so that changing email providers incurs an enormous switching cost.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The current corporate model for Internet services is to try to make everything sticky. I don't want that even though one of the businesses I have started is going to be an MSP. The Mesh is all about putting the user in control. User's can't be in control if they are chained to the service provider.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So what we need is a simple registry that provides service discovery. The very simplest form of registry would be to map a UDF of a Mesh fingerprint to the service provider. So <span style="color:rgb(0,0,0);font-size:13.3333px">mb2gk-6duf5-ygyyl-jny5e -> <a href="mailto:alice@example.com">alice@example.com</a>. And we could have a few of those. But that wouldn't last long because users would much much rather just be something like @alice.</span><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So I don't want Alice's address to be <a href="mailto:alice@example.com">alice@example.com</a>. I want her to be @Alice. And I want her to be able to use that same account and address  at cryptomesh (my MSP) or Comcast or Google, or whoever. This makes it very easy for Alice to be her own MSP if she chooses, it isn't a lifetime commitment.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is the point at which someone fisking the thread will write, 'but Phill, you don't understand, running a naming system is really hard, just look at ICANN'. Yeah, like I wasn't Principal Scientist of VeriSign for a dozen years when we bought Network Solutions. This stuff is difficult and I have been lucky in the past. But meeting Tim BL was luck, joining VRSN and creating the WebPKI was not.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So if @bob wants to send a message to @alice, his MSP will lookup @alice in the registry, discover that it is currently serviced by <a href="http://example.com">example.com</a> and send the message there.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is a difficult problem if you decide to make it so. It really doesn't cost $250,000 to decide if someone should have a TLD. That is pure rent seeking. And no, I don't want to enter into discussions of why that is OK or why we should embrace an organization charging $250,000 for a registration as the operator of the successor to the WebPKI where CAs charge a few hundred dollars a year. The important point we will come back to later is that while the registry I describe would cost almost (but not quite) nothing to run, it would potentially generate a vast amount of value. People will be willing to pay significant sums for names such as @london etc, there will be trademark issues with @microsoft, etc. etc. And again, the only reason I am stating the blitheringly obvious here is the alternative is a series of comments of the form 'Phill, you ignorant slut'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">OK so the simplest record for alice would be something like:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">alice :<br></div><div class="gmail_default" style="font-size:small">    udf: <span style="color:rgb(0,0,0);font-size:13.3333px">mb2gk-6duf5-ygyyl-jny5e</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">    service: <a href="http://example.com">example.com</a></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">    registration: initial</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">And we put this all in an append only log authenticated by a Merkle Tree and sign it once a minute. But unlike in the DNS system, the registry does not provide a query service. Instead, MSPs maintain a local copy of the registry of names and use that to respond to queries from their users.</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">Getting rid of the registry query service immediately removes 99% of the cost of running the registry. It also means the system is inherently failsafe. The worst that can happen if the registry is completely destroyed is that the ability to post updates will be lost. A DDoS attack that takes out the Comcast MNS service is not going to take out Verizon. The fact that attacks cannot cause a global outage will greatly reduce the incentive. And since an attack on Comcast can only come from Comcast customers they are in a much better position to defend themselves. </span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">Since we have a DDoS resistant infrastructure, why not use it to publish delegations for DNS services as well?</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">comcast</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">    udf: </span><span style="color:rgb(0,0,0);font-size:13.3333px">MB5S-R4AJ-3FBT-7NHO-T26Z-2E6Y-WFH4</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">    dns: 68.87.72.244</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">    dns: 69.252.250.103</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style=""><font color="#000000"><span style="font-size:13.3333px">ICANN world DNS can go down now and we can still reach @alice if her MSP is comcast. Ain't that interesting?</span></font></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">At which point we should better think about the trustworthiness of the entries. Aren't we putting a lot of trust in the registry?</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">The simplest record is not the best one because we want to have authentication etc. etc. And so we are actually going to maintain two separate logs. One of which contains the data we want to query, the other of which contains the proofs.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">Every change made to a record in the registry must be supported by an assertion signed by the name holder.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">The registry signs both append only logs once a minute. Validating MSPs download both logs and check that every entry added to the log is supported by proof. If everything is OK, the validating MSP sends a token back to the registry saying 'I checked the log up to this point in time' and this is entered into the registry log.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">The net effect of this scheme is that as far as each MSP is concerned, they are the root of trust for the append only logs: Any defection by the registry will be detected. It is not possible for any of the parties to defect without their defection being visible to all unless they all collude. So we get the Blockchain type effect of preventing rollback but with a 1 minute period instead of ~10 and without the need for proof of waste.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><br></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">So now, when  Bob sends that message to @alice he can be really sure it is going to the right place, is end to end secure, etc. The only reason there might be an issue is if the name has been reassigned because of a trademark issue.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">As a practical matter, I think it is essential that a naming system meet the reasonable expectations of the users and that expectation is that @microsoft goes to Microsoft corporation not some scammy namegrabber. But @prince certainly doesn't go to Prince Sports, it goes to the artist's estate. So some legal and UI issues there. I think it fine for names to be reassigned provided that nobody USING the original name is affected and that the reassignment is completely visible. So if @wikileaks is reassigned to @fbi, anyone using the name is warned.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">There is also an IoT play here, what if we want to send a message to Alice's coffee pot? Well that is coffepot@alice.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">We can represent these names in the DNS by defining our own TLD. No, I do not feel inclined to pay ICANN's rent. One of the features of the Mesh is provisioning network configuration information. So we can tell connected devices which DNS service to use and that can map @alice to alice.mm-- which is not a valid TLD ICANN can assign.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">Oh look, we have a new bit of censorship resistant technology. All she needs is an authoritative DNS service and Alice can publish her stuff at <a href="https://www.alice.mm--/">https://www.alice.mm--/</a> and that will be stable regardless of what ICANN does. And her coffee pot can offer status info at <a href="https://coffeepot.alice.mm--/">https://coffeepot.alice.mm--/</a> under a certificate that is signed under the root of trust </span></font>mb2gk-6duf5-ygyyl-jny5e.</div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><br></div><div class="gmail_default">No, I am not putting the CAs out of business with this. But I am eliminating the need for LetsEncrypt and NSA corrupted botches like DANE/TLSA. This will replace DV certs over time but the need for EV will be just as important because creating a trust relationship requires a source of accountability. And besides that, the Mesh creates more interesting opportunities for CAs as Mesh applications will present logotype information to the user. </div><div class="gmail_default"><br></div><div class="gmail_default"><br></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">OK so what about the business model for the registry? I expect this to cost about $2 million a year to run it properly (no I am not spending that on the prototype). We could go round with a begging bowl but look where that got us with the NSF.</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px">I think it much better just to charge for the names. But the incremental cost of servicing a name is close to $0 and the cost of maintaining a name IS $0.000000/year. There is no need for renewal fees. Names are for life (unless sold or reassigned).</span></div><div class="gmail_default" style="font-size:small"><span style="color:rgb(0,0,0);font-size:13.3333px"><br></span></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">So one business model would be to charge $0.10 for a name with up to 50 change of service registrations included. Which is fine and the model I would like to go with for names of 8 characters or more.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">But why leave money on the table? My problem with the ICANN model isn't just that they are corrupt rent seekers buying themselves bigger yachts, it is the fact that (almost) none of the money ends up going to people who are contributing to the development of Internet technology. It is just absorbed by a clique of rent seekers and lawyers.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">So what if we charged more for the shorter names that are going to be in high demand and used the revenues to fund development of new Mesh technology? The charges would increase exponentially as the name became shorter. $100 for a 7 letter name, $1,000 for six, all the way up to $10 million for single letter names. </span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">This approach has the important advantage of creating a disincentive for namegrabers. Nobody is going to spend the $100,000 needed to namegrab @ibm knowing that it will be reassigned. </span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">The Mesh is a binary prospect. I don't think it can be a modest success. Either it succeeds on global scale or not at all. So the registry is potentially worth of the order of a VeriSign Inc. And so the only way that it can possibly be allowed to succeed is as a form of public goods. Which is fine, its not like I personally need the cash (and I will have the MSP to unload). The only thing that can be done with wealth on that scale is to hoard it (pointless), give it away or spend it on parties. What I propose to do here is essentially short circuit the process so that the registry is run by the Mesh foundation which spends a large proportion of it supporting the developer community with consulting contracts, salaries and conferences in really nice places. Think of it as the equivalent of making club in the sales dept.</span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">I see this as a win-win-win for everyone apart from (some of) the incumbents. </span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">Right now the IoT space is being dominated by five major players all trying to establish themselves as the monopolist. And at least two of those are starting to realize that the eventual monopolist isn't going to be them. The Mesh provides an open playing field. </span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px"><br></span></font></div><div class="gmail_default"><font color="#000000"><span style="font-size:13.3333px">So in case the point of this message is not clear, I think I am close to done with the design of the Mesh. I am going to need a vast number of people to deploy it, many of whom are here. I don't have the funds to hire everyone on contract but if we are successful there should be a foundation that has the means to 'do the right thing' for everyone involved, including the folk at Comodo who originally financed this work.</span></font></div></div></div></div></div></div></div></div>