matrioshka encryption, right? - Love how “current thing” topis becomes a Hyde Park and Alex don’t even bother to split it in hundred different topics anymore like he used to. Beside that. i though storj cut the erasure coding significantly to improve just that? The big test last year or so was all about that reed solomon multiplier cuts, so the customer wont need to upload that much more above real weight.
Broooh.. “its a biiiig biig club, and You ain’t in it” - but i guess that just changed with inveniam aqusition i guess
You and I don’t need to understand why betting on customers running a gateway is delusional. Customers already have the option. But there are still no customers. So something is wrong.
See, we have a similar situation with OpenAI.
They need loads of money to operate. But have no paying customers.
And even if they win a customer, it is a net loss.
So you creating a ChatGPT subscription tomorrow will result in OpenAI losing even more money. That is a net loss. Same is true for every single customer that is using storj over S3. So even if we tomorrow find a new client that wants to dump 500TB into the storj network, this is only positive news if the client does not use S3.
Storj and ChatGPT both could be able to survive for decades. That is what VC money is for. But sooner or later, you have to make a profit. People will always come up with amazon as an example. While it is true that Amazon made a turnaround, they did actually change stuff and evolve.
Ask yourself, what did Storj do in the last two years?
Did it gain new customers? No.
Did it made the product in any way better or cheaper? I don’t know.
It seems like they made the nodes a little bit faster with the new hashtable after the onboarding of the surveillance customer showed that this is a fair-weather system that struggles even under slight load.
But other than that, was there any progress in the last two years?
Yes. Another downside of STORJ. Another reason why it has to be cheaper than B2.
I don’t think delusional, but now I understand your comment.
With self hosted S3 gateway they have no need for Storj provided S3. (Since Storj have now provided an alternative to Storj provided S3, they can now charge for the use of their gateway)
Is just an idea. My life will continue as is, with or without it.
All profitable, anything what wouldn’t be profitable likely would be reconsidered.
To make more money together
This is the same as was when we acquired Valdi, together we get a bigger revenue because of synergy (GPU + Storage).
Here I would expect the same result.
What native integration are you looking for? I’m currently and have been for some time backing up to Storj. I checked, as its been some time since I started doing it but it has native ‘storj’ credentials that I put in, has an advert for what Storj is, I put that in, and then it’s available as a target for cloud backup task and cloud sync task.
The discussion is about S3 gateway vs uplink. Built-in IXStorj “integration” is just a fancy hardcoded S3 connection string to Storj-hosted S3 gateway.
Uplink provides much higher performance ceiling at the huge cost of upstream bandwidth amplification, load on the network equipment due to the massive number of concurrent connections, and local CPU utilization for sharding and encryption. Most users don’t want to or can’t pay this price, let alone for benefits they don’t need. Moreover, most consumer network equipment would and does hang at any non-trivial uplink-generated traffic. S3 integration is therefore not only much more appropriate, but the only sane default choice.
The native integration (using the Storj native protocol) has many benefits like a high parallelism, a client-side encryption, has access to much more storage nodes than to gateway nodes and when you have a wide bandwidth, robust network and need speed (however, you need a pretty high bandwidth to be faster than using S3 protocol at the moment). So if your bandwidth is 100Mbps you likely will not have a difference in speed, if less, S3 might be faster, if more than 1Gbps, then libuplink might be faster. However, downloads from the network are usually faster with libuplink (again, if you have a good internet channel) due to a parallelism.
The biggest benefit of native is this though:
It does not run over a centralized Storj S3 hosted gateway that costs a lot of money for traffic.
Instead it will get the data directly from nodes.
S3 gateway is basically centralized Backblaze just with the storage outsourced.
It completely undermines the USP of Storj (using unused resources).
Financially this makes no sense and isn’t sustainable.
It’s not centralized, it’s a distributed service like everything in Storj, including satellites and their databases, not only nodes. Even the link share service is distributed, not saying about auditors and repair workers.
But the advantage there that storage nodes have a greater number than gateways at the moment.
Maybe, also - auditors and repair workers, and the database. The last thing will be a true solution, because it usually is a most expensive thing, of course, also egress, but there are options.
It could be implemented right now using Intel TDX, but no so confidence in it so far, it’s not the same like with blockchains or an encrypted distributed storage. You need to protect every single byte and the operation to do not be exposed to a malicious actor.
No it does not. Gateway is an independent service on top of storj. What, as soon as you use storj as a backend for another service you undermine its goal? So you can’t use it at all?!
Customers who plan realistically have choice. Use storj native it it fits them, run the s3 gateway (because face it — all software already supports s3) or use the one storj provides, for free, for now.
In fact glaring example is IX storj integration. TrueNAS uses restic for backup. Restic does not support storj, only S3. So here you go.
And no, this does not make it closer to Backblaze in any shape or form other than improving usability. In fact Backblaze also has to bolt s3 on top. First they explained in their blog post how they will never do that and how b2 is superior. And in the later blog post they explained how they have to bony on s3 because they had to.
If you want customers you have to support s3. Storj did it in a best way possible, as a standalone app anyone can run.
So this is a very ignorant thing to say. I recommend reading the design documents for both storj service and the gateway.
Let’s try it a different way. Let’s assume there is no STORJ native. Only S3.
Different vendors compete in the S3 market. Amazon, Backblaze, Wasabi and so on.
What they all have in common is that they run datacenter with storages, with S3 on top. What they use underneath S3, does not really matter.
STORJ had the very smart idea of not selfhosting storage, but let nodes do that for them. Ok, but why should paying nodes be cheaper than building a datacenter and put many 45 drives storinator in them and buy a multiple 100GBit lines at DE-CIX? Why should I as a node host be able to buy drives cheaper than Backblaze? Why should I be able to run storage cheaper than Backblaze? I can’t. I am only cheaper because I use unused resources.
So the answer is simple, you pay nodes very little.
And why can you pay the nodes so little? Well, nodes use only unused resources. That makes the running costs for storage for node operators exactly 0$.
0$ is a lot less than what you have to pay for running a datacenter.
Great isn’t it?!
It is.
But one thing is missing from this picture yet.
For an S3 gateway, storj has to pay for peering. A datacenter only pays once (data from/to a customer from/to the datacenter uses the line only once). storj has to pay twice.
Data from/to the node from/to the S3 gateway and from/to the customer.
So now you see, from a STORJ company standpoint, the only things you have achieved in this made up S3 only world is that:
You don’t have to store the storage
You pay twice for traffic
IMHO that business model isn’t financially feasible.
Well, it depends on whether paying double for traffic is cheaper than paying for storage, isn’t it? It at least depends on usage (upload, store for a year, delete — cost of traffic irrelevant here), and we don’t have actual numbers so this is all speculation:
it’s either already cheaper on average
Or the plan is to migrate large or most customers to native or self hosted gateways eventually, making this cheaper on average.
Those customers that require high throughput would be interested in using native anyway. Storj still has an advantage of being able to sustain very high throughput. Unlike this silly Backblaze that has nothing — no performance, no reliability, no integrity, no profits, just a horde of fanboys.
Right again. But there are clues. We first ran out of tokens, now got bought by someone. So I would argue that we ran on VC money.
Which they did not. For years. I also don’t know why. I can only speculate
it was not important, because the network isn’t really used anyway (20PB)
It is very hard to implemet. This one I could see. Not because the coding part is so hard, but even TrueNAS not really believing in the project and offering create a native integration in a collaborative effort, is a hard pill to swallow
they just had other more important priorities like the hashtable but are now on it
They have something that STORJ does not have: actual customer data and users. We might see the same problems arise, when STORJ finally has customers
You know, just like the BTRFS RAID bug that nobody discovered until recently, simply because nobody was using BTRFS in production and everyone was using ZFS instead
