Re: potable e-mail, now Trying to do too much (was Re: the introduction problem, etc.)

[Phillip Hallam-Baker <[e-mail]>]

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: [e-mail]
MeshService: example.com
OpenPGP: <PGP public key>
S/MIME: <S/MIME certs>
SSH: <SSH keypair>
Signal: <identifier>/<public key>
ContactUpdate: http://update.example.com/MDDK7-N6A72-7AJZN-OSTRX-XKS7D-JAFXI
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.