@liaizon@Coffee@dansup@sexybiggetje working on this right now -- weirdly, changing the string here from "mastodon" to "hometown" and restarting all processes isn't changing the rendered nodeinfo output
@Coffee@dansup@sexybiggetje@darius is this something that would make sense to change? adding some identification that is easy to parse that makes it not lump hometown with vanilla mastodon?
@dansupHometown instances use a dual version string (hometown version)+(mastodon version), but I don't know if that is expressed in nodeinfo. I'll dig when I have some time.
@sexybiggetje@Coffee The challenge with that is distinguishing forks from upstream. There is no uniform identifier (in nodeinfo for instance endpoints), some glitch instances have `+glitch` appended to version field but I can't find any hometown instances doing that.
If you have any ideas, let me know! Working on some new api endpoints too btw :)
@sexybiggetje Well, still the closest thing to what I'm looking for so far. If only I could get at that juicy JSON they're teasing with... but that's embedded in the HTML content.
@liaizon@darius The reason for adding the fork name to the user-agent is to give a hint to the server operator, so that access from the server calling itself fedibird can be blocked by nginx and traffic can be aggregated.
@noellabo@darius (sorry for this basic question) how would one query the user agent string of a server. Or rather, how can I see what user agent is set if all I have is the domain of an instance?
@liaizon@darius Fedibird didn't choose that expression for several reasons. If you do, it may be "main+0.1", as it doesn't necessarily match the Mastodon tag release. If Mastodon has a tag release, the version of Fedibird will be updated at that time.
You can get the Mastodon version from /api/v1/instance.
@noellabo might make sense to do what @darius is doing and show the two version numbers together. So hometown has the version number listed as "3.4.0+1.0.5" so the 3.4.0 is the version of mastodon its basing off of and 1.0.5 is the version of hometown thats ontop
@Coffee@liaizon@darius@dansup@sexybiggetje Fedilab is referencing software.name in nodeinfo and has encountered an issue where it is no longer recognized as Mastodon. We haven't seen any other clients that have the same problem yet. However, apps that support or will support multiple server types may experience this issue in the future.
@darius@Coffee@liaizon@dansup@sexybiggetje In Fedibird, I decided to change the software.name of NodeInfo back to mastodon and instead add forks to metadata and write it there.
This forks will be added to the array when Fedibird is further forked. It's a good idea for the client to trace to a name they already know to determine the type, and to recognize the software's unique name by the last name.
When collecting statistics, it can be used as a category hierarchy.
@darius@Coffee@liaizon@dansup@sexybiggetje While checking the NodeInfo specifications, I noticed that the character type that can be used for software.name is `^[a-z0-9-]+$`.
@Coffee@liaizon@darius@dansup@sexybiggetje@apps As you pointed out, only metadata can add free items in NodeInfo (2.0 or 2.1), and even if you allow free text in name, you will have problems similar to User-Agent. That is, you must list the names of compatible products.
> Mozilla / 5.0 (X11; Linux x86_64) AppleWebKit / 537.36 (KHTML, like Gecko) Chrome / 51.0.2704.103 Safari / 537.36
@noellabo Ouch. Looking into the nodeinfo protocol a bit, I don't think it's intended for this usage (yet), especially not after software.name was made free text.
@Coffee@liaizon@darius@dansup@sexybiggetje@apps Here, I will focus on the name problem of fork, but I think that it is good to have a format that can be traced from the base product (major classification) to its derivation (middle classification) and its final form.