Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Content availability and IPFS auto-pinning #542

Closed
tcrowe opened this issue Feb 8, 2020 · 5 comments
Closed

Content availability and IPFS auto-pinning #542

tcrowe opened this issue Feb 8, 2020 · 5 comments

Comments

@tcrowe
Copy link
Collaborator

tcrowe commented Feb 8, 2020

After working with the IPFS deploy, 3box, and other parts of the app I am seeing there may be a need for us to arrange a group pinning network for the assets in this project. The idea is to make all the content more available so users can get access to data, images, and documents.

CloudFlare IPFS proxy doesn't actually pin the IPFS CID. There is no guarantee that CloudFlare IPFS will reliably talk to Piñata IPFS. This would be an issue no matter if it were on CloudFlare or any other service. To boost up the connections and availability to the content we could assist as a community.

What could be hosted?

  • The dapp
  • Images
  • Video
  • Documents
  • 3box profile stuff

  1. When the site is deployed or a new asset is added we can use IPFS pub-sub channels to communicate the update.

  2. When an pub-sub broadcast message arrives we pin the content


It's a simple use case and app which may exist. We can find out.

Imagine you create a channel like:

  • mybit-go - app name
  • ethereum-mainnet - blockchain network and/or environment

Then you hash it:

const hash = require("crypto").createHash("sha256")
  .update("mybit-go")
  .update("ethereum-mainnet")
  .digest("base64")

console.log("channel", hash);
// channel channel KvR6OMlOMZsfQ7R12Ub7wXYPC69HE/fRQ+vY5YMrsYI=

Clients listen on that channel for messages.

{ "command": "pin", "cid": "app deploy cid" }
{ "command": "unpin", "cid": "app deploy cid" }

And probably sign it that. When it arrives users pin the CID and the content is more available around the world. It's easy for the deployer to send this message in the CI/CD and easy for anyone to receive. I don't think there is any risk of fraud or tampering due to IPFS's data integrity rules.


It's a simple way to distribute and boost up the availability of the content. Does anyone have any thoughts or suggestions? Has it been done? Is there a better way?

@cryptnotiq

@tcrowe
Copy link
Collaborator Author

tcrowe commented Feb 8, 2020

The dApp itself, clients, servers, humans, bots, and CI/CD can use IPFS & libp2p pub-sub right in the browser. MyBit users can opt-in and leave their browser open to host IPFS content. It's interesting, IMO.

@cryptnotiq
Copy link
Contributor

@tcrowe for non-technical users it seems like a messy process to pin the content. But i'm unsure of a better suggestion currently.

@tcrowe
Copy link
Collaborator Author

tcrowe commented Feb 11, 2020

Agreed. I was thinking that it should be automated and not done manually. This explains how we could do it technically.

@tcrowe
Copy link
Collaborator Author

tcrowe commented Feb 13, 2020

This is complex and it might be better rolled into a new module or new app. I've been speaking with the Commons Host community, an independent static host, and maybe I can propose this to their features.

Should we keep it open for MyBit org or close it out?

@tcrowe
Copy link
Collaborator Author

tcrowe commented Feb 22, 2020

I think we discovered that some of the innermittant issues were related to geography and network connection. I'm closing this out for now. If there is a need for more IPFS redundancy later we can re-open. Thanks for taking a look.

@tcrowe tcrowe closed this as completed Feb 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants