Update comment

doc/todo/untracked_remotes/comment_1_ccc743554cf9270e1db5275273b28265._comment

@@ -4,5 +4,40 @@
  subject="comment 1"
  date="2014-01-01T21:32:56Z"
  content="""
-.
+Such a class of repositories would be very useful, indeed.
+
+A good name would probably be, in descending order:
+
+* ephemeral
+* volatile
+* transient
+* fleeting
+
+It would be somewhere in between 'untrusted' and 'dead'.
+
+I can see two approaches working nicely, here:
+
+1. Local location log
+2. Local location log in another branch / directory
+3. No location log
+
+In the first case, location data would be added to the local location log, but any `git annex sync` or similar would parse the location log and strip out all mentions of the UUID in question.
+This would be somewhat slower when synching, but would ensure that all operations which rely on local logs operate normally.
+
+In the second case, location data would be kept in a different location.
+This would have the benefit of a clean separation and quicker merges, but induces overhead for lookups.
+On the other hand, if those lookups are wrapped cleanly, only those functions would need to know about the different locations.
+
+In the last case, no local logs would be kept.
+
+
+All in all, I think I would prefer the first option.
+
+The one thing that's hard/impossible by design is for other remotes to strip out the data.
+As the repository would not be known to other remotes, they would simply continue the carry the data.
+This can be worked around by setting the repository to "dead".
+Ephemeral repositories would not correct "dead" info about themselves; they _would_ start behaving normally once set to trusted, semit-trusted, or untrusted, though.
+
+
+Richard
 """]]