search

glitch-soc / mastodon

A glitchy but lovable microblogging server
https://glitch-soc.github.io/docs/
GNU Affero General Public License v3.0
690 stars 184 forks source link

nodeinfo reports software name property as "mastodon" #2582

Open nikclayton opened 8 months ago

nikclayton commented 8 months ago

Steps to reproduce the problem

  1. Fetch the nodeinfo for a glitch-soc server (by following a href entry at .well-known/nodeinfo)

Expected behaviour

The software.name property should indicate this is the glitch-soc fork

Actual behaviour

There is a glitch string in the build metadata portion of the version string

Detailed description

Hi, Pachli (https://pachli.app) author here. I'm working to improve Pachli's support for non-Mastodon servers, which led me to this.

Here's the software block from a server running Glitch:

"software": {
    "name": "mastodon",
    "version": "4.3.0-alpha.0+glitch"
}

This is a problem for a few reasons.

1. This makes things more difficult for any client trying to determine the server it's talking to, as it has to inspect the version as well as the name.

2. This is inconsistent with other Fediverse software that implements the Mastodon API, whether it's direct Mastodon forks like Hometown and Fedibird (which set the name to hometown and fedibird respectively), or non-forks like Pleroma, Friendica, and GoToSocial.

3. The nodeinfo schema definition (https://github.com/jhass/nodeinfo/blob/main/schemas/2.1/schema.json) describes the software.name property as "The canonical name of this server software.", and I don't think "mastodon" is the canonical name of this fork.

4. For something that looks like a Semantic Version (https://semver.org) putting this here in the version is also wrong.

Build metadata MAY be denoted by appending a plus sign and a series of dot separated identifiers immediately following the patch or pre-release version. Identifiers MUST comprise only ASCII alphanumerics and hyphens [0-9A-Za-z-]. Identifiers MUST NOT be empty. Build metadata MUST be ignored when determining version precedence. Thus two versions that differ only in the build metadata, have the same precedence. Examples: 1.0.0-alpha+001, 1.0.0+20130313144700, 1.0.0-beta+exp.sha.5114f85, 1.0.0+21AF26D3----117B344092BD.

I think it's a stretch to consider "glitch" to be "build metadata"

Please consider changing the software.name property to clearly indicate this is the glitch-soc fork (note that only a-z, 0-9, and - are valid characters in the name). Perhaps using the org + repository would suffice, so glitch-soc-mastodon?

Mastodon instance

No response

Mastodon version

No response

Technical details

No response

ClearlyClaire commented 8 months ago

Hi. I don't think replacing mastodon with glitch-soc here is very helpful, considering how close glitch-soc is to upstream Mastodon. If you are interested in supporting individual features that glitch-soc implements on top of Mastodon, there are usually better discovery mechanisms.

nightpool commented 8 months ago

nodeinfo is an anti pattern and clients shouldn't rely on it for anything except aggregated statistics.

nikclayton commented 8 months ago

nodeinfo is an anti pattern and clients shouldn't rely on it for anything except aggregated statistics.

Why do you think it's an anti-pattern? A single defined endpoint with a discoverable, extensible, versioned schema is hugely useful to clients.

nikclayton commented 8 months ago

considering how close glitch-soc is to upstream Mastodon.

"close" doesn't mean it's Mastodon though.

Spot the odd one out -- https://github.com/pachli/pachli-android/blob/54d788831699b549f49fbc8023de1a4f2643b0ac/core/network/src/main/kotlin/app/pachli/core/network/Server.kt#L322-L341

Unless all software that parses the nodeinfo does that glitch is going to be missed. I note, for example, that glitch doesn't show up in the stats at https://fediverse.observer/ or https://fedidb.org,