When linksharing links are shared and the performance makes Storj DCS look really bad

On Twitter we are seeing @BoonjiProject spreading the link to their NFT downloads that are stored on Storj DCS from now on: https://twitter.com/BoonjiProject/status/1457082823135924228

Something like: https://link.us1.storjshare.io/s/jws5cnue3pwx42a5tkfnq6qdj3qa/boonjiprojectcom/decentralizedassets-highres/11111.png

Now these files are only about 15 MB but for me being in the EU the download performance isn’t that great. When I switch the download link to ap1 then it is even slower: https://link.ap1.storjshare.io/s/jws5cnue3pwx42a5tkfnq6qdj3qa/boonjiprojectcom/decentralizedassets-highres/11111.png

To be honest, it is terribly slow and I am afraid this makes Storj DCS and the idea of decentralization look really bad where it should stand out.

Let’s compare performance for my location in Germany by downloading the 17 MB file 3263.png from the 3 available linkshares in a fresh Edge browser:

Takes about 30 secs to full display.

Takes about 7 secs to full display.

This took 7 minutes (!!!) to full display

Now if a project like @BoonjiProject publically advertises only the us1 link for NFT download, people in the US won’t have any issues. But users outside of the US will not be impressed by the performance of the decentralized new way at all or even totally annoyed by it, which will give Storj DCS a very bad name.


Maybe STORJ could build a worldwide kind of load balancer that checks the location of the client and then forwards to the nearest satellite. Then users would only need to call one global url which will avoid confusion and will automatically choose the best performance satellite for each request. This might be done with Serverless cloud infrastructure…


Yes, something like that is really required. We have seen it lately here as well, that clients don’t seem to be aware that there are multiple choices of share links and depending on the users location one might work much better than the other.

I think this should be addressed. Best solution would be to offer only one ‘global’ share link and the request gets routed to the best performing destination.


Here are some options to route traffic based on the geo-location of the requester.

Very interesting. The AWS Latency Routing Policy seems to be the fit.

You do not need Route53 or Cloudflare for this.

We are working on having this sorted out, but Rome also was not built in a day. :slight_smile:
Be a little patient with us, especially with the amount of growth and excitement in mind. :pray:


Well yes and no. Because from my perspective as user/customer it is really bad if it takes 7 minutes to download something which is advertised as “hot-rodded” super parallel hyper-fast download. And as a user you gonna ask yourself why should I sign up to or recommend such a service. Keep in mind that the user in question does not know that switching to another satellite may improve his performance by orders of magnitude. This is what makes things so bad in this matter.

1 Like

Honestly, the location will always be a problem. Same would apply to S3 buckets that are served from different continents. In our case there is of course a slight overhead due to the additional satellite roundtrip(s), which you seem to hit hard with the AP1 link and the US1 satellite being responsible, while sitting in the EU.

Something to keep in mind here is that the linksharing/gateway-mt service will never be lightning fast, simply by the nature of it being an hosted proxy. In every case, customers should intend to use native integrations that download/upload directly.

I am in EU and I dont have this big timing, bigest was 15-20 sec, and EU one is in 4 sec max
Other thing is that AP1 is not avalable now, 5h earler worked fine.


My priority here is not about the time to download. If it takes 30 seconds to download then be it.
My main issue is the significant time differences and that a user preferably should be routed to the best performing destination to give him the best experience possible.

1 Like

That will be the case when we get to it. For exactly the clarity purpose, the urls have the region within them. When our solution is implemented, the region specific subdomain will be gone.


This sounds very promising.