Thanks for being proactive and clarifying. In the future, please feel free to contact our team members if you have any questions about where we are at, our APIs, etc. We're happy to chat!

MetaDisk and DriveShare are both applications that will interact on the Storj network, so I'm not sure what you mean. MetaDisk nodes are fine for testing API interface, but certainly not for a formal integration right now.

I personally don't know a lot about Opal and my intention is not to make any comments about the Opal project. My only concern is that if you are going to talk about Storj or Storj integration in public announcements, you make it clear what you are doing. People in the crypto community are already on edge because of the number of less-than-reputable projects around. We work hard to be crystal clear with our community about the progress of Storj and minimize concern where possible. Misleading or unclear announcements can undermine those efforts.

Storj dev here. I can second these concerns. Saying Opal "partnered" with us when they were just planning on using our MetaDisk API was concerning, but we just attributed it to over-eager marketing.

However, this current announcement, if it implies that Opal Drive is currently using Storj, is just too far. The current MetaDisk test nodes we have are just that, tests, and are not suitable for production usage for a whole number of reasons. We've made lots of progress on the farming infrastructure side (as highlighted in live.driveshare.org) but the farming network is not hooked up to MetaDisk yet.

Our current managed tests (i.e. our test nodes) are only accessible to our crowdsale supporters, who are whitelisted by SJCX address.

I don't like to sling poop, but these kind of announcements risk tarnishing the respect of our own project, so you guys need to be crystal clear in exactly what you are doing...

We'll actually be using libtorrent as part of the data transfer solution for Storj. I wrote a library for this purpose. See: https://github.com/storj/storjtorrent

Vitalik was a technical contributor to the paper. He contributed on a personal level and not officially on behalf of Ethereum. That being said, when Ethereum goes live we'll certainly be interested in integrating Ethereum contracts.

Well all greylists would be community run and you'd have to opt-in only to the ones you trusted (which would, ideally, be validated as correct by many community folks). If you don't trust them you don't have to use those lists (or any, for that matter). The blog post (and other posts on storjtalk.org) and our FAQ go into much more detail about questions that come up regarding this too.

I'd take a look at our whitepaper if you haven't already (storj.io/storj.pdf)

With Storj you'll be able to choose how you encrypt your files before uploading. Remember we're still a relatively young project in rapid development so lots of things will be changing. TarSnap is definitely awesome (compared to a lot of other solutions out there), but they've also been maturing since 2006 (8 years) and had a 2-year private beta.

Talked a bit about that here:
https://bitcointalk.org/index.php?topic=579797.msg9915442#msg9915442

That part is handled by the heartbeat process (also described in whitepaper). Basically, if the file is corrupted it won't pass the heartbeat and the storage contract is broken.

I talked about Maidsafe & Storj a month or so ago here:
https://bitcointalk.org/index.php?topic=841972.msg9480153#msg9480153

Since then, our new whitepaper was posted (storj.io/storj.pdf) and our Test Group A started.

Hope this helps.

Storj dev here. I talked about this elsewhere on BitcoinTalk, so will pull some excerpts here:

We're all about cooperation rather than competition. Unfortunately, this seems to be a thing in the decentralization space. Suffice to say, if both our projects are wildly successful then everyone in the decentralization ecosystem will benefit. As I like to say, in nature, polyculture systems work a lot better than monoculture systems. In our case, different teams with different backgrounds can try different paths of innovation.

