Store usernames on the Also Known As stream rather than the profile

[dysbulic]

What would you like to be added?

Currently, a player's username (the slug used to identify them in /player/<username>) is stored as a string in the extended profile.

While it is a part of a player's profile, it is possible that they will have different usernames on different sites, so a more flexible location to store it is in the Also Known As stream.

The AKA stream relies on a claim url which displays the user's DID within the site in question. There are also attestations which are JWT-encoded Verifiable Credentials issued by parties which have verified that the given claim URL is valid.

For MetaGame, we could create a URL that exists solely to return the DID associated with a username. Something like https://my.metagame.wtf/api/player/<username>/did.json.

It could return { did: <DID> } for the DID associated with the ETH address which username is an alias for. It should not be necessary to store the DID, but rather to look it up using a CAIP-10 link. If the username doesn't exist, return a 404. If there is no DID associated with the ETH address, return a 500 error.

Why is this needed?

The current mechanism for storing username's is brittle. Currently, the player sets their username in their profile and it is read by the cache. If it already exists, it causes a uniqueness exception in the profile table. When that exception is caught, the last five characters of their DID is appended to the name and the save is retried.

There is a check when they are setting their username that it doesn't already exist. It is possible though, either through malicious code or a race condition, that two players would set the same username. By switching to a system where the username is going to the server and being saved into Ceramic after it is set, it should eliminate this possibility and make for a cleaner system.

The username could remain in the extended profile as their preferred username. The formatting restrictions still need to be relaxed, see #1176.