As we’ve talked about before, we see Fission being a “constellation provider”, not a “cloud provider”. We’re not a single cloud that holds your data hostage: we’re built on portable and interoperable identifiers and standards. You host with Fission and pay for premium features because you like what we’re doing and value the services we provide.
Our whole server stack is open source, and you can run your own version.
The stack is complex, and requires good server management and dev ops skills to setup, and more importantly maintain and support. We see this being interesting for large enterprise or specialized use cases, or perhaps a collectives of users that band together, might want to run their own Fission Constellation.
We also intend to build federation features, to have logins, apps, and other content link between constellations, or even be run completely privately for large scale “internal” usage.
For now, we want to explore including people in our constellation directly. We’re in the midst of rolling out IPFS nodes in a cluster mode as part of our infrastructure to increase speed and reliability of the system. Specifically, we’ll have services running in Stockholm to serve our European app creators and users, as well as our existing US-based services.
Following Fission
Since every Fission user and every Fission app has a unique name, it’s relatively simple to decide which data you might want to keep a copy of on your local desktop / laptop, or on your local network.
We’re going to look at experimenting with how to run an IPFS node on your own local computer, and set it up in such a way that it “follows” the apps and users that you use and connect to.
This means the app data and user data – both public, and fully encrypted – gets backed up and served from multiple users all over the world, close to where the apps and data are being used.
For you, on your local machine, this means even if your local Internet connection goes down, it means that all your data will be local.
And of course, performance for things you run should be nice and snappy – they’re coming from your own machine a lot of the time!
Raspberry Fields Forever
We’re fans of the Raspberry Pi #rpi – a low-cost mini computer that’s still powerful enough to run all sorts of things.
We’re going to investigate putting together a Raspberry Pi setup so you can run a little mini server that stores files on your network for you. Or maybe you can even take it to your local coffee shop with you?
There are various instructions to do this already, so this is mainly a documentation and testing setup process. Plus, integrating any of the “follow” new scripts we come up with so your favourite content is easily stored locally.
This can start with some config settings or small scripts to get this working, and could go all the way to a compact flash operating system image to plugin in and have your very own IPFS storage node on your home network.
Are you running IPFS on RPi already? What’s on your wish list?
Back to Basics
But even before we get to the fun stuff, we have some basics to work on.
Fission focuses on bundling IPFS directly into the browser. The JavaScript version of a peer-to-peer IPFS node (which is called js-ipfs) runs in a person’s browser, including on mobile.
These nodes don’t connect to the main IPFS network by default. So Fission runs additional services over Web Sockets to connect to our servers, and through that to the entire main IPFS network.
But, there’s a catch. This doesn’t work out of the box with a local node running on your machine, or through the IPFS Companion browser extension, or the more integrated IPFS support in Brave.
We follow this path because we want our webnative stack to “just work” in every browser without installing additional software.
But we also want to improve performance for the tinkers and early adopters and developers who want to run an IPFS node for better performance and better offline caching of content.
This core work with js-ipfs is already underway with the wider IPFS community led primarily by Protocol Labs. We’ve made some issues and pull requests already, so this is just a statement about framing the problem and working together on the interoperability and performance that everyone wants.
Get Involved
There’s lots of testing, experiments, documentation — and yes, coding — tasks to do.
- We’ll ask folks to try various combinations of browsers, extensions, local nodes, and config settings.
- Think you can work directly on some of the coding or debugging work? Get in touch!
- We’re looking at putting together some pooled funding through our Open Collective Fiscal Host to get it done.
Let us know if you have questions or feedback in the comments!