Inter Planetary Flash Cards (IPFC) is an educational technology app, aiming to set the groundwork for a new kind of EdTech ecosystem.
Check out the app at App site & Github **use chrome browser to download the PWA.
test login: hello@world.ipfc password: Password123
We thought long and hard about how and why we were adding IPFS to our app. Its important to keep the goal in mind. Decentralization is great and all, but if there is a trade-off in usability, we should consider what parts offer the most benefit of decentralized architecture. Because the app is open source and could be moved to a new host easily, we don’t care as much about decentralized hosting as having a decentralized database.
Goals for decentralization:
Users feel secure knowing their data (currently just flash cards, but will be expanded to lessons, notes, etc.) cannot be taken away from them, lost, held hostage with fees demanded to use or export. Using an EdTech app can feel like a big investment into the platform, we want to take away that fear.
Data (cards for now) can be shared across other apps built by different dev teams. There might be an app that can create flashcards based on your web browsing. There should be a way to automatically sync the cards from one app to another, which requires a shared or open database between them. If the database is privately owned, even with a public API, it could be held hostage from the rest of the ecosystem.
Current state
Data persistence seems to be the main challenge of IPFS. if all of the files are only pinned from your laptop, and they are not popular enough to be stored in a gateway, they will be inaccessible when your laptop is offline/not running a node. You’d need a server for persistence/universal access.
Our current imperfect solution is to make users sign up for Pinata, and use the Pinata API to upload to IPFS at every sync. If you want to sign up for a new app, and have it access your card collection, you’d just have to give your pinata keys. This way, user are (sort of) hosting their own data, we (sort of) don’t own it in the way a traditional private server would.
So this crudely accomplishes the two goals, but the obvious caveat is that you are still relying on Pinata to pin your data and they could go out of business, deny you service, etc. They/whoever you gave your API keys to could also delete (unpin) your data. This could be fixed by asking Pinata if they could generate special API keys that only have read and write but not delete privileges.
One solution would be let users pin from their own server/or their own hardware if they don’t mind not having access when that hardware is offline. If they set up an API with the same call structure as Pinata, integrating with the app would be trivial. This solution isn’t a great choice because of the technical limitations and hassle for most users.
So does anyone have a better solution? Can Fission help? Cheers!
Something I forgot to address was the open database aspect. The current crude answer is that our private server periodically queries users Pinata accounts to track changes, compiles them into a large database, and uploads that to IPFS, with IPNS**. That way, other devs could query the entire database, but could only make changes if they have users’ Pinata API keys. This works pretty well too, but the caveat is that all users would have to have signed up through us.
Also looking for a better way…
**Currently we aren’t doing this, but it would be easy. Also could just open up our database API.
Hey @Jewcub thanks for dropping by and writing up this long scenario. Welcome!
It’s late in our time zone, we’ll dig into this with the team tomorrow and write up a couple of answers.
A brief beginning of an answer is, the way we’re designing Fission is so that developers can build and deploy apps, including files with IPFS, but also a built in identity system where users own their data.
Our own system will be migrating to this, so no more API keys — a private key you own is your access to your Fission Account.
And users will be able to delegate access to an app, so that app can use “their” storage to keep all the data in.
In this model, a user can give access to different apps, to the same data. It’s up to the apps to coordinate on things like data standards & interchange, although we’ll have some primitives for some basics like images, music, etc.
We’re also going to have a distributed database option, but that’s a little further off.
We also try and be pragmatic about decentralization. We use / store in IPFS natively, but if you just use our http API to access it…keeping it in IPFS doesn’t make much sense. So we encourage the use of js-IPFS so any client side app can access IPFS natively.
Thanks for the thoughtful reply!
It seems like Fission could meet some of our needs but I’m not sure.
It sounds like your set-up is similar to my current one if I’m not mistaken? You are basically acting like Pinata as a pinning service.gateway? And users have their own account with you and you pin on their behalf?
Correct me if I’m wrong, but on the decentralization aspect it seems exactly the same as my current set-up, users need to trust a 3rd party (you or Pinata) to keep their files pinned.
If I understand correctly, what you offer is both hosting of the app, and letting users provide me with just one key instead of a set of keys for access to their data. If you could set privileges on that access(read/write only not delete), it would be an improvement over what I’m doing with Pinata as far as user trust.
Re: “keeping their files pinned” – are you using an HTTP gateway for the content, or are you loading things over IPFS?
We built the get-ipfs library so that users can either be running a browser or extension that supports IPFS, a local node, or if none of those are available, it loads in js-ipfs. If you’re building on top of IPFS – going through http gateways is the centralizing part!
Users should be able to choose to pin their files wherever they like. Whether they pay services, or just run their own IPFS locally.
That’s how we’re building and designing our system, and why we’re building in portable identity, encryption, and other tools. The identity system will allow different services to act on behalf of the user – not as a one off “API key” but as a standard that anyone can integrate. That’s the same issue with “API with the same call structure as Pinata” – we need to build standards at a higher level than individual services.
Pinning is pretty un-interesting to us. From a user perspective EVERYTHING should be pinned all the time – other than truly large files (mostly video or large amounts of high resolution photos).
Probably easiest to wait as we release more of our platform. Fission Drive will be an example “app” that we build on top of our own services and will be open source so you can inspect it yourself.
Unrelated to the challenge you’re facing, I thought I would share a flashcard design I built a couple years ago. It’s in super rough shape but you can kinda see where I was aiming. Unfortunately, the same hyper-realistic card swapping effect that made it look cool also made it a CSS layout nightmare (fun fact: I literally measured distances and angles of my wrists flipping flashcards).
Maybe it gives you some inspiration for down the road
FYI, here in Canada, FIPA/PIPA compliance has been mandated in all post-secondary institutes. As a rule of thumb, anything involving student data leaving the country was rejected on it’s face. This meant vendors with on-prem solutions and explicitly Canadian hosting made it to the head of the line. It also meant turning down great products that misunderstood the buying-criteria.
Theoretically, web3 solutions are a good fit, although I’m not sure how easy it would be to convince the bureaucrats…
This is an older thread, but i am still curious about the concept of “pinning”… Especially curious how fission affords to pin all of our resources.
Any insights?
Hey @gotjoshua! We publish apps (raw IPFS) and store public/private data (per user #wnfs).
We take care of persistence — keeping your app & user data online on IPFS and through IPFS HTTP gateways.
We consider our current service in beta and “best effort”, and yes we don’t currently have paid tiers, but do get in contact with heavy users to see if they’d like to run their own stack or pay for their service.
Eventually we’ll have some paid services. Think similar to Netlify or Vercel at like $50/month for production apps.
You can, of course, persist your content yourself. We’re likely to integrate with NFT.Storage so you can put your credentials in and that service will persist as well as back up to Filecoin.
Right now we are venture funded. We also get paid by large customers to implement and extend our protocol engineering research. We also see certain ecosystems wanting to run the Fission stack and integrating it for production services.
Finally — we think identity and base file storage / bandwidth are commodities.
We’re working on a IPFS based database that we’re likely to have paid services around.
