One of the common problems that the coaches and players have is transferring the footage that’s been recorded on the players computer to the coaches machine so that they can load it into Vodon Pro. This are quite often ~4gig video files as minimal compression is performed on them to ensure that the coach is working with the maximum amount of detail (they’re usually 60fps+ framerates to boot).
To solve this, I put together a small app called FileYeet which allows the coaches (and anyone really) to easily create portals, a.k.a a website page, which can be used to upload files (https://www.fileyeet.io/ if anyone is interested )
The site is built with Elixir / Phoenix and a small amount of React for the file upload interface. To integrate with Storj I’ve leveraged an AWS S3 library which seemed to play quite nicely with Storj’s S3 compatibility layer. However! After browsing around the forum a bit, it seems that I’m leaving quite a bit of functionality on the table by using this compatibility layer. Given my use case (generating signed URLs so that the uses can upload and download) what am I missing out on with this approach? Does anything spring to mind for people that would be a better solution (and can you link me to the docs about it )
Finally, a couple of small bits of feedback after working with Storj for a while. I couldn’t see if ACLs are used by Storj and if they are, they didn’t seem to be visible in the UI interface and I couldn’t figure out how to use uplink to query for the current ACLs on an object. As I grant access only via signed URLs this didn’t affect me too much as I was setting everything to private anyway.
Sounds very interesting.
I am just a SNO (so maybe I am even storing some of your data already, who knows? ).
As far as I understand the user uploads a file through the portal and the coach downloads it to view it in Vodon Pro?
Have you ever thought of an option so that the files can be streamed directly from Storj DCS into Vodon Pro without downloading it first.
Let me also point you to https://transfer.sh/ which uses Storj DCS as storage backend as far as we know. Maybe this gives you some additional ideas for your portals.
Streaming is tricky because of the file sizes and that a coach might have 5 simultaneous viewpoints loaded at once (even some SSDs struggle to deliver this, let alone over an internet connection) - that said, I’m planning on integrating both a bit more closely, having Vodon Pro manage the downloads into a library of videos for the coach automatically.
Thanks for the link to transfer.sh - very interesting. Similar concept but I suppose mine is a bit more user friendly, although I am a big fan of developer focused tools that can work on the CLI like that.
Yes I understand that streaming might face technical limits. The advantage however would be clear, a coach would simply need a link and could start reviewing immediately without the need to download and to save those big files locally.
Let’s see, maybe someone from Storj will jump on this thread and can add some thoughts what might be possible and what not.
From what I understand is that Storj is currently focused on these kind of use cases and put a lot of optimization into performance through massive parallelism. If that would be enough for such a use case like yours, I cannot tell. But it sounds very interesting I have to say. @Dominick
It’s good to hear that your app is already working as expected!
Yes, if you could use a native integration, files can be downloaded much faster, see Hotrodding Decentralized Storage
But upload could be slower (consumers ISP plans usually have asymmetric streams - downstream is faster than upstream), so for upload you can use S3 compatibility but for downloads use a native integration (see Storj Client Libraries | Storj Docs).
In case of low bandwidth (like 3G or H+) the S3 compatible layer will be more preferred though, because the file will be uploaded to the one endpoint instead of 110. And download will happen from one endpoint instead of 39.
Great! Thanks for the link, I’ll check it out. Any plans on an official Elixir client library? (and to follow up, do you use some kind of codegen to produce each client library?)
Some of the bindings are maintained by Storj, but others are maintained by community members.
Storj currently has no plans for an Elixir binding. If you have the expertise in Elixir, it shouldn’t be a problem to implement such binding as a wrapper to the C binding.
Spent a bit of time trying to improve speeds after some complaints. Converted my upload system to use the split uploads feature in S3 and now I upload 3 parts at one time (with file splitting based on the size of the file). Can confirm that I’ve got the speed to about 95% of what I get uploading to Google Drive which is cool.
I’d be interested in seeing other peoples speeds compared to Google Drive as well if anyone can be bothered testing
Basically, I would like to do something similar. A simple and free file-sharing website, however, I can’t do that myself. Would your website copy be for sale at one point?
I’m in the same position. I use Gokapi to send large files to people, and that can use Storj as the back-end, but it doesn’t allow people to send files to me (it’s a port of Firefox Send that uses an admin login).
I like the idea of a self-hosted solution where I could configure portals with different options (like file-size, how long they’ll last, etc.), but even as is this would be a very useful self-hosted tool. Assuming that whoever self-hosted would configure the Storj backend to use their own buckets.
I could be persuaded to open source what I’ve written so far I’m in the process of merging FileYeet with my esports VOD review so I’m not too attached to the standalone version as most of the code is going to be integrated elsewhere anyway.
In terms of running it, it’s all in a Docker container but requires a couple of external dependencies, the first is a Postgres database for tracking state and the second is a tool which is used to manage the push notifications.
I’d say to make it standalone totally requires:
Fixing the known exceptions that have been occurring (this is kind of on my list anyway).
Move the storage from Postgres to SQLite so that it can be totally self contained.
Remove the push notifications hard dependency and make it optional.
@acourter27 if you’re interested in taking some of this on then I’m happy to grant you access to the repo and advise on how to go about things (the app is written in Elixir / Phoenix).
)
)
).
I’m in the process of merging FileYeet with my esports VOD review so I’m not too attached to the standalone version as most of the code is going to be integrated elsewhere anyway.