Our app currently uses Pinata for IPFS integration. Is there a better way?

Description

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:

  1. 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.
  2. 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. I want to have an option to run an IPFS deamon/node on the users device and call it ‘swarm mode’, which would help a whole class of students download a lesson quickly, but adding a node to the app doesn’t solve syncing and data persistence issues.

Our goals are clear. Is there a better way?

2 Likes

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.

You could make it so users upload their content to your server, and then your server handles pinning the content and then giving them the IPFS link to access it through.

This isn’t a direct answer to your questions, but you may want to keep in mind that content on IPFS is public (https://medium.com/pinata/ipfs-privacy-711f4b72b2ea, https://github.com/ipfs/faq/issues/181). If this is an issue, you can address this by encrypting IPFS content, and having an encryption key for each user on your server that you give to the client when they log in.