User profiles

[sofiaritz]

Add support for setting and getting user profiles with the following information:

• Display name (35 graphemes)
• Short description (160 chars -- that's what GitHub does, seems reasonable)
  • Maybe long description? A Markdown description with a character limit of something like 1000 chars, something like GitHub's profile READMEs
• Links (up to 4)
  • Support for verified links with rel=me
  • Maybe categories (website, work, social...) that can be used by UIs to display an icon?

Both the profile and each individual field can be unset.

• I'll probably submit a PR making the db_interfaces impl return an Option when needed instead of an error before submitting the user profiles PR

Feel free to assign this to me, I'm actively working on this :)

[marcua]

Thank you for submitting this @sofiaritz ! You're now assigned and on the roadmap! :)

Display name, short description, and links sound great. Maybe see how it looks with or without a long markdown description and we can decide.

Some thoughts on links

• on the frontend you might restrict up to 4 links, but on the backend we can model it as a list of links of any length so we can modify/iterate on the specific length later
• I'm observing that GitHub also allows you to reference an organization you work for, a location, and a website distinct from your social links.

I'm excited for this! It will allow ayb to be way more social! Thank you for working on it!

[sofiaritz]

I agree with you, I won't limit the number of links in the backend, only on the frontend. About the other GitHub fields, I'll add them :)

GitHub also supports mentions, I'm thinking if we should create a Webfinger endpoint that returns something like this:

// ayb.marcua.net/.well-known/webfinger?resource=acct:[email protected]
{
    "subject": "acct:[email protected]",
    "links": [{
        "rel": "http://webfinger.net/rel/profile-page",
        "type": "text/html",
        "href": "https://aybWeb.marcua.net/u/marcua"
    }]
}

That way the UI could link @[email protected] to https://aybWeb.marcua.net/u/marcua, this would also be a small step towards federation and interoperability :)
The instance owner could configure that in ayb.toml:

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

If you think this would be useful I'll create a ticket and also start working on that :)

[marcua]

Webfinger sounds like a cool addition! :)

To keep this issue focused on profiles, I'd be open to us pursuing it in a separate issue and we can discuss some of the details there. One thing we can consider in that issue is how to manage an increasing (N=2) number of URL templates (for the registration link and the profile page link). To keep the ayb.toml small and tidy, my thought would be to have these all in one place in the ayb.toml, or even served by the aybWeb server at a .well-known-like URL, and you can implicitly determine what functionality is enabled based on which URL templates are provided. We can discuss on that other issue, and I'm excited for webfinger! :)

[sofiaritz]

in a separate issue and we can discuss some of the details there

That's the idea, I'll open an issue :)

To keep the ayb.toml small and tidy, my thought would be to have these all in one place

I think that would be confusing for new instance owners, also I don't think that a big ayb.toml file is necessarily a problem (eg. Forgejo config cheatsheet). Instance admins should have the possibility of having a small ayb.toml with some features disabled and sane defaults, but also have to possibility of customizing most of the things in their instance (webfinger config, character limits, database limits, authentication config, etc).

In the future a server configuration CLI could be created using something like inquire to simplify this process.

I do think that we should create a struct that can be easily used in the definition of the ayb.toml file that unifies and simplifies the process of template strings, I'll take care of that :)

served by the aybWeb server at a .well-known-like URL, and you can implicitly determine what functionality is enabled based

Instead of having the UIs guess by the values of templating strings, we could use something like Nodeinfo to tell the UIs which features are enabled or not (see the metadata map here: https://github.com/jhass/nodeinfo/blob/main/schemas/2.2/example.json).

---

I'm going to open the Webfinger issue, if you like the Nodeinfo idea, I'll create one for that too :)