Open Science, IPFS Integration, and Platform UI

[KeithSSmith]

In order to accomplish our goal of open science and collaboration we a need a reliable method to store and reference information (papers, reviews, data, etc.). IPFS allows us to achieve this goal by offering decentralized distributed file storage that can be reference by the same address anywhere a computer can connect to it. It also allows for cheaper storage and tracking version history to see changes made throughout the publication process.

Storing this kind of information is not practical on the Ethereum blockchain due to the gas it would require, but storing the permanent IPFS address on the blockchain would be much more effective for having an immutable entry to reference and attribute back to on the OSO network. This address would also be accessible to anyone else interested in obtaining and referencing the work at any time in the future. To present a couple of solutions to this problem I will list what I have found so far:

• Access via Oracles
  • http://docs.oraclize.it/#general-concepts-data-source-types
  • Anything to do with Oracles will certainly require more Gas
• Access via JavaScript
  • https://github.com/AdrianClv/ethereum-ipfs
  • https://github.com/ipfs/js-ipfs-api
  • Handled by the web application and written to blockchain as reference to storage hash
  • Someone has stated that it is still expensive to store the IPFS address in the blockchain, but I’m not sure I believe that as long as you store it in the proper type, will POC this and see what the actual cost is on private and test networks.
• Access via Go and IPFS fork
  • OpenBazaar forked IPFS – https://github.com/OpenBazaar/go-ipfs
  • OpenBazaar implemented this integration in their own Go daemon – https://github.com/OpenBazaar/openbazaar-go
  • OpenBazaar runs a stand alone app that enables P2P exchange/store fronts. It was required to fork the IPFS code and alter it so that the OpenBazaar nodes can talk to each other as alluded to in the README’s in the links above. Altering this code for OSO would most likely not be necessary since we do not need to solve the same problem OpenBazaar does, so it could possibly use a more direct fork of the IPFS Go daemon.

Option 1 is more than likely not necessary if it can be handled by JS but wanted to include it for completeness. On a side note, while this Gist is old, I still thought it was a good read and very informative: https://gist.github.com/nagydani/b3ab04f9970952a51b0c

Since there are three current examples of using IPFS above and I am sure more can be found we should determine how we envision the platform being accessed by the end user. That decision will help drive the IPFS implementation and dependencies.

• Access via a web site
• Standalone application with own daemon and client
• Combination of these
• None of these and something else

What would be the easiest to use as a researcher who may or may not know (or care) much about the distributed nature (cryptocurrency) of the platform?

[noman-land]

Hey guys, finally got around to whipping up a simple example of a purely in-browser IPFS node. No need to run a separate IPFS daemon and link to it from the browser. This is using a pure Javascript implementation of IPFS from: https://www.npmjs.com/package/ipfs.

Here's the example project: https://github.com/noman-land/ipfs-example.

Here's the app in action, and an example of viewing the content on a public gateway immediately upon adding it to IPFS.

Things worth keeping in mind:

• There is nothing keeping content inside IPFS. There are some automated mirrors that will mirror newly added content for a few hours, but it'll eventually get garbage collected unless the node that added it is online or some other nodes pin the content that was added.