We need to re-consider splitting users into alias & underlying opaque ID (SPEC-152)

Back when we defined rooms as split between aliases and IDs, there was a discussion over also splitting users between aliases and IDs too. At the time, the argument for doing so was "for symmetry", which didn't cut it, but we're starting to see concrete reasons why this could be a good thing to do. This bug is intended to gather together reasons to do so.

• We can use alias->ID api to also handle canonicalising case as per SYN-109 rather than SPEC-62
• We get email-style aliasing for free, allowing easy consolidation of various accounts to point at One True Account, and avoid having to support multiple accounts in clients
• We could use it for horizontal scaling, HA, and decentralising user accounts in general - replicating a single user account over multiple servers
• We could use it as the basis for a portability/account migration system.

Obviously the risks include:

• Another waste-of-time holy war over how to present aliases to users in UI as they're a many:one mapping. Needless to say, I suggest we just present them like email addresses (which are after all also many:one, effectively)
• Lots of security challenges in terms of which accounts are allowed to reside on which HSes, and how you prevent phishing attacks, and how you encrypt user data to protect them sufficiently.

If this idea went ahead, I suggest we adopt a syntax like:

@​matthew:matrix.org <-- user alias
^opaque_id:matrix.org <-- user id

I suggest using ^ as the sigil, as it doesn't escape in URLs, doesn't mean anything else, and is easily visually recognisable.

Yes, this would be a major backwards-incompatible change to the event format if we start shoving ^'s everywhere - so we need to decide to do so sooner than later if we are.

I suggest we consider using public key fingerprint as the opaque ID for the user (if this makes any sense at all).

(Imported from https://matrix.org/jira/browse/SPEC-152)

(Reported by @ara4n)

Start by reviewing the references to SPEC-152, SYN-109, and SPEC-62, then assess the proposed alias and opaque-ID model, including its security and compatibility implications. Done would require a decided direction and a sufficiently defined specification for user syntax, account mapping, and migration or backwards compatibility.