OK so how I plan to introduce portable email addresses:
Step 1: Alice creates a Mesh profile
[This does not have to be based on the Mesh but it isn't exactly a coincidence that the Mesh provides exactly the set of facilities required]
A Mesh profile is a personal PKI with a hierarchy of keys that allow Alice to manage provisioning of cryptographic keys through a user experience that presents this as managing the connection of her devices to her personal Mesh.
A Mesh profile has a fingerprint which is the UDF presentation of the SHA-2-512 hash of the root signing key:
MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
Step 2: Alice creates one or more contact assertions
A Mesh contact assertion contains all the information in an iCard but with the important difference that it is signed under a key that provides a validation chain up to Alice's root signing key.
The contact assertion contains entries for all Alice's information she wants to disclose to the people she shares the contact entry with. So:
UDF: MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
SMTP: alice@xxxxxxxxxxx
MeshService: example.com
OpenPGP: <PGP public key>
S/MIME: <S/MIME certs>
SSH: <SSH keypair>
Signal: <identifier>/<public key>
ContactUpdate: mcu:MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
Leaving aside the passive aggressive threat to reverse engineer someone's open source walled garden, the important part is the last. The contact assertion can provide instructions on how to get updates. So when Alice sheares a Mesh contact with a person, it isn't just that a static business card she is sharing, it is a dynamic resource.
So note that I have achieved email address portability without introducing callsigns. And those don't actually come for quite a while either.
Step 3: Alice shares contact information through various modalities
The strongest contact binding is arguably Alice and Bob meet together and bump phones. Currently I have a QR protocol for this. Except that the scanning side is not yet functional because it is blocked on that functionality becoming available in MAUI.
We can also imagine modalities where Alice and Bob bump phones via Bluetooth.
The code also provides a mechanism that allows Alice to exchange contact information through Mesh messaging.
Contact exchange actually comprises two separate functions:
1) The recipient obtains the permission to contact Alice
2) Alice grants authorization to the recipient to make use of specific messaging modalities.
Mesh Messaging modalities do not currently include what is thought of as 'mail messaging', the messages are limited to 32KB. But it does support contact exchange, group membership invites and 2 factor authentication. Right now I am adding invoicing, payment and chat messaging exchanges. Adding you to my contacts catalog does not mean I am giving you permission to invoice me.
The big difference between Mesh Messaging an SMTP is that every inbound message is subject to access control.
OK, so why introduce callsigns at all?
Callsigns are simply a consequence of the need to allow Alice to switch her Mesh Service Provider in the case where they are not willing to cooperate by participating in forwarding.
To make this work, Alice needs to register her contact with a service that provides the forwarding capability. So this initially publishes:
UDF: MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
MeshService: example.com
Alice moves to example.net and pushes out a new assertion to the forwarding service:
UDF: MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
MeshService: example.net
This is not just a forwarding service for her Mesh account though. Alice can issue a new contact assertion updating her SMTP email address as well.
So the real value of Mesh Contact assertions is that they are dynamic and provide portability for all contact information by means of any protocol.
There is only one small problem with the scheme so far and that is that the forwarder does not have a business model. I am currently putting a significant amount of funding into the Mesh but keeping a service running in perpetuity at six figures a year would require a significant endowment and if the system took off, the scheme will require more than six figures to run.
So looking at what it takes to run the forwarding service right, I worked out that I could turn it into a naming/discovery system by allowing registrations of the form:
UDF: MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
MeshService: example.com
Callsign: @Alice
Besides providing a funding model for the Mesh Foundation, Callsigns also solve the problem of how Bob can give Alice's contact information to Carol over the telephone, how Alice can put her contact address on papers, etc. etc. Callsigns can be chosen for memorability but fingerprints of public keys really cannot.
Now to be fair, only a small number of people can have callsigns as short as @Alice. So @Alice_Lastname is probably a more representative approach. And as people know, I plan to sell short names at a premium to fund the foundation.
Issues I glossed over
OK so I have glossed over a heck of a lot of issues here. What happens if Mallet puts Alice's SMTP email in his own contact assertion? What happens during a service transition where senders may be using a 'stale' contact address?
I do have answers, some involve the word 'Bloom' and 'filter'. This is not my first rodeo, I have spent 30 years making other people's designs work a lot better, I am aware of these issues.
