Add a config (and gitattributes) option annex.userkeystring , such that git-annex-add (and calckey) will include this string in the key.  If the string is 'UUID' then a uuid (or shorter random string) will be included instead.

From [[todo/support_longer_file_extensions]]:

"The way git-annex picks extensions doesn't need to be stable across all versions of git-annex, because it's only done when initially adding a file, and then the key, with whatever extension, is added as-is and git-annex does not care about the extension thereafter."

Then, for an MD5E key, the userkeystring can be included before the extension: MD5E-s0--d41d8cd98f00b204e9800998ecf8427e.USERKEYSTRING.txt .
Cleaner would be to add a field to the key, as in MD5E-s0-uUSERKEYSTRING--d41d8cd98f00b204e9800998ecf8427e.txt , if that wouldn't break compatibility.


This enables attaching metadata not to file contents, but to the file itself; or partitioning keys (and therefore key metadata) into namespaces.   The downside is some loss of 
deduplication.  This loss may be acceptable.  The loss can be mitigated for local repo and non-special remotes: after storing an object with e.g. MD5 d41d8cd98f00b204e9800998ecf8427e under .git/annex/objects, check if there is a symlink .git/annex/contenthash/d41d8cd98f00b204e9800998ecf8427e ; if not, make this a symlink to the object just stored; if yes,
erase the object just stored, and hardlink the symlink's target instead.

> Closing since [[external_backends]] is implemented, and you could do this
> using it. Whether that's a good idea, I'm fairly doubtful about. Be sure
> to read "considerations for generating keys" in 
> <https://git-annex.branchable.com/design/external_backend_protocol/#index7h2>
>  
> [[done]] --[[Joey]]
