Support exclusive lists with GoToSocial 0.17

[graue]

Fixes #808: supports exclusive lists with GoToSocial 0.17+.

Unlike some other server types, GTS does not use version strings that pretend to be Mastodon (for example, Pixelfed's version string of "3.5.3 (compatible; Pixelfed 0.12.3)". Instead, to detect that the server is GTS, we must use NodeInfo. I've added support for this ~~and rewritten the feature detection to use it~~.

Note that for Mastodon <4.3 (all current stable releases of Mastodon), the NodeInfo request will fail due to mastodon/mastodon#23135, so we'll fall back to the existing behavior. Mastodon 4.3 fixes this. For other server software, this will allow for more accurate checking of feature availability.

[cheeaun]

Honestly, this changes too many things at once, which makes it hard for me to review.

Few notes:

• Could be simplified by just introducing @gotosocial/list-exclusive.
• @mastodon/list-exclusive': [['mastodon', '>=4.2'], ['gotosocial', '>=0.17']], looks confusing to me, thus the point above.
• versionSatisfies(software, version, [softwareSpec, versionSpec]) is kinda unreadable to me
• I'll still prefer that current implementation is untouched and add nodeinfo check only for platforms that don't add their own user agent with Mastodon's, for now. Try not to over-engineer this as there could be many more platforms in the future that might do different things, especially learning from the history of browser user agent sniffing 🙈

[graue]

Thanks, yeah, that part could definitely be written better. I can take a second pass on readability and split it into multiple commits, although it also sounds like you don't like this approach at all...

Could be simplified by just introducing @gotosocial/list-exclusive.

I thought you might prefer only to have to check one flag at the point where the feature is implemented. This could one day also become @akkoma/list-exclusive, @pixelfed/list-exclusive...

I'll still prefer that current implementation is untouched and add nodeinfo check only for platforms that don't add their own user agent with Mastodon's, for now.

The issue here is, without getting the nodeinfo, Phanpy doesn't know it's a platform that doesn't add its own user agent with Mastodon's. Unless the code did something like assume that a version >=3 is Mastodon and <3 is GTS, but that doesn't seem very future-proof.

Nodeinfo has become a widely used standard, with this list of implementations including every kind of server Phanpy has issues about (except one, you have an issue tagged Takahe which isn't in the list but I checked and it also supports nodeinfo).

[graue]

All right, here's a smaller version of the change. It feels a bit less future-proof to me than what I was trying to do, but I admit my implementation was awkward. Perhaps if projects start using the NodeInfo more heavily to communicate their capabilities, this could be revisited later.

[graue]

@cheeaun, any thoughts on my revised version of this based on your feedback?

For what it's worth (side note...), with Mastodon 4.3 out now, the nodeInfo API will become almost universally supported as servers upgrade.

[graue]

Rebased and addressed feedback. Hopefully this will do the trick for you!

(Note: the line treating Hometown as Mastodon future-proofs against a Mastodon 4.3-based release of Hometown, in which the node info API will start working and setting 'hometown' as the softwareName.)

[graue]

When you get a chance, can you advise me on if you still think this needs changing, and my questions above? Thanks!

[cheeaun]

@graue sorry, progress has been unfortunately very slow on my side. Looks good so far, is it possible to resolve the conflicts?

[graue]

I'm a bit confused about how the .po files are generated or what they're supposed to contain. How do you recommend fixing the conflict? Can I just regenerate en.po from the source?

Edit: ok, I did it manually, although this would have been difficult had it been a bigger change, so I'm still interested in any advice for next time!