[tahoe-lafs-trac-stream] [tahoe-lafs] #1946: consider removing some st_* fields from metadata

[tahoe-lafs]

#1946: consider removing some st_* fields from metadata
------------------------+-------------------------------
     Reporter:  daira   |      Owner:
         Type:  defect  |     Status:  new
     Priority:  normal  |  Milestone:  soon
    Component:  code    |    Version:  1.9.2
   Resolution:          |   Keywords:  privacy anonymity
Launchpad Bug:          |
------------------------+-------------------------------

Comment (by zooko):

 I think {{{tahoe backup}}} was originally conceived as being, well, for
 "backup". And there was originally the idea that there would eventually be
 a {{{tahoe restore}}}. The assumption of a "backup and restore" use case
 is that the set of files and directories probably won't be shared or
 published while it is backed-up, and that it will eventually be restored
 to the same or a "similar" system as the one it came from.

 However, I don't use {{{tahoe backup}}} that way. I use it as a good way
 to publish files to my LAFS grid. I almost always use {{{tahoe backup}}}
 whenever I'm uploading files, and I never "restore" them, and I often
 share them. Even if a {{{tahoe restore}}} command existed, and even if I
 decided to use it, then the system I was restoring to might not have the
 same uid and gid set as the original system.

 So why do I use {{{tahoe backup}}} then if not for backup? Well, it is
 faster than "tahoe cp" or "tahoe put" or FUSE because it maintains a local
 cache db of files that it has already backed-up. It also keeps time-stamp-
 keyed snapshots of all previous versions that have been written to the
 grid. These are two very nice features.

 What if we create a command named something like {{{tahoe snapshot}}} or
 {{{tahoe mirror}}} that has those two features, but does not have the
 {{{st_*}}} metadata, which I do not think is meaningful in my use case,
 and which could be a privacy leak? An advantage of this new {{{tahoe
 snapshot}}} command is that then more people would discover its existence
 and its usefulness, even when they have a "publish" kind of use-case
 instead of a "backup" kind of use case.

 If you like this ticket, you might also like #1865, #897, or even
 [/query?status=!closed&keywords=~tahoe-backup&order=priority all open
 tickets about tahoe-backup]

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1946#comment:6>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage