Provide advisory on naming of custom features to avoid possible conflicts

[alimirjamali]

How to file a helpful issue

The problem you're addressing (if any)

If user sets a feature for their local personal program (or whatever reason), it might be allocated by Qubes OS project in the future and break something. Just like how it is mentioned in #7730

The solution you'd like

1. Allocate some prefixes (e.g. user-, custom- or dev-) for user custom features workflow. Never use them it in future developments. Document this.
   Optional:
2. Have a database of all known features. If user tries to set an unknown feature without the above prefixes, warn them that it might conflict with future features and they would better prepend the custom prefixes.

The value to a user, and who that user might be

Advanced users and 3rd party developers who might need custom features.

Completion criteria checklist

(This section is for developer use only. Please do not modify it.)

[marmarek]

Generally a good idea. I wonder about specific prefix - the ones you proposed is not a bad idea, but still may result in some conflicts with 3rdparty extensions (for example I can see several people coming at custom-start-services name with different semantics, and some may also publish their setup as salt formulas to reuse by others...).
Maybe encourage some user/project specific prefix? Like user-marmarek-... or custom-qusal-... ? Or maybe shorter x-marmarek-... (x- prefix is common for extended unregistered values in various protocols). There is of course still a chance for a conflict (I don't think it's desirable to enforce any central register of those prefixes - after all, the point of this recommendation is to allow user safely using their own features without registering them anywhere), but should be much smaller.

[alimirjamali]

Or maybe shorter x-marmarek-... (x- prefix is common for extended unregistered values in various protocols)

This sounds very good for private use.

I also considered reverse domain name notation. Something like tld.domain.app.feature_key. e.g. com.example.feature_key or press.freedom.securedrop.feature_key. This might be safe to be shared with other users without any worries for conflicts. p.s.: As far as I know, there is no existing official feature with dot in key.

[marmarta]

I agree with x-[project-or-username] pattern. It also clearly distinguishes features that are part of core qubes from custom ones; and big projects like SecureDrop could use e.g. sd- prefix, which would be kind of visually consistent.