Webfinger support

[sofiaritz]

Right now UIs have no way to link users on other instances without some magic guessing. Implementing Webfinger would allow users to mention users on any Webfinger-compliant service (ayb, Mastodon, Akkoma, etc.) and link to its profile page.

In the future, this could also be used to link to the entity retrieval endpoint with the addition of a link of type application/aybEntity+json.

This would be configured in the ayb.toml with something like this:

[webfinger]
enabled = true
profile_page = "https://aybWeb.marcua.net/u/{entity}"

Also, feel free to assign this to me :)

[marcua]

This is great! Before we start it, there are two things to consider

The use case

While in theory adding webfinger support sounds good, could you describe the user experience a little more? Specifically I'm wondering where and how ayb users might mention other services, and where users on other services might mention ayb users?

How to configure it

I did a bad job of describing it in #237, but while I'm not opposed to adding this stuff to configuration files, I'm trying to think of a way to standardize it. I can think of two approaches

Approach 1: One section of ayb.toml

We could have a web section of ayb.toml where all configuration will go. For example

[web]
server_url = "https://aybWeb.sofiaritz.com/some/prefix/"
profile_path = "u/{entity}"
registration_confirm_path = "register/confirm/{token}"

The benefit of this approach is all of the web frontend related stuff is in one section, rather than having URLs in several sections. (Note that we'd have to change how registration confirmation works a little bit, since you'd only have a registration URL and not other content, which the email logic would have to handle. That seems fine given the other benefits of standardization.)

Approach 2: Have the web frontend define its paths

The ayb server shouldn't be responsible for knowing specific paths on a remote server, and the server is better-suited for providing its paths. So ayb could have a simpler configuration like

[web]
server_url = "https://aybWeb.sofiaritz.com/"

And the aybWeb server could provide a file with its routes/paths. This could be in an OpenAPI spec or a way simpler format. For example: https://aybWeb.sofiaritz.com/.well-known/ayb.json

{
  "paths": {
    "profile_path": "/some/prefix/u/{entity}"
    "registration_confirm_path": "/some/prefix/register/confirm/{token}"
  }
}

The benefit of this approach is that the responsibility lies with the web frontend for communicating its paths, which it is better suited to doing. I think it adds a bit of complexity at this stage though, and requires some bootstrapping logic web an ayb server first starts to query the web frontend, so perhaps Approach 1 is better in its simplicity.

[sofiaritz]

could you describe the user experience a little more

The process is the following:

1. Alice (@alice@ayb1.host) edits her description and adds the following: @bob@ayb2.host.
2. ayb1.host stores the description without doing anything special.
3. Mallory (@mallory@ayb1.host) goes to Alice's profile.
4. Mallory's frontend sees that the description contains a mention (@bob@ayb2.host).
5. Mallory's frontend performs a Webfinger request to ayb2.host (https://ayb2.host/.well-known/webfinger?resource=acct:bob@ayb2.host).
6. ayb2.host returns the response with the link to the profile page.
7. Mallory's frontend adds the link (<a href="...">@bob@ayb2.host</a>).
8. Mallory clicks the link and he's sent to Bob's profile page.

From the perspective of the user, they are just mentioning someone (adding @username@host) and the frontend links to the profile page of that user.

where and how ayb users might mention other services

Description, organization description, the organization you work for, etc. This feature is an extension of #237 to allow users to mention others. An ayb user could also say that they work for @w3c@w3c.social without W3C needing to create an account on any ayb instance :)

where users on other services might mention ayb users

I don't think that would be de facto supported right now (aside from aybWeb, of course).

About the two approaches to config, I really like the second one. I think the complexity is worth it in this case. Edit: This is how I would approach the second approach, almost the same as yours: https://git.sofiaritz.com/sofia/gists/src/branch/main/0002-ayb-config-improvement.md

[marcua]

The description was so helpful! Thank you! :)

Your approach for #2 looks good to me! I still think that, despite proposing it, it's a little overengineered, but if you're good with it then I am as well :).

[sofiaritz]

I like the second approach because ayb instance maintainers don't have to worry about changing a ton of endpoints when updating aybWeb or migrating to another ayb frontend, and also they don't have to test whether they set all of the endpoints right in the ayb.toml :)

Also, the PR is up #242 :p