It looks really good. I’ll put it in the wire for the next round of approvals. Have you worked out with @pramitgaha how the payout will be distributed?
2 Likes
@pramitgaha agreed to $3,400. I get the difference from that. I think we can just give you our ICP wallets. Here is mine: c49ddb79b5243c6941c5b56b6150476f9e55996db8b497752b660a5c9adafac1
1 Like
Do I also need to post my address? @skilesare
You should post it, I created a new linked account just for distribution.
1 Like
@skilesare
here is mine:
f1dd32160226d1b7a3c61ef1accd2da62d4d81ac0abe801703d1694c8680f4cb
@cyberowl and @pramitgaha this code is great news.
We are building a DAPP that needs to upload documents to the IC.
I tried making your code work @pramitgaha but I got some errors when building the Rust canisters. I would prefer to use Rust, but on my local DFX I got the error below for one of the canisters:
On the other hand the code from @cyberowl ran perfectly, it all worked. I can not figure out yet how to use it, since I do not use Motoko, some pointers on how to use it from a Node.js application running locally would be most welcome.
Still, THANK YOU BOTH, this code is a Godsend for us, since getting this functionality to work is not trivial.
I am currently going over all the files you guys did, lots to review, but any additional guidance would be appreciated to save time, and understand how you built STATIC the example IC DAPP. Where should we start, and how could we integrate the code into a new Client App running locally on Electron ?
hello @josephgranata
can you show the error that you’re getting?
I’ve tested the code and I’m also using the same code in my other projects, it works fine for me!
@pramitgaha The error is on the screenshot I shared above.
It says an error happened in the Candid canister, and then it shows the error it found.
If you can tell me in detail the steps to correctly build your code, I will happily try again.
are you trying to run the test?
@pramitgaha I am trying to replicate the results of building the Motoko version in my local DFX replica:
When building that one, you get two canisters and their Candid interfaces.
When I try to build yours, using your Readme file instructions, only one canister builds. The other one fails, as shown on the screenshot.
The one that fails is the file_scaling_manager, the other one works. Here is the other error I get from the command line:
ahh! now I got it!
so, the file_storage canister is the crate that handles the chunk upload and file serving through http part.
@cyberowl has another canister for scaling the storage. I skipped that as the bounty was for uploading.
1 Like
@pramitgaha Okay, now I understand. I am guessing the whole storage scaling is in Motoko correct?
How do you suggest I could connect your code with the Motoko code from @cyberowl ?
@josephgranata
not into motoko, if motoko accepts wasm file for instantiating the canisters, then you can use the rust part with file_scaling_manager code.
however, I can push the code for storage scaling part too.
1 Like
Thanks! I would really appreciate having it all in Rust.
1 Like
Makes me happy that you are using it. We will help you in any way to onboard you and future users more easily into it. First a few questions.
Are you going to modify the code in any way to extend functionality?
What functionality are you wanting to use?
One of the easiest ways to get started is to use GitHub - cybrowl/agent-js-file-upload: fileupload pkg.
You can take a look at static to see how it is being used: static/src/ui/routes/+page.svelte at main · cybrowl/static · GitHub
All you need to do is pass the canister id to agent with some other args and deploy those canisters and it should work.
If you are running on Electron it should be the same as running it on web. You would need to communicate with the canisters that are running those storage assets.
I can help you more if I understand your use case.
Thanks again for using it.
1 Like
@cyberowl the main functionality we need is for a given IC user to upload his files into a canister where his files will reside, and to use his Cycles to pay for the file storage.
We would like to make the upload invisible, like iCloud and Dropbox do, but at the same time to have a confirmation of when a file was saved to the IC Blockchain. A status for each file like Dropbox does.
I am not familiar with Motoko, and I do hope @pramitgaha can finish the Rust code so that we can see the whole thing in Rust.
That said, I tested your code in Motoko, and it runs really well. I will try to get an understanding of the code you built too, perhaps we end up using Motoko for this feature.
Based on that description you should be good with what is there. The only part you will need to figure out is the flow of getting the user to pay before creation of the canister. Or maybe you will charge them later. You will need to map their files to some tree like structure if you want directories, organizational structure that maps those files. Also if you want to limit the viewing of those files you can do some kind of code based system to not allow access via the public url that is provided. Http requests cannot pass the principal in the IC. Other than that you should be good.
@cyberowl yes indeed, we plan to use a Rust data structure (a BTree) to replicate a directory like structure. Rust Stable Data structures help here, but there is no code similar to yours for the upload. That is why I am so interested in the work of @pramitgaha but I reckon I must examine your code, especially the way you build STATIC which is a remarkable showcase.
We also need a controller canister, and targets where to put the files in other canisters. Indeed we would need to charge the user beforehand.
I would appreciate any help as we build this, I will DM you for sure, thanks for your work!
@josephgranata I have started working on it!
I’ll be busy with my college assignment for 2 days.
after that I’ll complete and push the new changes
@pramitgaha no problem, thanks again.
One favor, that probably @cyberowl can answer.
Imagine you were in my shoes, meaning an experienced developer who knows JavaScript, and Rust; but no Motoko, and wants to get a good understanding of the series of programs you just built.
What would be the sequence of files I should examine to UNDERSTAND how they work together? Which should be first, second, third, and fourth? These are your code files:
a) GitHub - cybrowl/upload-file: uploading file assets
b) GitHub - cybrowl/agent-js-file-upload: fileupload pkg
c) GitHub - cybrowl/static-components: components for static
d) GitHub - cybrowl/static: ui showcasing file-upload scaling
Also where does the code @pramitgaha fit, I am guessing it can replace (a) only since the FileScalingManager piece is not there yet.
Thanks for your guidance in advance.
Joseph