Add support

[6543]

to discovering instance staff / information

close #27

[jhass]

I always like to avoid as much ambiguity as possible for clients, so I'd actually restrict the possible roles to a definitive list in the schema. Just to avoid silly things like accidentally including a space, using American vs. British English out of a habit etc. We can always extend this list quickly with a minor revision should the need arise.

I'm not sure why you introduced support as a toplevel key with contacts nested but then decided to introduce support_page at the toplevel rather than nesting it within support.

I am generally also not a big fan of alternating optional keys, that leads to less pleasant client code IME with a lot of conditionals rather than simply filtering data to what you need. So I'd suggest perhaps something like

{
  "address": "foo@example.org",
  "type": "email", // account, website, ...
  "purpose": "support" // security, abuse, ...
}

for the contact items.

[6543]

I let the role undefined as there are just to many you can think of. for wrong formation we could just add a regex that enforce all lowercase and no white-space etc ...

[6543]

firefish has:

"metadata": {
  "maintainer": {
    "name": "Some Name",
    "email": "info@example.social"
  },
  "tosUrl": "https://example.social/@admin/pages/tos",
...

-> https://codeberg.org/thefederationinfo/nodeinfo_metadata_survey

so purpose can also be terms-of-service ...

also code-of-conduct reports are a thing ...