{ "allMarkdownRemark": { "edges": [ { "node": { "id": "6effe45d-0884-527c-9fba-6f7f567979fd", "fileAbsolutePath": "/Users/m/Code/blog/content/photos/2019-11-03-orszaghaz-ii.md", "html": "
Inside the Hungarian Parliament Building in Budapest, Hungary.
", "excerpt": "Inside the Hungarian Parliament Building in Budapest, Hungary.", "frontmatter": { "title": "Országház II", "linkurl": null, "tags": null, "image": { "childImageSharp": { "original": { "src": "/static/2019-11-03-orszaghaz-ii-2dbcf257b4bdf625c24fede935d32425.jpg" }, "fluid": { "aspectRatio": 2.3255813953488373, "src": "/static/2dbcf257b4bdf625c24fede935d32425/ef7a0/2019-11-03-orszaghaz-ii.jpg", "srcSet": "/static/2dbcf257b4bdf625c24fede935d32425/23780/2019-11-03-orszaghaz-ii.jpg 100w,\n/static/2dbcf257b4bdf625c24fede935d32425/02ed9/2019-11-03-orszaghaz-ii.jpg 200w,\n/static/2dbcf257b4bdf625c24fede935d32425/ef7a0/2019-11-03-orszaghaz-ii.jpg 400w,\n/static/2dbcf257b4bdf625c24fede935d32425/ac974/2019-11-03-orszaghaz-ii.jpg 600w,\n/static/2dbcf257b4bdf625c24fede935d32425/12c26/2019-11-03-orszaghaz-ii.jpg 800w,\n/static/2dbcf257b4bdf625c24fede935d32425/24914/2019-11-03-orszaghaz-ii.jpg 3793w", "srcWebp": "/static/2dbcf257b4bdf625c24fede935d32425/a93fc/2019-11-03-orszaghaz-ii.webp", "srcSetWebp": "/static/2dbcf257b4bdf625c24fede935d32425/b0720/2019-11-03-orszaghaz-ii.webp 100w,\n/static/2dbcf257b4bdf625c24fede935d32425/f6188/2019-11-03-orszaghaz-ii.webp 200w,\n/static/2dbcf257b4bdf625c24fede935d32425/a93fc/2019-11-03-orszaghaz-ii.webp 400w,\n/static/2dbcf257b4bdf625c24fede935d32425/7c0bb/2019-11-03-orszaghaz-ii.webp 600w,\n/static/2dbcf257b4bdf625c24fede935d32425/d1e4e/2019-11-03-orszaghaz-ii.webp 800w,\n/static/2dbcf257b4bdf625c24fede935d32425/0a478/2019-11-03-orszaghaz-ii.webp 3793w", "sizes": "(max-width: 400px) 100vw, 400px", "originalImg": "/static/2dbcf257b4bdf625c24fede935d32425/24914/2019-11-03-orszaghaz-ii.jpg", "originalName": "2019-11-03-orszaghaz-ii.jpg", "presentationWidth": 400, "presentationHeight": 300 } } } }, "fields": { "slug": "/orszaghaz-ii/", "date": "November 03, 2019", "type": "photo" } } }, { "node": { "id": "c80697e5-681d-5fcc-9dab-c3a3821ff0b1", "fileAbsolutePath": "/Users/m/Code/blog/content/photos/2019-11-02-orszaghaz-i.md", "html": "The Hungarian Parliament Building seen from across the Danube in Budapest, Hungary.
", "excerpt": "The Hungarian Parliament Building seen from across the Danube in Budapest, Hungary.", "frontmatter": { "title": "Országház I", "linkurl": null, "tags": null, "featured": true, "image": { "childImageSharp": { "original": { "src": "/static/2019-11-02-orszaghaz-i-36d87329aeeda296ae923606e5a4a785.jpg" }, "fluid": { "aspectRatio": 2.3255813953488373, "src": "/static/36d87329aeeda296ae923606e5a4a785/ef7a0/2019-11-02-orszaghaz-i.jpg", "srcSet": "/static/36d87329aeeda296ae923606e5a4a785/23780/2019-11-02-orszaghaz-i.jpg 100w,\n/static/36d87329aeeda296ae923606e5a4a785/02ed9/2019-11-02-orszaghaz-i.jpg 200w,\n/static/36d87329aeeda296ae923606e5a4a785/ef7a0/2019-11-02-orszaghaz-i.jpg 400w,\n/static/36d87329aeeda296ae923606e5a4a785/ac974/2019-11-02-orszaghaz-i.jpg 600w,\n/static/36d87329aeeda296ae923606e5a4a785/12c26/2019-11-02-orszaghaz-i.jpg 800w,\n/static/36d87329aeeda296ae923606e5a4a785/b9e8b/2019-11-02-orszaghaz-i.jpg 3708w", "srcWebp": "/static/36d87329aeeda296ae923606e5a4a785/a93fc/2019-11-02-orszaghaz-i.webp", "srcSetWebp": "/static/36d87329aeeda296ae923606e5a4a785/b0720/2019-11-02-orszaghaz-i.webp 100w,\n/static/36d87329aeeda296ae923606e5a4a785/f6188/2019-11-02-orszaghaz-i.webp 200w,\n/static/36d87329aeeda296ae923606e5a4a785/a93fc/2019-11-02-orszaghaz-i.webp 400w,\n/static/36d87329aeeda296ae923606e5a4a785/7c0bb/2019-11-02-orszaghaz-i.webp 600w,\n/static/36d87329aeeda296ae923606e5a4a785/d1e4e/2019-11-02-orszaghaz-i.webp 800w,\n/static/36d87329aeeda296ae923606e5a4a785/730f8/2019-11-02-orszaghaz-i.webp 3708w", "sizes": "(max-width: 400px) 100vw, 400px", "originalImg": "/static/36d87329aeeda296ae923606e5a4a785/b9e8b/2019-11-02-orszaghaz-i.jpg", "originalName": "2019-11-02-orszaghaz-i.jpg", "presentationWidth": 400, "presentationHeight": 297 } } } }, "fields": { "slug": "/orszaghaz-i/", "date": "November 02, 2019", "type": "photo" } } }, { "node": { "id": "2e2c9611-be7b-5bc0-a72b-6c63e2072b5a", "fileAbsolutePath": "/Users/m/Code/blog/content/posts/2019-10-24-ocean-protocol-and-ipfs-sitting-in-the-merkle-tree/index.md", "html": "IPFS is now integrated into the Ocean Protocol stack, allowing you to take advantage of decentralized asset file hosting.
\n\n\nThis article was originally posted on Medium in the Ocean Protocol blog.
\n
With Ocean Protocol, you can use centralized storage services like S3, Azure Storage, or your own On-Premise storage to store and retrieve your asset files through Osmosis drivers in Brizo.
\nBut storing asset files in a centralized service poses multiple problems:
\nInitially created to store and efficiently move scientific data sets, the InterPlanetary File System (IPFS) solves all those issues with its goal of transforming the vastly centralized web into a distributed peer-to-peer network.
\nFiles are distributed among multiple nodes, eliminating the single point of failure, legal, and censorship issues. By using content-based instead of location-based addressing of files, URLs won’t break if files are moved.
\nSo we defined OEP-15 to make the ipfs://
protocol a first-class citizen in the Ocean Protocol stack, allowing you to store asset files on IPFS, and use their native IPFS URLs during the publish process.
In short, every component in the Ocean Protocol stack now supports publishing and consuming of asset files stored in IPFS which includes support for native IPFS URLs, referencing files with their Content Identifiers (CIDs).
\nEvery file stored on IPFS is public by default, so it made perfect sense using this in our Commons Marketplace first. We went through multiple prototypes to end up with our final setup.
\nDuring the publish flow you will find an extended Files section for adding a file from an existing URL, and for adding a local file from your device to IPFS.
\n\nThe existing URL field now supports ipfs://
in addition to http(s)://
so if you have an existing asset on IPFS, you can add it here and everything works as before. With the exception that the asset files will be registered with this native IPFS URL.
The new IPFS drop zone provides a convenient way to add and register unpublished asset files.
\n\nThat drop zone allows you to add a file from your local machine and add it to IPFS during the asset publish flow in a snap:
\n\nFirst, opening up the drop zone area will ping the IPFS node & gateway to check connectivity. Dropping or selecting a file from your device onto that area does a bunch of things in the background:
\nipfs://QmX5LRpEVocfks9FNDnRoK2imf2fy9mPpP4wfgaDVXWfYD/video.mp4
.All these steps are required because of how files in IPFS are distributed among its nodes. When adding a file to a node (note how it’s not called “uploading”) it is only available on that node. Requesting that file from another node will start the distribution process of the file from the initial IPFS node, making it globally available.
\nAlso the consume flow required some changes. Whenever an asset file stored on IPFS is requested to be downloaded, multiple things related to IPFS are happening in Brizo with its shiny new osmosis-ipfs-driver:
\nipfs://
url is mapped to its https://
gateway URL.ipfs://QmPQNaNxHkasNiJBFZht2k3zCEBkvEu1aE5VNGZ8QiT8Nj
), the proper file ending will be added automatically at the end of the download process, based on detected MIME type.While developing this feature, it became clear we need to run our own IPFS node & gateway to have better control over the whole experience. And donating a node instead of taking away bandwidth from the main IPFS gateway (gateway.ipfs.io) felt like the right thing to do to make Juan happy.
\nSo we created ipfs.oceanprotocol.com, run by us (that is, legally speaking, BigchainDB GmbH).
\n\nIt is setup to be a public gateway, and provide some access to its node HTTP API for everyone. This means you can use it to address any content in the IPFS network, like:
\nAt the same time all node API functionality required by Commons is open to the world, so those endpoints can be used by anyone to add files to IPFS:
\n/api/v0/add
/api/v0/version
/api/v0/id
As a start, this is a simple single node but we plan to gradually upgrade ipfs.oceanprotocol.com to a full IPFS Cluster of multiple nodes for best data availability.
\n\nBeside upgrading to an IPFS Cluster there are many ways the process will be improved over time. At the moment the drop zone in Commons only supports single file uploads, so a quick win improvement would be to allow dropping multiple files at once. Likewise, the drop zone using js-ipfs-http-client comes with some bugs when trying to upload larger files.
\nTo make the process of adding files to the IPFS node less dependent on the client browser, it could be moved into a background task in the Commons Server. This should also give more control and feedback for the process of distributing a file from the initial node to other nodes.
\nAnd finally, further work may be done to store files encrypted on IPFS and implement a way to decrypt them in an Ocean Protocol network.
\n\n\nThis article was originally posted on Medium in the Ocean Protocol blog.
\n
Inside the Hungarian Parliament Building in Budapest, Hungary.
", "excerpt": "Inside the Hungarian Parliament Building in Budapest, Hungary.", "frontmatter": { "title": "Országház II", "linkurl": null, "tags": null, "image": { "childImageSharp": { "original": { "src": "/static/2019-11-03-orszaghaz-ii-2dbcf257b4bdf625c24fede935d32425.jpg" }, "fluid": { "aspectRatio": 2.3255813953488373, "src": "/static/2dbcf257b4bdf625c24fede935d32425/ef7a0/2019-11-03-orszaghaz-ii.jpg", "srcSet": "/static/2dbcf257b4bdf625c24fede935d32425/23780/2019-11-03-orszaghaz-ii.jpg 100w,\n/static/2dbcf257b4bdf625c24fede935d32425/02ed9/2019-11-03-orszaghaz-ii.jpg 200w,\n/static/2dbcf257b4bdf625c24fede935d32425/ef7a0/2019-11-03-orszaghaz-ii.jpg 400w,\n/static/2dbcf257b4bdf625c24fede935d32425/ac974/2019-11-03-orszaghaz-ii.jpg 600w,\n/static/2dbcf257b4bdf625c24fede935d32425/12c26/2019-11-03-orszaghaz-ii.jpg 800w,\n/static/2dbcf257b4bdf625c24fede935d32425/24914/2019-11-03-orszaghaz-ii.jpg 3793w", "srcWebp": "/static/2dbcf257b4bdf625c24fede935d32425/a93fc/2019-11-03-orszaghaz-ii.webp", "srcSetWebp": "/static/2dbcf257b4bdf625c24fede935d32425/b0720/2019-11-03-orszaghaz-ii.webp 100w,\n/static/2dbcf257b4bdf625c24fede935d32425/f6188/2019-11-03-orszaghaz-ii.webp 200w,\n/static/2dbcf257b4bdf625c24fede935d32425/a93fc/2019-11-03-orszaghaz-ii.webp 400w,\n/static/2dbcf257b4bdf625c24fede935d32425/7c0bb/2019-11-03-orszaghaz-ii.webp 600w,\n/static/2dbcf257b4bdf625c24fede935d32425/d1e4e/2019-11-03-orszaghaz-ii.webp 800w,\n/static/2dbcf257b4bdf625c24fede935d32425/0a478/2019-11-03-orszaghaz-ii.webp 3793w", "sizes": "(max-width: 400px) 100vw, 400px", "originalImg": "/static/2dbcf257b4bdf625c24fede935d32425/24914/2019-11-03-orszaghaz-ii.jpg", "originalName": "2019-11-03-orszaghaz-ii.jpg", "presentationWidth": 400, "presentationHeight": 300 } } } }, "fields": { "slug": "/orszaghaz-ii/", "date": "November 03, 2019", "type": "photo" } } }, { "node": { "id": "c80697e5-681d-5fcc-9dab-c3a3821ff0b1", "fileAbsolutePath": "/Users/m/Code/blog/content/photos/2019-11-02-orszaghaz-i.md", "html": "The Hungarian Parliament Building seen from across the Danube in Budapest, Hungary.
", "excerpt": "The Hungarian Parliament Building seen from across the Danube in Budapest, Hungary.", "frontmatter": { "title": "Országház I", "linkurl": null, "tags": null, "featured": true, "image": { "childImageSharp": { "original": { "src": "/static/2019-11-02-orszaghaz-i-36d87329aeeda296ae923606e5a4a785.jpg" }, "fluid": { "aspectRatio": 2.3255813953488373, "src": "/static/36d87329aeeda296ae923606e5a4a785/ef7a0/2019-11-02-orszaghaz-i.jpg", "srcSet": "/static/36d87329aeeda296ae923606e5a4a785/23780/2019-11-02-orszaghaz-i.jpg 100w,\n/static/36d87329aeeda296ae923606e5a4a785/02ed9/2019-11-02-orszaghaz-i.jpg 200w,\n/static/36d87329aeeda296ae923606e5a4a785/ef7a0/2019-11-02-orszaghaz-i.jpg 400w,\n/static/36d87329aeeda296ae923606e5a4a785/ac974/2019-11-02-orszaghaz-i.jpg 600w,\n/static/36d87329aeeda296ae923606e5a4a785/12c26/2019-11-02-orszaghaz-i.jpg 800w,\n/static/36d87329aeeda296ae923606e5a4a785/b9e8b/2019-11-02-orszaghaz-i.jpg 3708w", "srcWebp": "/static/36d87329aeeda296ae923606e5a4a785/a93fc/2019-11-02-orszaghaz-i.webp", "srcSetWebp": "/static/36d87329aeeda296ae923606e5a4a785/b0720/2019-11-02-orszaghaz-i.webp 100w,\n/static/36d87329aeeda296ae923606e5a4a785/f6188/2019-11-02-orszaghaz-i.webp 200w,\n/static/36d87329aeeda296ae923606e5a4a785/a93fc/2019-11-02-orszaghaz-i.webp 400w,\n/static/36d87329aeeda296ae923606e5a4a785/7c0bb/2019-11-02-orszaghaz-i.webp 600w,\n/static/36d87329aeeda296ae923606e5a4a785/d1e4e/2019-11-02-orszaghaz-i.webp 800w,\n/static/36d87329aeeda296ae923606e5a4a785/730f8/2019-11-02-orszaghaz-i.webp 3708w", "sizes": "(max-width: 400px) 100vw, 400px", "originalImg": "/static/36d87329aeeda296ae923606e5a4a785/b9e8b/2019-11-02-orszaghaz-i.jpg", "originalName": "2019-11-02-orszaghaz-i.jpg", "presentationWidth": 400, "presentationHeight": 297 } } } }, "fields": { "slug": "/orszaghaz-i/", "date": "November 02, 2019", "type": "photo" } } }, { "node": { "id": "2e2c9611-be7b-5bc0-a72b-6c63e2072b5a", "fileAbsolutePath": "/Users/m/Code/blog/content/posts/2019-10-24-ocean-protocol-and-ipfs-sitting-in-the-merkle-tree/index.md", "html": "IPFS is now integrated into the Ocean Protocol stack, allowing you to take advantage of decentralized asset file hosting.
\n\n\nThis article was originally posted on Medium in the Ocean Protocol blog.
\n
With Ocean Protocol, you can use centralized storage services like S3, Azure Storage, or your own On-Premise storage to store and retrieve your asset files through Osmosis drivers in Brizo.
\nBut storing asset files in a centralized service poses multiple problems:
\nInitially created to store and efficiently move scientific data sets, the InterPlanetary File System (IPFS) solves all those issues with its goal of transforming the vastly centralized web into a distributed peer-to-peer network.
\nFiles are distributed among multiple nodes, eliminating the single point of failure, legal, and censorship issues. By using content-based instead of location-based addressing of files, URLs won’t break if files are moved.
\nSo we defined OEP-15 to make the ipfs://
protocol a first-class citizen in the Ocean Protocol stack, allowing you to store asset files on IPFS, and use their native IPFS URLs during the publish process.
In short, every component in the Ocean Protocol stack now supports publishing and consuming of asset files stored in IPFS which includes support for native IPFS URLs, referencing files with their Content Identifiers (CIDs).
\nEvery file stored on IPFS is public by default, so it made perfect sense using this in our Commons Marketplace first. We went through multiple prototypes to end up with our final setup.
\nDuring the publish flow you will find an extended Files section for adding a file from an existing URL, and for adding a local file from your device to IPFS.
\n\nThe existing URL field now supports ipfs://
in addition to http(s)://
so if you have an existing asset on IPFS, you can add it here and everything works as before. With the exception that the asset files will be registered with this native IPFS URL.
The new IPFS drop zone provides a convenient way to add and register unpublished asset files.
\n\nThat drop zone allows you to add a file from your local machine and add it to IPFS during the asset publish flow in a snap:
\n\nFirst, opening up the drop zone area will ping the IPFS node & gateway to check connectivity. Dropping or selecting a file from your device onto that area does a bunch of things in the background:
\nipfs://QmX5LRpEVocfks9FNDnRoK2imf2fy9mPpP4wfgaDVXWfYD/video.mp4
.All these steps are required because of how files in IPFS are distributed among its nodes. When adding a file to a node (note how it’s not called “uploading”) it is only available on that node. Requesting that file from another node will start the distribution process of the file from the initial IPFS node, making it globally available.
\nAlso the consume flow required some changes. Whenever an asset file stored on IPFS is requested to be downloaded, multiple things related to IPFS are happening in Brizo with its shiny new osmosis-ipfs-driver:
\nipfs://
url is mapped to its https://
gateway URL.ipfs://QmPQNaNxHkasNiJBFZht2k3zCEBkvEu1aE5VNGZ8QiT8Nj
), the proper file ending will be added automatically at the end of the download process, based on detected MIME type.While developing this feature, it became clear we need to run our own IPFS node & gateway to have better control over the whole experience. And donating a node instead of taking away bandwidth from the main IPFS gateway (gateway.ipfs.io) felt like the right thing to do to make Juan happy.
\nSo we created ipfs.oceanprotocol.com, run by us (that is, legally speaking, BigchainDB GmbH).
\n\nIt is setup to be a public gateway, and provide some access to its node HTTP API for everyone. This means you can use it to address any content in the IPFS network, like:
\nAt the same time all node API functionality required by Commons is open to the world, so those endpoints can be used by anyone to add files to IPFS:
\n/api/v0/add
/api/v0/version
/api/v0/id
As a start, this is a simple single node but we plan to gradually upgrade ipfs.oceanprotocol.com to a full IPFS Cluster of multiple nodes for best data availability.
\n\nBeside upgrading to an IPFS Cluster there are many ways the process will be improved over time. At the moment the drop zone in Commons only supports single file uploads, so a quick win improvement would be to allow dropping multiple files at once. Likewise, the drop zone using js-ipfs-http-client comes with some bugs when trying to upload larger files.
\nTo make the process of adding files to the IPFS node less dependent on the client browser, it could be moved into a background task in the Commons Server. This should also give more control and feedback for the process of distributing a file from the initial node to other nodes.
\nAnd finally, further work may be done to store files encrypted on IPFS and implement a way to decrypt them in an Ocean Protocol network.
\n\n\nThis article was originally posted on Medium in the Ocean Protocol blog.
\n
Inside the Hungarian Parliament Building in Budapest, Hungary.
", "excerpt": "Inside the Hungarian Parliament Building in Budapest, Hungary.", "frontmatter": { "title": "Országház II", "linkurl": null, "tags": null, "image": { "childImageSharp": { "original": { "src": "/static/2019-11-03-orszaghaz-ii-2dbcf257b4bdf625c24fede935d32425.jpg" }, "fluid": { "aspectRatio": 2.3255813953488373, "src": "/static/2dbcf257b4bdf625c24fede935d32425/ef7a0/2019-11-03-orszaghaz-ii.jpg", "srcSet": "/static/2dbcf257b4bdf625c24fede935d32425/23780/2019-11-03-orszaghaz-ii.jpg 100w,\n/static/2dbcf257b4bdf625c24fede935d32425/02ed9/2019-11-03-orszaghaz-ii.jpg 200w,\n/static/2dbcf257b4bdf625c24fede935d32425/ef7a0/2019-11-03-orszaghaz-ii.jpg 400w,\n/static/2dbcf257b4bdf625c24fede935d32425/ac974/2019-11-03-orszaghaz-ii.jpg 600w,\n/static/2dbcf257b4bdf625c24fede935d32425/12c26/2019-11-03-orszaghaz-ii.jpg 800w,\n/static/2dbcf257b4bdf625c24fede935d32425/24914/2019-11-03-orszaghaz-ii.jpg 3793w", "srcWebp": "/static/2dbcf257b4bdf625c24fede935d32425/a93fc/2019-11-03-orszaghaz-ii.webp", "srcSetWebp": "/static/2dbcf257b4bdf625c24fede935d32425/b0720/2019-11-03-orszaghaz-ii.webp 100w,\n/static/2dbcf257b4bdf625c24fede935d32425/f6188/2019-11-03-orszaghaz-ii.webp 200w,\n/static/2dbcf257b4bdf625c24fede935d32425/a93fc/2019-11-03-orszaghaz-ii.webp 400w,\n/static/2dbcf257b4bdf625c24fede935d32425/7c0bb/2019-11-03-orszaghaz-ii.webp 600w,\n/static/2dbcf257b4bdf625c24fede935d32425/d1e4e/2019-11-03-orszaghaz-ii.webp 800w,\n/static/2dbcf257b4bdf625c24fede935d32425/0a478/2019-11-03-orszaghaz-ii.webp 3793w", "sizes": "(max-width: 400px) 100vw, 400px", "originalImg": "/static/2dbcf257b4bdf625c24fede935d32425/24914/2019-11-03-orszaghaz-ii.jpg", "originalName": "2019-11-03-orszaghaz-ii.jpg", "presentationWidth": 400, "presentationHeight": 300 } } } }, "fields": { "slug": "/orszaghaz-ii/", "date": "November 03, 2019", "type": "photo" } } }, { "node": { "id": "c80697e5-681d-5fcc-9dab-c3a3821ff0b1", "fileAbsolutePath": "/Users/m/Code/blog/content/photos/2019-11-02-orszaghaz-i.md", "html": "The Hungarian Parliament Building seen from across the Danube in Budapest, Hungary.
", "excerpt": "The Hungarian Parliament Building seen from across the Danube in Budapest, Hungary.", "frontmatter": { "title": "Országház I", "linkurl": null, "tags": null, "featured": true, "image": { "childImageSharp": { "original": { "src": "/static/2019-11-02-orszaghaz-i-36d87329aeeda296ae923606e5a4a785.jpg" }, "fluid": { "aspectRatio": 2.3255813953488373, "src": "/static/36d87329aeeda296ae923606e5a4a785/ef7a0/2019-11-02-orszaghaz-i.jpg", "srcSet": "/static/36d87329aeeda296ae923606e5a4a785/23780/2019-11-02-orszaghaz-i.jpg 100w,\n/static/36d87329aeeda296ae923606e5a4a785/02ed9/2019-11-02-orszaghaz-i.jpg 200w,\n/static/36d87329aeeda296ae923606e5a4a785/ef7a0/2019-11-02-orszaghaz-i.jpg 400w,\n/static/36d87329aeeda296ae923606e5a4a785/ac974/2019-11-02-orszaghaz-i.jpg 600w,\n/static/36d87329aeeda296ae923606e5a4a785/12c26/2019-11-02-orszaghaz-i.jpg 800w,\n/static/36d87329aeeda296ae923606e5a4a785/b9e8b/2019-11-02-orszaghaz-i.jpg 3708w", "srcWebp": "/static/36d87329aeeda296ae923606e5a4a785/a93fc/2019-11-02-orszaghaz-i.webp", "srcSetWebp": "/static/36d87329aeeda296ae923606e5a4a785/b0720/2019-11-02-orszaghaz-i.webp 100w,\n/static/36d87329aeeda296ae923606e5a4a785/f6188/2019-11-02-orszaghaz-i.webp 200w,\n/static/36d87329aeeda296ae923606e5a4a785/a93fc/2019-11-02-orszaghaz-i.webp 400w,\n/static/36d87329aeeda296ae923606e5a4a785/7c0bb/2019-11-02-orszaghaz-i.webp 600w,\n/static/36d87329aeeda296ae923606e5a4a785/d1e4e/2019-11-02-orszaghaz-i.webp 800w,\n/static/36d87329aeeda296ae923606e5a4a785/730f8/2019-11-02-orszaghaz-i.webp 3708w", "sizes": "(max-width: 400px) 100vw, 400px", "originalImg": "/static/36d87329aeeda296ae923606e5a4a785/b9e8b/2019-11-02-orszaghaz-i.jpg", "originalName": "2019-11-02-orszaghaz-i.jpg", "presentationWidth": 400, "presentationHeight": 297 } } } }, "fields": { "slug": "/orszaghaz-i/", "date": "November 02, 2019", "type": "photo" } } }, { "node": { "id": "2e2c9611-be7b-5bc0-a72b-6c63e2072b5a", "fileAbsolutePath": "/Users/m/Code/blog/content/posts/2019-10-24-ocean-protocol-and-ipfs-sitting-in-the-merkle-tree/index.md", "html": "IPFS is now integrated into the Ocean Protocol stack, allowing you to take advantage of decentralized asset file hosting.
\n\n\nThis article was originally posted on Medium in the Ocean Protocol blog.
\n
With Ocean Protocol, you can use centralized storage services like S3, Azure Storage, or your own On-Premise storage to store and retrieve your asset files through Osmosis drivers in Brizo.
\nBut storing asset files in a centralized service poses multiple problems:
\nInitially created to store and efficiently move scientific data sets, the InterPlanetary File System (IPFS) solves all those issues with its goal of transforming the vastly centralized web into a distributed peer-to-peer network.
\nFiles are distributed among multiple nodes, eliminating the single point of failure, legal, and censorship issues. By using content-based instead of location-based addressing of files, URLs won’t break if files are moved.
\nSo we defined OEP-15 to make the ipfs://
protocol a first-class citizen in the Ocean Protocol stack, allowing you to store asset files on IPFS, and use their native IPFS URLs during the publish process.
In short, every component in the Ocean Protocol stack now supports publishing and consuming of asset files stored in IPFS which includes support for native IPFS URLs, referencing files with their Content Identifiers (CIDs).
\nEvery file stored on IPFS is public by default, so it made perfect sense using this in our Commons Marketplace first. We went through multiple prototypes to end up with our final setup.
\nDuring the publish flow you will find an extended Files section for adding a file from an existing URL, and for adding a local file from your device to IPFS.
\n\nThe existing URL field now supports ipfs://
in addition to http(s)://
so if you have an existing asset on IPFS, you can add it here and everything works as before. With the exception that the asset files will be registered with this native IPFS URL.
The new IPFS drop zone provides a convenient way to add and register unpublished asset files.
\n\nThat drop zone allows you to add a file from your local machine and add it to IPFS during the asset publish flow in a snap:
\n\nFirst, opening up the drop zone area will ping the IPFS node & gateway to check connectivity. Dropping or selecting a file from your device onto that area does a bunch of things in the background:
\nipfs://QmX5LRpEVocfks9FNDnRoK2imf2fy9mPpP4wfgaDVXWfYD/video.mp4
.All these steps are required because of how files in IPFS are distributed among its nodes. When adding a file to a node (note how it’s not called “uploading”) it is only available on that node. Requesting that file from another node will start the distribution process of the file from the initial IPFS node, making it globally available.
\nAlso the consume flow required some changes. Whenever an asset file stored on IPFS is requested to be downloaded, multiple things related to IPFS are happening in Brizo with its shiny new osmosis-ipfs-driver:
\nipfs://
url is mapped to its https://
gateway URL.ipfs://QmPQNaNxHkasNiJBFZht2k3zCEBkvEu1aE5VNGZ8QiT8Nj
), the proper file ending will be added automatically at the end of the download process, based on detected MIME type.While developing this feature, it became clear we need to run our own IPFS node & gateway to have better control over the whole experience. And donating a node instead of taking away bandwidth from the main IPFS gateway (gateway.ipfs.io) felt like the right thing to do to make Juan happy.
\nSo we created ipfs.oceanprotocol.com, run by us (that is, legally speaking, BigchainDB GmbH).
\n\nIt is setup to be a public gateway, and provide some access to its node HTTP API for everyone. This means you can use it to address any content in the IPFS network, like:
\nAt the same time all node API functionality required by Commons is open to the world, so those endpoints can be used by anyone to add files to IPFS:
\n/api/v0/add
/api/v0/version
/api/v0/id
As a start, this is a simple single node but we plan to gradually upgrade ipfs.oceanprotocol.com to a full IPFS Cluster of multiple nodes for best data availability.
\n\nBeside upgrading to an IPFS Cluster there are many ways the process will be improved over time. At the moment the drop zone in Commons only supports single file uploads, so a quick win improvement would be to allow dropping multiple files at once. Likewise, the drop zone using js-ipfs-http-client comes with some bugs when trying to upload larger files.
\nTo make the process of adding files to the IPFS node less dependent on the client browser, it could be moved into a background task in the Commons Server. This should also give more control and feedback for the process of distributing a file from the initial node to other nodes.
\nAnd finally, further work may be done to store files encrypted on IPFS and implement a way to decrypt them in an Ocean Protocol network.
\n\n\nThis article was originally posted on Medium in the Ocean Protocol blog.
\n