This is like a Dropbox or Google Drive front-end with a torrent client's back-end, delivered as a PWA.
Users are able to access the web app through an official hosted domain or over the IPFS network. They can "upload" files and folders into an interface similar to Dropbox which enables exploring, updating and removing.
We want users to be able to self-host, download and share dynamic folders directly with each other easily all from the browser. The product is comprised of the protocol to track changes to dynamic content and the web app to interface with it. One of the largest advantages of the project is how easy it will be for anyone to start using. There's no need to make an account or give us your email. It would be similar to how many .io games in the browser operate (see agar.io).
Providing a service is not part of the current product. We will not own infrastructure for reliable hosting of user content. This could be built but will not be part of the MVP at this time. We will likely explore ways to make it simple for users to have their own server instances spun up and hosted by third parties. We think this is the first step to building more apps like this one; allowing users to take a look at of how these kind of apps can work and benefit them.
Use cases: An instant and permission-less web app for easily transferring files between devices. A self-hosted alternative to shared folders in Dropbox and Google Drive, enabling verification of exactly whats happening to your data and the ability to swarm downloads from peers, erasing metered connections.
Competitors: Centralized consumer cloud storage solutions like Dropbox, Google Drive. IPFS content hosting solutions like pinanta.cloud overlap in some parts as well. Some use cases over lap with file transfer protocols, we have advantages over many of these with default secure transports, nearest host with content can deliver, and zero configuration or signup. One downside is handling large file sizes will be an issue for now.
Attracting Users: Discord, along with many other sites, has this beautiful thing called an 'upload limit'. This limit is usually around 15-50mb at a time. When you want to send a larger file to friends (or maybe even enemies) you must find a platform you can both use. Sometimes you have to use different platforms depending what type of file you want to share, not very fun. You might even find the perfect platform that fits your needs, only to have it disappear a month later :(. What if you could have a site, hosted on the immutable web (and accessible through https gateways), useful for storing any type of content, and usable instantly without an account?
Need to transfer some files to a friend over the 'upload limit'? Try this site here pastes link. All someone needs to do is visit the site's landing page and click a button to launch the app. Once in they can upload, share or download files directly with friends with a code.
Scalability: The web app is made of static files that can be delivered over https or ipfs. We can have the official web app hosted on Cloudflare with automatic https while also hosting the app on dedicated ipfs servers. One cool thing we can also do is build the web app to host itself over ipfs. This would make it available through the ipfs network and public gateways.
The files hosted in the web app would also be able to scale. As more and more ipfs servers request and receive blocks of content more servers can deliver it.
First 2 weeks: The first two weeks will be used creating the base of the web app a long with designing the simple protocol used to keep consistent state of the dynamic files and folders. The base of the web app consists of setting up the repo with some of the tools (PWA, bundling, testing and workflow tooling) and sketching designs for the UI and user flow.
Inside 4-6 weeks is when I would like the protocol to be in a solid condition and have a strong base and basic features working in the web app.
Tech stack: React/Redux/ReduxObservable (this may change for performance and bundle size reasons), RxJS, Workbox for PWA, IPFS and OrbitDB for application logic, NodeJS
Monetization currently is not discussed and may be difficult to work in as all we are providing, aside from the official domain we will manage, is open source software for anyone to build and run. One idea would be to build and offer a service inside of the web app selling dedicated servers to host user content. However this introduces more challenges that come with traditional products: calculating cost for users, handling abuse, and managing infrastructure. Another way for revenue might be selling global names that can be set up to point to users folders. It would be possible to use a registry like the ethereum name service to do this.
Unconventional UX may also be a challenge. It's possible our app may be a bit alien to users. It might look like an app you are supposed to sign into, we will do our best to handle this. Explaining to users quickly and concisely what is going on immediately when they arrive, while also being intuitive, will be key. Having a landing page to optionally explain basics of the app before the user launches the app seems like a good start.
There's also UX related issues having to do with the different architecture and what users expect when using something that looks like Dropbox but acts much differently. Having icons and helper texts that can guide the user through downloads, sync progress and file history are some things to be implemented.
Hosting and managing data in the browser. IPFS would be using browser storage through the IndexedDB API. This has limits and, in browsers using Webkit, can be purged without user interaction. In the case of storage limits, limiting storage to 1GB for now is likely the step we will take (IPFS can also have issues with files larger than that). Another way to side step this issue would be to also offer a client built on Electron which would share a lot of code with the web app. In the case of Webkit wiping inactive websites storage, we may build a system for backing up critical data like crypto keys although simply creating new ones in most cases will be fine.
Researching and implementing the dynamic part of the distributed file system will be difficult. We will need to use something like OrbitDB to be able to recover from concurrent updates. It would be nice to be able to use IPFS's mutable file system api but this would likely introduce more complexity by having to manage the side effects. The state of the file system will have to live entirely inside OrbitDB by managing IPFS CIDs and updating the local IPFS repo accordingly on updates.
Security challenges. This is mostly related to people who want to control who has read access to a folder and can be handled two ways; configuring the local IPFS instance to only talk to nodes part of their private network and/or encrypting content before it's uploaded to IPFS.
The first of these options is harder to handle than the second, but both would be hard to do right. From a user standpoint connecting devices will be pretty easy, however connecting to a private IPFS network will be more difficult as they would need to configure their own IPFS server with signaling services to connect all of their browser devices. As much of this app is centered around users ease of use this option is not very compelling.
Encryption seems like a much better alternative for private information. Firstly we should make the user aware that anyone can request content from their server. Yes this is a big oof and needs to be looked into more much more. It's similar to if a data center was open for anyone to access the data inside, some of the data might be clear text and some might be encrypted. There might not be anything useful to do with the encrypted data right now but if someone were to store it for a significant amount of time it's possible they could eventually read it.
Data availability is another challenge especially when compared to centralized service like Dropbox and Google Drive. To request a file from the network, the network must first have that file. This seems obvious but will not be apparent to most users and will need to be explained. It's likely even then some users will upload content, close their browser (shutting down the IPFS instance), and then expect to be able to retrieve their uploaded content. It's possible users will have to keep the web app open in order for IPFS to respond to network requests. One strength in the area of data availability when compared to centralized services is that this is much more usable in offline and ad hoc network situations although this would still require a signaling server. We will not be hosting their content, we want to make it very easy for users to self-host.
A satisfying option for improving data availability is making it very easy for users to spin up their own web service easily through the app, but hosted on and paid for through some third party platform. That service would be a reliable node running the app's protocol. In the future as more storage networks like Filecoin and Storj's Tardigrade develop, that route could become an obvious one to go by integrating them into the client as long as the dynamic aspect of the users content is kept.
Browser support and compatibility is always a "fun" thing to deal with. Browsers and their API's can act differently and even the same browser can have different behavior depending on the OS its running on. Testing on one browser on one device is not an option if we want to ensure a consistent experience for our users. Across our team members we have every major platform covered (OS and browser) but will be looking for a cloud solution to speed up and automate the process.