[API] Route: /version

[kozabrada123]

Is your feature request related to a problem? Please describe.
When developing an app meant to support several different Discord API implementations, sometimes on different versions, it would be very useful to be able to easily find the software you're working with and its version.

Why? Sometimes issues only arise only on one implementation, an implementation has extra features or a bug is found in an implementation. Even after bugs are fixed administrators do not update immediately and instances still run faulty versions. Knowing if you're working with a server on an affected version means the difference between your app working and crashing.

Describe the solution you'd like
A new route along the lines of /api/version, which returns the server's software (spacebar) and its version.

A return schema may look like this:

{
  "version": "0.2.1",
  "server": "spacebar"
}

(Other server implementations could then simply change the "server" field to identify themselves)

Describe alternatives you've considered

Why .well-known is not enough

As a convention, .well-known/spacebar does exist (though not always), but that doesn't expose the server version and is only available on the base url (http://spacebar.chat/.well-known/spacebar exists, but http://old.server.spacebar.chat/.well-known/spacebar or http://old.server.spacebar.chat/api/.well-known/spacebar do not - and apps may only have the api url, not the base url)

Other viable alternatives

• Spacebar already has the route /api/ping, which could also be updated to add this version information
• the route /api/policies/instance/ could also include this information

However, adding a new route is preferable to changing an existing one - this would break existing apps relying on the old schema and new apps expecting them to have the new fields on old instances

Additional context
This was also discussed in the spacebar guild, see https://discord.com/channels/806142446094385153/806142446529806367/1289269996404473959

[TheArcaneBrony]

Seems fine to me, how does one obtain the "version"? What does one do if version info is not available?

[MathMan05]

also, I'd like if this could also have an area for features like "features":["WebRTC","Threads"] etc so I don't have to manually write code checking for that stuff lol

[kozabrada123]

Seems fine to me, how does one obtain the "version"? What does one do if version info is not available?

One version is defined in package.json, but that doesn't seem to have changed from "1.0.0" which was set 2 years ago

To get it in code you'll probably want to write it into a typescript source file with a prebuild script:

"scripts": {
    ...
    "prebuild": "node -p \"'export const SERVER_VERSION = ' + JSON.stringify(require('./package.json').version) + ';'\" > src/version.ts",
    ...
  }

There's also the version that's displayed on startup:

Which is just pre-release with the current commit hash, or Unknown (Git cannot be found)

I think ideally this route would return a semver compatible version so it can be parsed in code and evaluated as before or after a known version

[kozabrada123]

also, I'd like if this could also have an area for features like "features":["WebRTC","Threads"] etc so I don't have to manually write code checking for that stuff lol

Yeah, that would be very useful, but Im not sure if its in scope for this issue
We should either agree on a common format for communicating features / extensions, probably also the exact values for some of them, or Spacebar could have its own route and its own format for this