Advertise a mastodon-compatible version in api/v1/instance

[blackle]

pleroma and pixelfed seem to do this, both report 2.7.2 plus their actual versions. partially helps with #113, though after the oauth flow the login seems to have not done anything, so something else might be wrong.

[tsmethurst]

I'm not too keen on this change because:

• it's not specified in the mastodon API what this version string should actually look like (seems like semver but apparently clients accept semver plus other strings?)
• it feels like something clients should be handling better
• it's unclear where the 2.7.2 comes from
• it seems arbitrary here why 1.1.0 is required: https://github.com/superseriousbusiness/gotosocial/issues/113#issuecomment-896122089

I get that in order to make the Mastodon API work properly, we have to do such things (and lord knows we've done plenty of them elsewhere too), but I'm finding it difficult to strike a balance between compensating for what clients expect (which is often idiosyncratic), and sticking to the mastodon API as written (which is out of date). What do you think?

[blackle]

I think that because other mastodon-client-api implementations are doing this (both pixelfed and pleroma use the exact same 2.7.2 (compatible; real_name real_version) value) it seems like the colloquial thing to do. at any rate, if a client is going to parse this version string it's going to trip up on the "v" at the start of our version number, and also will be interpreting our symver as a mastodon version which is wrong. if it sees 0.4.1, it might disable certain features that weren't implemented in mastodon 0.4.1, even though we do support those features

[tsmethurst]

I did a little bit of investigation and asking around about this one.

So firstly re: the 2.7.2 version question, nobody really seems to know why that specific number was picked. I got this reply from dansup about it: https://mastodon.social/@dansup/108921828327963390 but that was about it.

BUT I looked through the code of that python library, and 2.7.2 seems to be the moment that the library says that Application support was introduced to Mastodon, judging by this: https://github.com/halcy/Mastodon.py/blob/master/mastodon/Mastodon.py#L208 SO I guess there's some importance there?

The other thing I saw when looking through the code was this: https://github.com/halcy/Mastodon.py/blob/master/mastodon/Mastodon.py#L338-L347 So basically, library users have the choice of whether to use this version checking or not, and the default is to do so.

Aside from all that, I haven't yet seen another client library that does this kind of version checking, and since it's possible for library users to just switch off the version checking if they want, I don't think it justifies bringing that version number change along from pixelfed and pleroma. I think it would be better to make an issue or PR on brutaldon, or just ping the author and ask them to turn off the version checking, since afaik brutaldon doesn't use that version for anything (unless i'm missing something looking through the code, which is very possible).

[blackle]

I think the unfortunate state of things is if we don't format things like "2.7.2 (compatible; ourversion)," then the "version" field is practically useless for the clients, since otherwise there would be no way to determine what software the version corresponds to. we basically have a browser useragent situation where implementations have to pretend to be mastodon, because that's the only way this field has any meaning. we could make a brutaldon PR, but there's surely many other clients, possibly abandonware, using halcy's mastodon library without changing that version checking setting.

one benefit of including the software name in the version field is that it gives much more flexibility to clients, who can activate or deactivate certain features (iirc pleroma has extended the mastodon API a bit, and some clients take advantage of this) however this is a double-edged sword and bad in the long run, possibly leading to a useragent-style nightmare where we have to lie about being pleroma so clients enable some pleroma features we want to support :facepalm:

it might be best to not participate in this whole thing and just put the latest masto version as the version string. if we're trying to fool clients into thinking we're a mastodon instance, this would be the best way.

I did find the original pleroma commit that added that "2.7.2 (compatible; ourversion)" format https://git.pleroma.social/pleroma/pleroma/-/merge_requests/100

"thanks! I hate it" is a mood

seems that it was to fix tootstream support. looking at their code, it seems that they use the version number to enable/disable certain features (lists are disabled if version <2.1.0) https://github.com/magicalraccoon/tootstream/blob/develop/src/tootstream/toot.py#L127

[tsmethurst]

"thanks! I hate it" is a mood

Right???

So after reading your reply last night I was pondering this in bed for a long time. And I was grumpily thinking like 'boo abandonware boo who cares about that boo, they should update their stuff booo.' But also 'blackle is right' and 'we should try and support this stuff' and also -- overwhelmingly -- 'this whole thing is a pain in the arse.'

And then it hit me: we can just make this configurable and then instance admins can choose what they wanna do with their version string.

So I suggest we add a setting in the config (default true) called something like api-advertise-mastodon-version. When 'true', the version number for the instance will be set to the mastodon-compatible value, but just for /api/v1/instance responses, not internally or via the web interface. So rather than putting this in the type converter, it can be put somewhere in the api package.

The reason for having the setting be in a new api namespace: we might want more API things to be customizable in future, like rate limiting or allowing some endpoints to be accessed without a token etc.

For Mastodon version, I suggest we take 3.4.2 -- this is when the configuration field in instance responses was introduced, which we also support, but it's before a lot of the crap trending stuff was introduced.

What do you reckon?

[blackle]

that sounds good to me! I'll try doing this tomorrow (saturday EST)

[tsmethurst]

Hey @blackle should i close this one and you can rebase + open a new one later? Or do you wanna keep it open? Fine either way, just wanted to check :)

[blackle]

you can close it. I ran out of brain juice and can't work on it rn >.<

[tsmethurst]

I ran out of brain juice

mood!

[tsmethurst]

Closing for now per discussion above :)