[irq-1]

> The same key, in every app, for every recipient. Not assignable to anyone else, not revocable, not subject to suspension. Yours forever.

This is impractical and the opposite of what we want. It's a required ID to use the internet, monitored by governments, tracked by corporations, and forever unchanging.

What we need is a system that allows people to easily create new IDs, that updates contacts that people choose. Think of a contact book that sends new keys to all contacts on every change. (Contacts would need to be always online.) It could update the key used on a website or not, depending on the users choice.

Breaking tracking and required IDs means flux and churn.

[marcus_holmes]

> It's a required ID to use the internet, monitored by governments, tracked by corporations, and forever unchanging.

There are clearly two opposing requirements.

One for anonymity, where people who need to be anonymous can create an identity that is verifiably the same person each time, but not a specific, identifiable, individual. The classic example is journalistic sources.

One for trust and verification, where the identity needs to be absolutely, permanently, associated with a specific individual. Online banking is the classic example here.

I don't think the same system can be used for both.

- If we can create multiple identities without verifying the human each time, as you say "flux and churn", then the second requirement is broken - there is no link between the identity and a verifiable person so the identity can't be trusted.

- If we can't create multiple identities without verifying the human each time, then the first requirement is broken - every identity can be associated with a specific human and there's no anonymity.

We could try some hybrid system where some identities are known people, and others are pseudonymns. But that feels like two systems wedged into the same box. The hard problems of absolutely correctly identifying a human so the second system works is still not solved, and irrelevant to the first system.

You are absolutely correct that the system that identifies individuals is incredibly attractive for states and large corporations, and so incredibly dangerous for actual humans. We need to be very, very, careful with this.

[lxgr]

> What we need is a system that allows people to easily create new IDs, that updates contacts that people choose.

> Contacts would need to be always online.

That also sounds impractical.

> It's a required ID to use the internet

How does any of that follow? Having a reusable self-sovereign ID format for those scenarios where people want to share it is very different from having an authority-issued ID format that's mandatory for some interaction.

As a concrete example: I have an iMessage (CKV), Signal, WhatsApp, and GPG identity key, but I don't need to provide any of them when ordering pizza online. But what I can't do is choosing to use the same key for my same number on both e.g. Signal and iMessage to make it easier for people to switch between messengers without having to re-verify me.

A hypothetical shared key format would fix that, but would (hopefully!) still allow me to create multiple keys/identities for multiple contexts, and to not provide any persistent identity when it's not necessary.

[irq-1]

If the ID is permanent then governments will require it, because they can. If it has attestations or endorsements, governments will require a government endorsement. Think about what China, Iran or Russia would do with a permanent ID being a standard. The US, England and the EU are not immune to the same impulses.

Always online is no different than an email account or website, and the rate of change would be, at least, minutes not seconds.

[lxgr]

If governments want to do these things, they already can. Phone numbers are KYCed in many countries, for example, and many messengers mandatorily require them.

The lack of an interoperable key standard isn’t stopping them. (In fact, it’s even helping a bit by providing cover for MITM snooping)

[voxic11]

look into "sealed sender" schemes, they allow the recipient to verify the sender identity without allowing anyone else to verify the sender identity. So making use of such a scheme allows you to prevent governments or corporations from intercepting even the metadata of communications (and of course E2EE prevents intercepting the contents).

[deepsun]

> Not assignable to anyone else

I can foresee there will be valid use cases to re-assign a number (e.g. stolen, mistyped, wrongly assigned etc). One thing I learned about a real-world database for human information -- there will be a valid use case to do _anything_.