laurens

Members
  • Content Count

    12
  • Joined

  • Last visited

Posts posted by laurens


  1. Interesting idea. Here's some feedback:

    - Typo in 4.C: it says 'Add the account account to settings.json.data file following the specification' - I assume you mean invite account or something?

    - I think the fact that you have to give writable access to a share (the invite folder) is a risk; as BTSync currently is, I don't think there's a way to stop it from being abused; what would stop an evil-doer from storing 100gig there? It could either be a ddos on diskspace or bandwidth.

    - I understand that the problem of an evil person deleting files from there can to a certain extend be mitigated since BTSync has the option to store a number of deleted/changed files on the client, but I think that too has a limit; I could change a file a 100 times, and that would also cause the client to have a lot of space wasted, and depending on how BTSync deals with that (can't find it ATM), could potentially also overwrite any legitimate old copies, if it is limited to store only a certain number of old copies.

    - In the current document, you don't mention how to generate/manage public & private keys.


  2. I see your point, and agree that it probably won't benefit the majority of the bt sync users. However, I am of the opinion that it will do more good than bad to have these settings in there: it will help users who do sync there entire drive, and it will do nothing for people who don't.

    Also, the majority of users also won't be using OSX, and yet there are by default specific entries for osx, too.

    But: I'm happy to agree to disagree, just expressing my personal opinion.