Consider deterministically deriving the first three digits of `minorVersion` when instantiating SoulseekClient

[slook]

Since #893 version of 9 the library Require a minor version to be supplied when instantiating SoulseekClient. This is a good idea, but it is somewhat inconvenient that minorVersion...

• ... is a required argument in the main constructor,
• ... has to have a minimum value of no less than 100,
• ... should be unique from other projects yet there's no easy method for developers to ensure this,
• ... is named an ambiguous term whereas in fact it could be better if it were unrelated to a client's software version,
• ... doesn't necessarily imply a unique client type, as ideally it should help to identify...
  • ... a unique developer, and/or;
  • ... the project by its name.
• ... doesn't explicitly identify the library version upon which a client is based,
• ... is prone to frequent changing if a developer ties it to their application's "minor version" and has a rapid release cycle,
• ... doesn't protect against an actor from using a random number generator for each new instance of a malicious client.

Consider if the library could derive the first 3 or so digits of this number from, for instance:

• Numeric digits from the library package Version, such as "9.1.0"=910; "10.0.x"=100; "10.1.x"=101 and so on
• The client's application name string (if discoverable?), such as "slskd" = [numeric output of a deterministic hash function]
• A numeric output of a deterministic hash function from the specific combination of all the SoulseekClientOptions()
• Some other unique information that is already known by the library at build time that could be used for fingerprinting
• A combination of any of the above which derives some useful number to use as the first three or more digits

Then the minorVersion could be made optional, whilst still providing the intended benefits of requiring this value to be supplied, and helping the server admins to more reliably identify different clients types/versions on the network because:

• The likelihood of each client type having a unique value would be greatly increased
• It would be harder for a malicious actor to deliberately impersonate other client types to hide a bot net or swarm
• If the API library Version was used at the beginning of the value then...
  • ... the sequential numeric value would help to serve a purpose that is closer to the original intent of this field,
  • ... at least the start of the value will predictably increment rather than seeming/being entirely random/randomized,
  • ... client capabilities/vulnerabilities would be known and could be acted upon if required,
  • ... clients using legacy API versions could be restricted or obsoleted if and when it became necessary to do so.

If a custom value is also supplied by the caller then this could be appended after the first 3 derived digits, thereby still allowing developers the freedom to use the remaining part of this value for their own purposes as they so wish.

[jpdillingham]

Thanks for the feedback. I'm pretty firm on fixing the major version to 170 so that if server admins want to issue a blanket ban on all Soulseek.NET derived clients they have that ability, and I'm also pretty firm on forcing the minor version to be supplied in the constructor so that anyone using this library is forced to make a deliberate choice about what they supply (and I can search GitHub for them).

This library has used minor version 100 since the beginning and forcing the number to be strictly greater ensures that nothing using the latest version of this library can pretend to be an earlier version.

We don't really have details on how versioning works server side; we only know what what's being done in Nicotine+ and this library hasn't gotten any clients banned. I would be concerned that if a ton of new versions started popping up it may create issues, and there would be a much greater risk of conflicts.

I'm finalizing additions to the slskd license here that forbid forks from using a minor version beginning with 76, reserving 760-769999 for myself.

All of this relies on good faith, which I'm increasingly concerned isn't enough in the age of AI. I'm not sure what to do about that.

[slook]

forcing the number to be strictly greater ensures that nothing using the latest version of this library can pretend to be an earlier version

No I don't think that works you way you intended because the < less than operator is not <= less than or equal, see PR #910 :

Soulseek.NET/src/SoulseekClient.cs

Lines 106 to 109 in 8096d45

	if (minorVersion < 100)
	{
	throw new ArgumentOutOfRangeException(nameof(minorVersion), "The minor version must be greater than 100");
	}

All of this relies on good faith, which I'm increasingly concerned isn't enough in the age of AI.

That is also my concern as well, and I think the minorVersion could be helpful to mitigate in case of a serious issue that came about from a particular client implementation, but I'd say more needs to be done in order to programmatically enforce that the value is implementation in a way that is at least partially unique for each library version or such.

AI. I'm not sure what to do about that.

I think the main problem is that AI tooling tends to associate peer-to-peer networking with swarming topologies and wants to extend the protocol beyond its capabilities. To mitigate this I'd suggest better docstrings to ensure that your library's functions are not implemented in unintended ways. For example see nicotine-plus/nicotine-plus@7e1e19f