somid3

DaasBoss, Seems I can't PM you. Feel free to email me at somid3 at gmail dot com Usesync.com was taken down. The source can be found at: https://github.com/somid3/bitcargo Let me know what you need. O.

Well, there is a simple solution to this. If the search engine has the secrets it can create a "Selection" secret that contains only the files the user wants to download. That way the end-user can only download the files he or she wants by selecting the files of interest.

So perhaps people can provide their read-only secrets, and optionally their read-write secrets?

Seems trivial to create a one time use secret for a file given the secret for a folder. Ideally people should submit the read-write secret to the search engine so the search engine can add a simple stats.html file on the folder informing everyone the level of activity, etc. There also needs to be no copyrighted material filter to protect such files from being shared I would imagine.

precisely my point, an intermediary search engine has to be able to catalog all files and send one-time use or selective-file secrets to users. These users will then use the selective-secret to access one or two files.

This is very cool. Practically making every person a web server. This could be an interesting way of sharing very large files, etc. More interesting would be to build a search engine that allows one to find the secret (or color coin) given a query. What are some use cases you think people will use your browser for?

How many public secrets exist out there? I ask because: It should be possible to make a search engine where people type something -- like "cars" -- and they get all the secrets and file listings from all the people that have made their secret public no?

On AWS you know that at least on peer will be online 24/7.

No, the tool was shut down due to low use

When I set: api?method=set_prefs&upload_limit=50 On the peer that is providing a file (Peer: A), the download speed of the peer downloading the file (Peer: hits 50 kB/s. At the same time when peer B is downloading a file at 50 kB/s, I call: api?method=get_speed On peer A, and I get: { "download": 9, "upload": 51223 } That is very confusing as right now there is no documentation on the units of the upload/download limits and the speed. And it seems both use different units. This is minor, but can be very confusing given the lack of details. Love the product though, it all feels like magic and it works flawlessly.

On the linux version of BitTorrent Sync I can't update the download_limit. wget http://127.0.0.1:8888/api?method=set_prefs&download_limit=1024 When I get all the prefs, the download_limit is still set to 0. Any advice? Also, what are the units here, bytes? Thanks, Omid S. ----- Oh I feel like an idiot. I didn't escape the & on bash with \&. My last question still applies, I wanted to see what is the download limit unit on that preference. Thanks, Omid ------- Nevermind, just tested it, for future reference its in Kb/s Note, you should add to the documentation that download and upload are relative terms. When peer A uploads to peer B, the upload_limit of peer A will be capped and the download_limit of peer B will also be capped. The lowest value between A's upload limit and B's download limit will be the final transfer rate, assuming their bandwidth is solid.

All right, we just released a new version on http://www.usesync.com. - Files are stored long term, sync-ing will no longer seize from working after 10 days. - We now provide the encryption-secret as well for those that want redundant copies in an encrypted fashion - We are also accepting request for enterprise customers -- we will only receive the first 5 customers, all other customer requests will be put on a waiting list and addressed on a first come first serve basis. If you experience any problems please let me know. - Would it be helpful if we also displayed QR codes for mobile users?

Ah, haha. That feature will be removed, all space now will be long term. I guess "self-destruct" was a strong word to use. What we meant to communicate was that after 10 days syncing will be turned off from our server's point of view. All files will remain on the peers that downloaded the files, and peers will be able to still sync with other peers, but the "always-online" peer that we provide will no longer act as an active syncing peer. However, that feature will be removed. After next release all sync spaces will be long term. One just needs to provide a valid email address to ensure the synchronization will not seize after 10 days. Initially I thought the 10 days limit would be a great functionality since it will keep server side costs low. However, after much feedback we decided to remove the 10 day limit if a user provides their valid email address. We are also going to remove the limitation of space on our servers. We are going to experiment with unlimited space and see how that goes. Likewise, are also going begin providing an enterprise server version so businesses can manage their synced directories in a manageable manner. While we are at it, we are also going to provide the encryption-secret that BitTorrent Sync recently made available. That way you can have redundant back ups of your files with other peers who will retain your files in an encrypted fashion. I hope this answered your question. Did it?

Hi lolcat, So the code is hard to explain but if you'd like for $500 I can spend a week modifying the code it so that you can make use of it in a very easy way. I can also add other features that you'd like... are you interested in that? I can make a Windows, OSX, or Linux executable that you can run from anywhere. Let me know

Sure, I am using the Play Framework and running it on AWS. Do you know Java, it requires a bit of configuration.