replace alias resolution with alias web endpoints

[staltz]

Here's a big idea that needs feedback @arj03 @cryptix @hendrikpetertje.

Essentially replaces aliases like @alice@scuttlebutt.eu with alice.scuttlebutt.eu (or https://alice.scuttlebutt.eu). Removes host resolution and alias resolution algorithms, instead, there is one HTTP call to the alias endpoint, and then alias consumption is a thin verification of the endpoint's results, before doing tunnel connection.

Main document to review: https://github.com/ssb-ngi-pointer/rooms2/blob/fdb5dac6ac5552bd620fe38fc16658046b6b48dd/docs/Alias/Web%20endpoint.md, the other changes in this PR are just adapting links and adapting surrounding text to accommodate to this new concept.

[HendrikPetertje]

Looks good and its well documented!

[HendrikPetertje]

I like how you implemented the aliases. would there be problems if I was present in say both the Hermies room and the Picoroom?

[staltz]

Thanks @HendrikPetertje !

With rooms 1.0 there are currently problems with ssb-conn when you're online in 2 rooms simultaneously, like the ssb-conn scheduler gets confused (I can't remember exactly the symptoms). With rooms 2.0 I don't think this will change, but I think it's mostly ssb-conn issues.

But regarding aliases, yes it's definitely designed to support owning several aliases, and that's a good situation, because we don't want users to depend too much on one server

[staltz]

I'm gonna merge this, feedback can also be given post-merge.

[arj03]

The dedicated URL for a user is pretty neat. Like it.

[arj03]

When reading it I didn't understand what signature would be used for. But it doesn't hurt that it's there.

[staltz]

Thanks for taking a look!

When reading it I didn't understand what signature would be used for. But it doesn't hurt that it's there.

The alias owner needs to sign its alias so that the room cannot register aliases on behalf of the user.

The person visiting the web endpoint for the alias needs to see the signature to make sure that it was the alias owner who registered it, confirming that the room didn't forge the alias.

This is just a trust mitigation issue, so that people using aliases don't need to trust the room.

[arj03]

Understood, but at least that document doesn't say that the signature if checked and if so how.

[staltz]

Right, the web endpoint doc describes just the retrieval, then there is alias consumption doc which describes the signature verification, and after that's done, tunneled connection happens.

[arj03]

Perfect then :-)