[Feature request] API extension: SOGS pubkey

[mdPlusPlus]

Hi, maintainer of sessioncommunities.online here.

We're supposing the following API extension:

• Retrieval of the SOGS public key

Currently there's no way to get the public key of a SOGS via API.
If you have access to the API of a specific SOGS, you can get all the info you need to join one or more of the present communities except for the common public key. To get that, you need to open the preview (if accessible) or rely on a third-party source (session.directory, sessioncommunities.online) to provide the key for you.

As the maintainer of one of these third-party ressources, it means we need to make additional http requests to other sites and have to parse that info to (hopefully) find the correct public key to present.
This isn't only computationally wasteful and error-prone, it's also really inconvenient for everyone using the API.
(Anecdote: In the past one SOGS operator changed their public key, which resulted in conflicting public information about which key is the correct one. This resulted in confusion and made us implement a manual workaround to override found public keys with manual known good copies. Ideally this would just be a single API request.)

Since the information clearly is available on the server, I propose to make the public key available via the API.

[majestrate]

would a /.well-known/sogs.ed25519 for a GET endpoint suffice?

[majestrate]

we can use the /capabilities endpoint to signal when something like this is enabled.

we really do need a formal RFC style pipeline for these feature adds.

[KeeJef]

In cases where the SOGS isn't using SSL wouldn't this be insecure, requesting the public key for a SOGS via an unsecured http request? It's expected that the public key be obtained out of band to secure against MITM, this seems like it would open that attack up

[mdPlusPlus]

For HTTP SOGS this problem exists anyway, since the only way to get their pubkey right now is to rely on the HTTP preview (Example: http://sog.caliban.org/r/privacy/) which can be MITM-ed, too.
Out-of-band postings of pubkeys suffer basically from the same problem as they are not signed.
At least that's my understanding of the situation.