Yes I do. I also remember when STORJ linkshare went down.
The “better uptime” argument I only consider valid, when people actually have the option to use STORJ native.
Does TrueNAS finally offer a nativ backup?
Or is it still just S3?
I mean offer STORJ as a backblaze cold storage Backblaze alternative at 2$ per TB. Maybe that will convince users.
Actually they do. Only use unused resources what the one and only USP of STORJ form the beginning. Otherwise you would not need a decentralized network with all its drawbacks.
We have had the same discussion multiple times years ago. It is always the same old story.
Just wait, STORJ is amazon in its infancy
Network growth is not that bad, here is some fake data
We have big customer X that hopefully will soon onboard
We are way better than Backblaze or Amazon, customers are just to stupid to realize it
We need fringe feature X, that would solve our issues
Trying the same thing over and over again and expecting a different result is not that smart. Now would be the time to be honest with ourselves and realize what STORJ sell, a commodity that is S3.
It isn’t fast, it isn’t decentralized, because it isn’t native in most cases and it isn’t competitive in its pricing.
That is why STORJ has IMHO 2 options:
Either make a native TrueNAS implementation as fast as possible, aggressively cut pricing to something between 1-2$ per TB stored or continue to run on VC money.
The interesting part will be if the Valdi acquisition will extend the VC money runway, or if they want to see results. If they really want a black 0 for 2026, we will see some dramatic changes.
Thank you.
But the question was not if I can do it.
I mean, there is a reason why you created this. Despite there already being a a “Cloud Sync tasks” that is able to backup to S3 of any provider, you also created a “TrueCloud Backup Task”.
I find it pretty fascinating that you partnered up with TrueNAS, even created a new name for an already existing feature, created a new GUI, made a press release, but somehow did not have the energy to integrate updates or “TrueCloud Backup Task” to be native instead of S3.
I seriously don’t understand the stance of STORJ towards S3.
I thought you would agree with me, that S3 is not decentralized, slow, and a net loss for STORJ? You always said that it is ok to be a net loss, since this is only at the beginning, to lure customers in, make the transition from S3 amazon to STORJ native.
So why are you not pushing native in any shape or form? I don’t get it. It is years later and we still don’t have any* meaningful native integration.
* I am not counting FileZilla as meaningful. I mean something like Adobe, a surveillance system, heck even just TrueNAS doing their updates. You know, something that actually brings customer data, something we still don’t have after all these years.
Decentralized (very fast because the file is split into many pieces that are uploaded to many nodes)
Secure (the file is encrpyted before splitting, so that only the customer can decrypt it)
Both of those features disappear if you use the Storj-hosted S3 gateway. The file is uploaded to one place and the gateway has to know your key. Of course, files can be encrypted separately before uploading to the gateway, but that is true for every single storage service.
Oh, and doing this costs Storj more money, because the gateway cannot be run on nodes.
It would be slower, but would work and would not cause a net loss to the company. There is no point in offering a service where you incur a loss providing it.
S3 makes sense for big customers temporarily - so they can test the service, then later use native protocol or run their own gateways.
Yes, there is one, though if Storj does not charge extra for using their gateway (in the past Storj said that running the gateway is expensive) why should the cusomer bother running his own gateway?
This especially applies to the NAS part - the NAS software could have been made to include the native client, but wasn’t and I don’t think that many NAS users would bother with running the gateway (as it would probably require a separate server).
In case of server applications, I can imagine a kubernetes setup where the gateway is configured as a sidecar container local to the application. This could then mean faster downloads. A rather specialized setup though.
For most people (the ones who use a NAS for example) that would be a very diffitult, if not impossible task.
Unless the gateway was made completely automatic, so that the used only had to click some button and start it, but then why not just use native client in the “backup to Storj” program?
A local gateway is feasable for professional deployments that HAVE to rely on S3 only software AND need the extra low latency, but for most users Storj drowning in S3 queries instead of native ones is a Storj problem and they’re not gonna deploy and maintain a local gateway for every service they use. Especially if it’s CLI only administration and they have to deal with the access grant system & local auth service as well. Probably not even a single one, because for most users standard S3 is “good enough”, but this also has the side effect of putting Storj in direct competition with insert any generic S3 provider here.
The main question is “why isn’t Storj, when they’re starting a new project/collaboration like TrueCloud Backup using their own client instead of a remote S3 gateway?” Is it too difficult to integrate (maybe)? Too performance hungry (probably not)? Not reliable enough? It can’t be less resource intensive to run an S3 client + a gateway on the same system, doing 2 layers of translation.
You know what, don’t even bother trying to understanding it. It does not matter anyway.
Just know this; we already have the option. Customers are still not coming. So whatever mythical, totally unexplainable problem storj is facing, there is magic barrier that hinders customers from coming in.
Uploads using the native integration consumes more upstream bandwidth because of erasure coding and encryption up to 3x. For a low upstream limits this upload will have a higher chance to fail. And the overall upload speed could be slower on low upstream bandwidth.
S3 uses 1:1 of the upstream bandwidth, so even if you use as low as 10Mbit it has a higher probability to be successful.
The native protocol usually can be faster on downloads than on uploads, unless you have a wide upstream and downstream bandwidth.
The backup task usually uploads data to the cloud, and rare downloads
The CloudBackup Task uses restic under the hood, so it has an additional encryption above Storj encryption, so win-win.
Also we have had a not good result with FileZilla - they procrastinating to update the native library for years, and the old library has incompatibilities with a new one. Not big ones, but still.
However, if there would be a demand for the native integration too, I’m sure it can be added.
We’re here still pretty far from what I’d consider an out of touch realm.
