← Feed
@hallam@infosec.exchange
Post #1312442
2023-03-18 17:36 UTC
Huge progress on the Mesh last week, I have completed the plumbing for the (optional) naming infrastructure.
Forget all the talk about 'end to end' and 'decentralization'. The single biggest issue for giving ordinary Internet users control over their digital lives is giving them lifelong control over the names they use to identify themselves.
You cannot be a first citizen on Twitter or Facebook because they own your account name and can yank it away at any time they choose. Same for gmail.com.
The Mesh offers three naming alternatives.
The first is a name formed from the base32 fingerprint of your account public key. e.g. MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ.
That name is permanent and unique but it isn't routable. To make it routable, we have to add a location for the current service provider:
MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ@example.com
Now that works but is a pain in the patootie to use. So people are going to demand to use an alias. So Alice can call herself alice@example.com if her service provider is example.com and it agrees.
Now what happens if Alice changes service provider to example.net. Her impractical is easy:
MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ@example.net
But what if alice@example.net was taken? How do people find out Alice's address changed.
The answer to both problems is the callsign registry. And this is the one part of the Mesh that I cannot decentralize fully and cannot run for free at global scale. I can however make it very very cheap.
So first round was the 'change of address service'. Alice uploads a binding declaring that her new service is example.net and people can now find out where she went even if example.com refuses to help.
But for the same cost, the change of address service can issue aliases on a first come first served basis. So Alice can register @alice and that is hers for life and it is hers globally. Or at least globally among mesh service providers using the common registry.
So then we get into the political issues to do with how to make a registry and not have it turn out like ICANN's yacht fund with ridiculous fees. $10 is a weeks wages for many people. If we are going to go global, it has to be possible to get a usable name for $0.10.
So the idea is that the registry is a not for profit that funds the development of end to end secure, open applications and code. Callsigns of 9 Latin characters or more are $0.10. Callsigns that are bound to a mesh fingerprint of 24 characters or more are free. Callsigns of 8 characters or less are premium and have higher fees.
(Currently just doing Latin, will add Han, Arabic, Cyrillic, etc.as expertise becomes available).
Names can be used to retrieve a contact assertion which gives access to your address info for any application you wish to share.
One use for this would be in the developer community. Use your Mesh account to manage credentials for your SSH, OpenPGP and PKIX code signing, they are all linked to one identifier allowing traceability across the whole development surface, 'This is the GIT update Bob signed, This is Carol's executable she signed, etc. etc.'
Closing the circle here, while $0.10 isn't nothing, I can also provide DNS type functionality. A callsign binding can optionally specify a DNS server authoritative for the .m3-- domain.
This is a name you can enter into a Web browser and it will work if your DNS server recognizes the .m3-- alt-domain.
So that $0.10 is for a DNS zone for life as well.
OK so how can I promise the names will resolve forever on a one time charge? Simple, understanding where the costs lie in DNS, I have pushed them all off to your Mesh Service Provider.
Registering names is cheap.
Dealing with IPR disputes is expensive but can be entirely shifted to the disputants.
Supporting online resolution of the names is very expensive and the design of the DNS makes that especially so.
So the registry does not provide the resolution service, each Mesh Service Provider does. And that immediately removes 99% of running the resolve which is dealing with abuse from script kiddies trying to 'take down the Internet'. They can't because taking out the registry doesn't stop anything working, it just delays updates to the registrations.
So to sum up, your choices for a Mesh name are:
1) MB2GK-6DUF5-YGYYL-JNY5E-RWSHZ@example.com
2) alice@example.com
3) @alice
This really demonstrates a Zokko's triangle, there are three properties, each fails one,
1) Fails usability
2) Fails individual ownership
3) Fails 'free'
Any objections?
Replies (6)
-
@hallam@infosec.exchange @alice@infosec.exchange
Phillip, will you be presenting these ideas at #FediForum later this month?
See: https://fediforum.org/
Open ##2175076
-
@hallam@infosec.exchange @alice@infosec.exchange
Meshnames don't have to fail usability. Since they don't yet exist they can be interpreted any way we want.
I'm also unsure about using aliases/callsigns as primary keys when mostly they're just "Pretty Names".
And link-rot due to indirection is a worry as each "change of address" could result in stored URLs becoming unfetchable.
So why not invert the problem, dispense with indirection and make meshname a first-order name?
Open ##2175080
-
@hallam@infosec.exchange @alice@infosec.exchange
What does "invert the problem" mean?
Given that the DNS *has* to be involved at some level, let's eliminate indirection (alias/callsign -> domain/URL) and go straight to a readily dispersed, cheap, uncontroversial, non-yachtable, not-for-profit namespace in the DNS.
IOWs no indirection beyond a DNS lookup that works forever and relegates "Pretty Names", callsigns, aliases et al to rendered values or cross-checkable identifiers.
Open ##2175081
-
@hallam@infosec.exchange @alice@infosec.exchange
The Specifics:
1: Create a lifetime meshname=`uuidgen --m3` (pubkey fingerprints are too ephemeral over a human lifespan)
2: Register $meshname.m3-- with non-profit at $0.10pa, e.g. MB2GK.6DUF5.YGYYL.JNY5E.RWS.HZ.m3--
3: Mesh network agrees to AXFR and DNS serve 00.m3-- thru ZZ.m3-- somewhat like the pool.ntp.org model.
4: Mesh tools are meshname aware such that MB2GK.6DUF5.YGYYL.JNY5E.RWS.HZ is recognised as a magic pattern when entered into a form.
Open ##2175082
-
@hallam@infosec.exchange @alice@infosec.exchange
The Inversion:
You provide $meshname to your fediverse site.
Tools standardise on well-known locations and render https://$meshname.m3--/callsign, https://$meshname.m3--/alias, etc.
Your fediverse instance is given authority to POST content to https://$meshname.m3--
Alias verification emerges as needed - perhaps a callsign DNS RR like:
"alice.example.com. 60 IN MESHNAME $meshname"
or maybe https://example.com/$meshname
Open ##2175094
-
@hallam@infosec.exchange @alice@infosec.exchange
On day one fediverse sites render https://$meshname.m3--/alias
meshname namespace is unlimited & valueless so no yachts. It's cheap to serve by mesh and hard to stop.
URLs never rot. No "Change Of Address" service or callsign server needed.
To move ISPs: rsync web-site; update not-for-profit registrar; done.
To change alias, update https://$meshname.m3--/alias and possibly update verification callsign DNS RR in new domain.
Open ##2175095