In progress, collected most of the current day used encryption schemes in MIT licensed JS and converted some to CS. Added some optional dependencies to other nice, stand-alone usable encryption tools. Would be elegant to seperate a bunch of schemes currently in one file -> src/lib files
No testing set up or planned yet.
Possible features based on some (not so) common use-case scenarios I could come up with:
- MD5 checksum list and download link generation?
getHash('md5', ['src/files/iso/*','src/files/some-huge-archive.bin'])helper function used in src/document files What/how? Much like you use getBlock pass array of files, return JSON list of MD5 hashes and download links Why/when? Really only if someone frequently publishes large files that require checksums although a lot more file downloads could benefit, verifying a MD5 checksum to ensure you have a complete and valid file (?) is something not many people or sites do. Also: how often would you change this? And isn't the future more and more cloud? On the other hand, virtual images of OS/distro's in the cloud, to really run in a optimal way, would always constitute a download of that image locally (imagine a virtualbox instance on dropbox...how will that work? it won't really mainly due to network limitations) or atleast cached portions of that. Another viewpoint or possible future use, would be if say a lot of people (developers) would store their say Vagrant boxes in dropbox. Mind you: this constitutes a full Linux development environment as a virtualbox instance from a modified vbox distro image used as a base template. The only hurdle for this to be truely kickass or as much as feasible with current technology, is the problem of concurrency in data and multi-user environment. Then with incremental delta sends over the network, you have a lot more at your hands than say cloud9 currently does... oh well... Conclusions Seems like a bit too much effort for something unlikely to be used often - much like my writings :P user-base potential :low...DNP