One of the biggest differences between MaidSafe and Storj is that Storj takes advantage of blockchain technology and MaidSafe does not (as pointed out in one of their blog posts). David Irvine started working on MaidSafe back in 2006, before Satoshi even wrote the Bitcoin whitepaper. Because of that (even though they've integrated SafeCoins), they've gone along a different and unique evolutionary path.

Another difference, as some folks have pointed out, is that MaidSafe has been evolving their concept and organization for a while. Because of this, they've had time to build a pretty awesome team and work on some cool things like RUDP. I've had some exchanges with David and some MaidSafe folks on their forum and I think all of us share the vision and hope for what our platforms can accomplish. David and the MaidSafe team want to build a completely new kind of internet and have developed technologies to that end. Again, if they succeed we'll all be better for it.

Storj is a much younger project, really starting about 9 months ago, but we've made tremendous progress since that time. We're evolving on a different path than MaidSafe and are focusing on decentralized cloud storage at the present moment.

One of our strong desires is to make it unbelievably easy for non-crypto folks to use DriveShare and MetaDisk so UX is one of our core concerns.

You can check our whitepaper http://storj.io/storj.pdf for some more info and check our repos at http://github.com/storj.

There is certainly the possibility for integration of some of our front-end applications with MaidSafe (in addition to our own network) in the future. I think that in a world of open-source projects and decentralization, the more innovation the better.

What I said earlier still applies. As I understand it, OPAL is planning to use the MetaDisk API to support additional functionality in their own project. If they use the API to upload a lot of encrypted data chunks to the Storj network it's certainly possible that many farmers could end up receiving those chunks. But inside the Storj network it's the same deal.

Your last sentence seems to indicate you've made up your mind or are heavily leaning towards a certain conclusion. It's fine to be skeptical; at the end of the day, for anything to truly take off there are folks will need to "see it to believe it."


Of course LEOs will pursue folks who do things illegally anywhere. That's their rightful job. Folks who knowingly upload illegal content and share the decryption keys can certainly be liable. Folks who knowingly advertise access to illegal content could also be in hot water depending on jurisdiction.

Farmers receive encrypted chunks from the network, in an automatic fashion. Farmers can't tell chunks apart or piece them together as (a) it's highly unlikely they'd have all the requisite chunks to do so and (b) they may not know how the chunks were encrypted and (c) they wouldn't have the keys to decrypt any content. DriveShare clients will also ultimately prune any chunks that aren't being paid for, as a farmer would only want to store chunks that were economical for them.

So if a LEO nabs someone distributing illegal stuff, that person can no longer pay to keep their content on the network and it would be automatically purged from farmers' drives.

Is there a legal precedent you are basing your last statement on? Are you thinking about a certain legal jurisdiction?

Tor relays, for example, may see all kinds of content, however the Tor Project FAQ indicates that no one has ever been sued or prosecuted in the US for running a Tor relay. The same FAQ indicates that the Tor folks believe running a node is completely legal under US law. One of Tor's active sponsors (2014) is the US Department of State Bureau of Democracy, Human Rights, and Labor. I highly doubt the Department of State would fund a project where running a relay would put you in legal hot water.


Where did you read this? I think you may be thinking of folks who want to integrate with Storj. The MetaDisk API is one way folks will be able to interact with the Storj network and some projects are intending to make use of that API. No "selling" or "leasing" involved.

Hi All. Josh here, one of the Co-Founders of Storj. We're all about cooperation rather than competition, so I think it's possible to talk about Maidsafe and Storj without anyone having to disparage each other's projects.   Unfortunately, this seems to be a thing in the decentralization space. Suffice to say, if both our projects are wildly successful then everyone in the decentralization ecosystem will benefit. As I like to say, in nature, polyculture systems work a lot better than monoculture systems. In our case, different teams with different backgrounds can try different paths of innovation.

One of the biggest differences between MaidSafe and Storj is that Storj takes advantage of blockchain technology and MaidSafe does not (as pointed out in one of their blog posts). David Irvine started working on MaidSafe back in 2006, before Satoshi even wrote the Bitcoin whitepaper. Because of that (even though they've integrated SafeCoins), they've gone along a different and unique evolutionary path.

Another difference, as some folks have pointed out, is that MaidSafe has been evolving their concept and organization for a while. Because of this, they've had time to build a pretty awesome team and work on some cool things like RUDP. I've had some exchanges with David and some MaidSafe folks on their forum and I think all of us share the vision and hope for what our platforms can accomplish. David and the MaidSafe team want to build a completely new kind of internet and have developed technologies to that end. Again, if they succeed we'll all be better for it.

Storj is a much younger project, really starting about 9 months ago, but we've made tremendous progress since that time. We're evolving on a different path than MaidSafe and are focusing on decentralized cloud storage. You can read out current whitepaper draft here:

Storj (draft): https://github.com/Storj/whitepapers/blob/master/storj/Storj%20Whitepaper.pdf?raw=true

An updated version is forthcoming, that will include additional information about attack vectors and reputation systems.

Our MetaDisk whitepaper is available here: http://metadisk.org/metadisk.pdf

As Nic noted, we have had a beta of our Metadisk software up for a while. We are also alpha testing our DriveShare software in preparation for testing with crowdsale participants. The relevant repositories are here:

https://github.com/storj/downstream-node
https://github.com/storj/downstream-farmer
https://github.com/storj/heartbeat

We're primarily a Python house, but used C++ to code our Merkle/Swizzle verification schemes in our heartbeat library.

We've had alpha tests and the software is working well in several countries. We're planning to more widely open access to our live dashboard in the near future as tests come up.

One of our strong desires is to make it unbelievably easy for non-crypto folks to use DriveShare and MetaDisk so UX is one of our core concerns. We're also talking with folks to build Storj into many devices that have extra hard drive space.

---

To respond to some additional comments above:

I think looking at the codebases of MaidSafe and Storj show the projects are different and saying that Storj is a rip-off of MaidSafe is demonstrably untrue. I believe one of the reasons for the MaidSafe blog post regarding blockchains (though MaidSafe folks can correct me if I'm off) was to specifically show they were on a different evolutionary path than blockchain-related projects.

We raised 910 BTC from our crowdsale in July and are in discussions about more traditional investment opportunities as well. We are growing quickly.

We are also very organized as well, as any member of our team can vouch for.

I'm also working on an additional white paper for biologically-inspired, decentralized, self-reproducing servers as well that will integrate with Storj. Again this, is a different path than MaidSafe has taken.

So you can support one project, another projects, both or neither. Both projects will evolve along their paths and react to innovations in the space (e.g. MaidSafe introducing Safecoins to their platform). No need to spew FUD against either project, just support the ones you like and believe in and see what happens.

Would be happy to respond to any additional questions about myself or Storj as well.

I'll leave off with a nice blog post David posted about visions and supporters:
http://metaquestions.me/2014/05/09/what-is-a-vision/

This applies to all projects in the cryptospace. Just support what makes you passionate and as long as the projects you support are responsive to your needs and deliver, all is well.

Storj core dev here.

From what I've read so far about Zennet, it's possible you could run DriveShare farming software inside a container (e.g. instead of a traditional VPS) if you wanted to run an instance remotely instead of on your own computer. I'm also working on an autonomous agents system now that could plug into Zennet's distributed infrastructure nicely too. Can reach out when that whitepaper is done.

One question I have though, how would you be able to prevent someone from tampering with the VM on the host machine, or tweaking it so it feeds you back bad data? It would be nice if there were a system in place so everything inside the container is completely opaque to the host and the communication back-and-forth was entirely encrypted. You could even send some 'tests' once in a while to ensure the host isn't messing with the VM.

Thanks guys! And, shamless plug (if it's allowed here), but if you're pumped about Storj, I encourage you to join our own talk boards too at storjtalk.org. We try to be very responsive to our community's feedback, whether it be technical, business, or something else. Contributions are welcome too, whether they are simple grammatical reviews of our websites/blog/whitepapers or code or spin-off projects (e.g. Storj-based X).

Not really. The cost will be tied to market demand.

Well, among other things, you need to be signed up with Microsoft for Office 365 and Microsoft will have your payment and personal information stored in some fashion that you don't have control over. If your storage space is encrypted, it's likely that MS holds the decryption keys so your privacy is questionable (though I haven't researched their offering in depth). You also have to keep paying Microsoft (i.e. the same singular entity) indefinitely or your space is gone. If you end up storing lots of data with Microsoft (assuming you could, in actuality, store hundreds of terabytes -- e.g. if you're a video producer), Microsoft could suddenly decide to scrap its unlimited storage model, or spin off the business to someone else. It could also decide to suddenly change its pricing structure: i.e. you still have unlimited storage, but now they decide to charge an additional $25/month if you hold over 10 TB on their service.

With Storj, you'd only pay to store the amount of space you're using at the redundancy you desire. Your files are chunked, encrypted and distributed across the network so there isn't a single point of failure. There isn't one central company that can shut off your space all at once, as well. Think MEGA -- when they got shut down, a lot of legitimate users lost access to their backups/files. If someone stores something funky on a centralized service, an enforcement agency may decide to freeze the entire infrastructure or server during an investigation/to preserve evidence (that other innocent folks data may be held on) and you may be out of luck with access.

I'm also skeptical of indefinite, unlimited storage with a traditional provider. When iPhones first came out, many cellular providers like AT&T offered unlimited data plans, but those are now gone unless you're grandfathered in. And only a few days ago, Bitcasa, which also had an unlimited storage offering for $10/month, also stopped (see: http://techcrunch.com/2014/10/24/bitcasa-no-unlimited/).

Disclosure: am Storj dev.

Haha. Well, sorry to disappoint. 

Created an account to say this, but I'm actually in the early stages of putting together a whitepaper to describe a practical implementation of something similar to this (reproducing nodes/servers that can adapt/evolve in a certain fashion and support themselves using cryptocurrency).