Hi
Recently I 've been exploring the “boundaries” of what can be achieved using Internet Computer and now I wonder if it is possible to use IC as CDN to host images or documents. Like Amazon S3 + Cloudfront.
Here it is stated that there should be no limits on file sizes. So can one implement a canister that would host static files to be consumed by “traditional” web applications?
This is of interest to me as well. Also I would like to add the ability of not only hosting content (images, videos, documents, etc) for traditional infrastructure like you mentioned, but also for other open internet services on IC as well.
For example, if users upload short videos to CanCan, they may also prefer to upload the same clips to say, a future OpenInsta, OpenFB, OpenYoutube, etc. In such a case, wouldn’t it be better to host the content on such “user owned content only cannisters” for the specific purpose of storage that can then be used across multiple services, than say in a CanCan canister in this example? The latter would also result in extra cycles being burnt by CanCan rather than the other services that may use them, which won’t be very fair for the makers of one (CanCan in this case) over the others.
So yeah, you can both create an asset canister, and we in fact give you one out of the box with our dfx SDK tooling!
I’ve done a couple writeups on the topic, but yes, you can totally use the IC as a CDN, and we had that as a design goal in mind for our developer experience.
@Rakesh.MindInc as for video uploading, yeah, there are some open questions. I think a version where you upload the videos to some canister you own and lease it out to other platforms as content could be really interesting! That ecosystem has yet to evolve though, so we’ll see how it develops
@kpeacock Right, we are considering whether we should attempt something such ourselves, because our app is image and video heavy! Giving users the ability to “lease out their content” like you said would make it a win-win for both developers and users! Rather than restricting them to use the content only on our service, they will have the freedom to use it wherever they like.
As far as I can tell, all you’d need is to implement a contract that sits between the asset canister and the service that
You’d probably want to do a query with the payment getting settled async after the fact, since updates are slower than you usually want for social media. It seems very doable though.
For reference, here are our docs on accepting cycles: Accept cycles from a wallet :: Internet Computer
Thanks for reply, @kpeacock
I assume the following approach should work, but can’t figure out details.
When we need to upload new image, say something.png, to our so-called CDN, we create an “asset” canister with that image in /assets subfolder.
After that the image is accessible via https://xxx/something.png?canisterId=aaaa-bbbb-cccc-dddd
At least that’s how it works for local development, when xxx is localhost:8000
In case we deploy canisters to Internet Computer itself, how would xxx look like? I guess we should have an IC node that would accept requests and returns images, so to make something.png available for everyone and not only to those having IC node themselves (like https://myserver.com/something.png?canisterId=aaaa-bbbb-cccc-dddd). But this nullifies the idea of CDN, as we still have one server.
Or am I missing anything?
Also, how can I evaluate how much cycles (or ICP, or $) will be spent to deploy a canister with image of a particular size?
Just re the nodes, canisters are a separate concept from hardware nodes/replicas, so in your example you would have an IC canister that accepts requests and returns images. These canisters are automatically striped across the network by the platform itself according to network load, so you get the CDN functionality built in, without having to do anything. Users also wouldn’t need nodes at all to call your canisters, they can just use any ordinary web browser (or if you prefer, some client software written using one of the ic agent libraries).
Re checking costs, you could explore the ExperimentalCycles module in the Motoko base library: motoko-base/ExperimentalCycles.mo at master · dfinity/motoko-base · GitHub
Thanks @Ori
From what I’ve understood from this post is I don’t need to bother at all about domain names as it equals canister-id, so actual iage will be accessible on https://aaaa-bbbb-cccc-dddd/something.png
Yep!
We are working on custom domain name support for hosted canisters, but I don’t have docs to point you at yet. As for the pricing, the way we are supporting this at launch is to create a wallet canister that you can fund with cycles, and that wallet can send cycles to keep your canisters topped off.
Also, if you’re mainly focused on frontend canisters, check out one of our partner developers, https://fleek.co/. They’ll set you up with automatic builds on Github, subsidized (free) hosting, and more nice things. Basically netlify on the IC
