Internxt launched today desktop sync client and it works.
Everything based on Storj v2. Fork.
1 Like
Different business models, different targets 
Not sure what you wanted to say here?
It can’t work unless internxt managed to fix the fundamental issues storj v2 has. Should we dive into the issues? Now that the storj v2 network was shut down I am allowed to talk about all the issues.
2 Likes
Yes @littleskunk I am very interested what are exactly the Issues of v2. It will be very nice if you tell this.
However I am wondering that somebody build up a product on top of v2
Always love some insight into how things were.
I definitely know that simple replication wastes a lot of space and results in less reliable storage. If the wrong 6 farmers would have gone offline, that file is gone.
All storage was based on expiring contracts so no permanent storage. And I believe no meaningful form of repair. But I’m sure I’m missing a lot more stuff.
There are a bunch of issues and most likely I have forgotten most of them already.
Storj v2 has a fixed contract length / no garbage collection
The customer uploads a file and the farmer will store it for 1 year. If the customer deletes the file earlier it will not get cleaned up from the farmer. After 1 year the farmer will just delete it without any further check. The farmer will delete it even if the customer would still like to access it. We worked on a contract renewal system but it turns out that the bridge wouldn’t be able to scale so we never finished the contract renewal system. → Expect to lose your data after 1 year.
In storj v3 we solved that problem with garbage collection. That allows us to store data without any TTL. If the customer deletes a file we send a delete message to all storage nodes. If a storage node is missing a delete message we can still clean it up days later with garbage collection.
Storj v2 has no audit system
It has very basic but simple to manipulate the reputation system. The normal workflow would be: Customer requests a download from the bridge, bridge contacts farmer, farmer returns auth key, bridge returns auth key to the customer, the customer connects to the farmer using the auth key and downloads the data. If the farmer is not holding the data anymore it will return an error instead of an auth key back to the bridge. That will reduce the reputation and at some point, the farmer doesn’t get new uploads. What if the farmer changes his code? How about always return an auth key but later return an error back to the customer? The answer is the farmer will stay at 5000 reputations even if he sends all uploads to /dev/null. Happy cheating!
In storj v3 you can try that but you will get disqualified within a few days inclusive losing the holdback amount. That is a penalty that should keep cheaters out of the game.
Storj v2 has no repair system
Let’s say we have no cheater in the network. We still have to deal with node churn, hardware failures, and other issues. We never implemented a repair system. At some point, the data might get unavailable. Especially with increased contract time of 1 year.
In storj v3 we have a repair system in place that replaces lost pieces before the file is in danger.
Storj v2 has wrong incentives
Farmer wants to get as much download traffic as possible. At the same time the farmer is responsible for creating mirrors (uploading the file to another farmer). Mirror traffic is unpaid. How about not creating any mirrors? That would allow the farmer to get 100% of the download traffic for this file. At the end of the day that was the incentive in storj v2. Do not create any mirrors because they are unpaid and they will reduce your download traffic.
In storj v3 that is not possible. Repair traffic is paid which is a good incentive to not block it. Even if a few storage nodes are blocking repair traffic the remaining pieces will still allow a successful repair. So there is no incentive to block the repair traffic.
Storj v2 has no Sybil attack protection
In storj v2 it is possible to register thousands of nodeIDs and point them all to a single farmer. The farmer needs a small modification to respond to all uploads. At the end of the day, this single farmer can dominate the entire network. Combine that with the previous ideas and you can destroy the storj v2 network with a single pi3.
In storj v3 a Sybil attack will get expensive because of the nodeID generation. It takes hours to generate a single nodeID. It will take years to generate thousands of them.
We could also talk about the advantage of the storj v3 reed Solomon encoding over the storj v2 mirrors. Storj v3 has a lower storage expansion factor and a better performance than storj v2.
Did I miss anything? Feel free to extend the list 
9 Likes