<div dir="ltr"><div dir="ltr">For the mesh to work at scale, onboarding and discovery will have to build on top of existing naming infrastructures (telephone, SMTP, banking, ...), regardless of how spammy they are.<div><br></div><div>Let assume Alice (resp. Bob) is the mesh participant that can prove possession of Alice's mesh record (public key).</div><div><div><br></div><div><div>If Bob has Alice's email contact entry named "<a href="mailto:alice@gmail.com">alice@gmail.com</a>", Bob wants to use this to discover Alice's mesh record.</div><div>If Bob has Alice's phone contact entry named "+1-617-666-1234", Bob wants to use this to discover Alice's mesh record.</div><div>If Bob knows Alice's bank account number (IBAN), he wants to use this to discover Alice's mesh record.</div><div><br></div><div>The choice of which naming to trust is given to the participant initiating discovery (Bob). This way, Alice can register her mesh record with facebook, twitter, gmail, t-mobile...</div><div></div><div><br></div><div>MSP: Operators of Naming Infrastructures:</div><div><br></div><div>There are tons of naming schemes in use out there and each of them under is the control of custodians. Gmail for <a href="mailto:alice@gmail.com">alice@gmail.com</a>, the bank for my IBAN, the telco operator for my number. Even facebook for my facebook account (DNS, ...). We call these custodians OPERATORS of naming schemes.<br></div><div><br></div><div>The custodian of each legacy naming infrastructure shall be able to adhere to the mesh network and earn money with providing onboarding and discovery services.</div><div><br></div><div>The operator of Gmail can be paid for validating that alice is the legitimate owner of <a href="mailto:alice@gmail.com">alice@gmail.com</a>.</div><div>The operator of Alice's bank account with IBAN "AD1400080001001234567890" can provide a legitimate proof that Alice is the owner of that bank account.</div><div><br></div><div>MSP: Validators of Naming Schemes:</div><div><br></div><div>Beside operators of naming infrastructures, validators can be paid to proceed with known validation schemes (even though less reliable than operators based validation):</div><div><br></div><div>- A validator can check that Bob has read access to <a href="mailto:bob@gmail.com">bob@gmail.com</a> or to +1-678-321-3454 by sending a challenge to those addresses and having Bob provide that challenge.</div><div>- A validator can check that Bob has write access to <a href="mailto:bob@gmail.com">bob@gmail.com</a> or to +1-678-321-3454 by having Bob send a given nonce to a provided address using those addresses.</div><div>- A validator can check that Alice has read access to the bank account with IBAN "AD1400080001001234567890" by transferring money to bank account (with purpose code "challenge") and have Bob alice present that challenge.</div><div>- A validator can check that Alice has write access to the bank account with IBAN "AD1400080001001234567890" by having alice transfer money to a given bank account (providing a given purpose code "none")</div></div></div><div><br></div><div>Operator/Vendor Locking</div><div><br></div><div>I am not worried about operator locking because all names to record mapping are registered in the discovery log (merkle tree). Migrating is also simple. Bob can give up <a href="mailto:bob@gmail.com">bob@gmail.com</a> or to +1-678-321-3454 without any fear. Bob simply has to have mapping invalidated in the discovery log.</div><div><br></div><div>Peer Validation of Naming Schemes (PeerPoP)</div><div><br></div><div>Beside relying on operators and validators for onboarding and discovery, participants can use peer2peer validation schemes to prove association of mesh records with given names. Alice's mesh client can wire money to Bob's bank account and provide the given nonce to Bob's mesh client as a proof the alice has write access to that bank account. This can be done as well with phones, email, Whatsapp, ... We can call this Peer2Peer Proof of Possession (PeerPoP).</div><div><br></div><div>Money is Spam Prevention</div><div><br></div><div>The best way of preventing spam in the mesh network is to have participants pay for operations they initiate. Or have them sponsored by commercial participants. A recipient of a message will always get paid for receiving the message. The MSP of the recipient can also have a share of the payment.</div><div><br></div><div>This is what we miss on today's email and telephone system. If i could get paid for receiving an email or a spam call, i won't mind them!!!</div><div><br></div><div>Privacy</div><div>I am also worried about privacy when it comes to public discovery log. I am not sure we can solve that problem. If mesh implements money based spam protection, and mesh allows participants to define the price of a message they receive, we will solve the pam problem and care less about having all naming records in the publicly available discovery log.</div><div><br></div><div>I am not worried about social inclusion as the recipient can use an acknowledge message to return money to the legitimate sender.</div><div><br></div><div>/Francis </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Sep 26, 2020 at 12:41 PM Phillip Hallam-Baker <<a href="mailto:phill@hallambaker.com">phill@hallambaker.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="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-size:small">On Sat, Sep 26, 2020 at 1:47 AM Richard Outerbridge <<a href="mailto:outer@interlog.com" target="_blank">outer@interlog.com</a>> wrote:<br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Maybe only if some chain also followed the number around through number reassignments,<div>iotw if each number had its own chain of number reassignments?</div></div></blockquote><div><br></div><div><div style="font-size:small">Here is how I would see things going.</div><div style="font-size:small"><br></div><div style="font-size:small">First off, nobody uses telephone numbers for dialing any more. They are used to establish an initial connection and then get stored in a contacts list.</div><div style="font-size:small"><br></div><div style="font-size:small">Secondly, if you build on the legacy telephone infrastructure, you are going to end up finding yourself regulated under CALEA. Not good.</div><div style="font-size:small"><br></div><div style="font-size:small">So let us imagine that parallel to the Mesh naming system, there is a Mesh telephone number tracking system. I can register my telephone number and bind it to a Mesh account. And this is authenticated and periodically re-authenticated by means of a callback. Maybe the service tracks the SS7 system to see if things have been reassigned.</div><div style="font-size:small"><br></div><div style="font-size:small">Alice has +1-617-666-1234 registered in this service and it binds to alice@service.</div><div style="font-size:small"><br></div><div style="font-size:small">So now lets imagine that Bob is using his Mesh enabled comms app to call Alice. She is not in her contacts, he dials the number on her business card +1-617-666-1234</div><div style="font-size:small"><br></div><div style="font-size:small">* Consult the telephone number registry, the name is there, use the Mesh VOIP protocol to establish an end to end secure voice call to alice@service.</div><div style="font-size:small"><br></div><div style="font-size:small">* (Optional) try other non telephone providers.</div><div style="font-size:small"><br></div><div style="font-size:small">* If not found, drop down to standard SIP based VOIP telephony (however that works) through her telephony provider. Since Alice doesn't know Bob (yet) this is likely to be a voicemail box because the legacy telephone system is so spammy these days it is dying and will soon be dead, dead, dead.</div><div style="font-size:small"><br></div><div style="font-size:small">The advantage of going through the Mesh first is of course we can then achieve end-to-end secure and have the ability to shift to a different modality (message, video) if desired. And since Alice doesn't know Bob in this use case, she can require him to perform a contact request first unless Bob has a credential from some group Alice has put in her accept policy. </div><div style="font-size:small"><br></div><div style="font-size:small"></div><div style="font-size:small">The way I see things, traditional telephone and SMTP email are dying because they are too spammy to live. And the only thing keeping them alive for now is the fact that they are the only open, interoperable game in town. If there is a viable spam free alternative that is open, it will start to acquire users and will be supported by a large number of ISPs etc. who realize that they are not going to establish themselves as the monopoly provider of the replacement system. </div></div><div><br></div></div></div></div></div></blockquote><div> </div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div>Francis Pouatcha</div><div>Technical Lead</div><div>adorsys GmbH & Co. KG</div><div><a href="https://adorsys-platform.de/solutions/" target="_blank">https://</a><a href="http://www.adorsys.com" target="_blank">www.adorsys.com</a></div></div></div></div></div></div></div></div></div></div></div>