Can you show some usage examples and resulting UA string?

Also: For what it's worth in web browsers there's currently a trend toward simplifying user agents, creating less variants instead of more. Mostly for privacy reasons. Is signalling this extra information in the user agent useful for the user of the node, or is it simply for statistics for the developers?

Slightly tend to NACK. Might as well put in the OS, whether the full node is controlled by the GUI, ...

Sometimes remote attacks can only be exploited in a specific environment, putting that specific environment into the ua and sending it to the attacker seems counter productive.

Can you show some usage examples and resulting UA string?

-uaappend ABCore:1.1.1 could produce /Satoshi:0.20.0/ABCore:1.1.1/

Sometimes remote attacks can only be exploited in a specific environment, putting that specific environment into the ua and sending it to the attacker seems counter productive.

You could argue for removing the UA entirely. But so long as it's there, there's no reason to stop other people from using it as intended. (Nobody is forcing anyone to use this if they don't want to.)

I agree with @luke-jr here, concept ACK.

Might as well put in the OS, whether the full node is controlled by the GUI,

This is different, it's something user puts there if he wants to (example - "UASF"), not something that gives out some information about your system by default.

Note we already have uacomment for user stuff. This would be just for applications built on top of Core.

Giving a footgun to a user is less bad than giving a footgun to applications built on top of Core. Explicitly offering the option makes it seem "officially supported" or even encouraged for applications to use it.

How about if we hide it behind -help-debug?

I simply don't see the use case to tell malicious remote peers that you are running on an Android system.

If there was a use case, then other operating systems (and other system information) should also be put in there, not only Android.

ABCore is not an operating system.

A better example might be Wasabi, but I'm not sure they support Core at the moment.

Or Armory, perhaps.

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• common: Disallow calling IsArgSet() on ALLOW_LIST options #17783 (util: Fix -norpcwhitelist, -norpcallowip, and similar corner case behavior by ryanofsky)
• refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags #17580 (refactor: Add ALLOW_LIST flags and enforce usage in CheckArgFlags by ryanofsky)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

Rebased

I can't see much support for adding this, and for what it's worth I'm also a ~0/NACK. I don't think there's heaps of value to adding a "not really supported" hidden option to allow other pieces of software to add more information to our user agent. Also the examples given don't seem very convincing:

ABCore

Is this still actively developed / maintained? Seems like the website no longer exists, and the repository has a bunch of spam issues open / hasn't seen any updates for ~18 months. Has it moved somewhere else?

A better example might be Wasabi, but I'm not sure they support Core at the moment.

As mentioned, this software doesn't actually support Bitcoin Core, for reasons unrelated this this, so this seems like a poor argument for adding a feature for it to use?

Or Armory, perhaps.

Do we know if this is something that Armory actually wants/would use?

In any case, I'm going to close this for now.

don't think there's heaps of value to adding a "not really supported" hidden option to allow other pieces of software to add more information to our user agent.

I agree 100%. Also the privacy zeitgeist seems to be to strip as much as possible from user agents and other publicly visible software-identifying information, not to add more specifics.