Quinist

Members
  • Content Count

    12
  • Joined

  • Last visited

  • Days Won

    1

About Quinist

  • Rank
    Member
  1. Seconding this. The feature seems overdue.
  2. Oh please, just like 1024 bit PGP keys were "unbreakable in the foreseeable future", back in 2001. Or how 640 kB ought to be enough for everybody. Yes, and at that point I would lose mobile access and I could also store the data on other untrusted servers like Dropbox and the many other options. Don’t get me wrong, I’m not planning to save any highly sensitive data via Bittorrent Sync, but I still don’t want random people to go through my family pictures and random documents with almost no effort sometime in the future. An encrypted peer under my control with a long, self-generated se
  3. I second this. I was really excited about the encrypted peer feature, but this is a deal breaker. To sum this up from my enduser perspective (I planned to use a VPS as an encrypted peer for somewhat secure cloud storage), please correct me if I am wrong: Unlike with other secrets is not and will never be possible to simply derive an encrypted peer secret from a custom, self generated base 64 RW secret. The only way to make use of the encrypted peer feature is to generate a brand new share using the "api?method=get_secrets&type=encryption" call, note down the three (RO/RW/ENC) secrets
  4. Encrypted peers seem like a feature that many end users would like to use for backing up data to an untrusted location. Is there a reason why you decided to "hide" this behind a developer-only API ?
  5. This is going to be a killer feature. An additional "encrypted read-only" secret would be so much cleaner of a solution than the various Truecrypt/EncFS workarounds. Thank you in advance!
  6. I would really appreciate if you could add this feature soon: That would be amazing for many apps like Goodreader or Jotnot (to upload and share pdfs/scans via BTsync) Thank you for your work!