diff --git a/doc/todo/option_to_add_user-specified_string_to_key.mdwn b/doc/todo/option_to_add_user-specified_string_to_key.mdwn
new file mode 100644
index 0000000000..140a0a0f8f
--- /dev/null
+++ b/doc/todo/option_to_add_user-specified_string_to_key.mdwn
@@ -0,0 +1,13 @@
+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.