Skip to content

Commit

Permalink
Update IPFS util application
Browse files Browse the repository at this point in the history
  • Loading branch information
dobschal committed Sep 6, 2022
1 parent c94c6e2 commit e50b81f
Showing 1 changed file with 28 additions and 13 deletions.
41 changes: 28 additions & 13 deletions applications/ipfs_utilities.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,22 +17,31 @@ This application is about the utilities of Substrate within IPFS.
IPFS is a web3 solution to store and provide big-sized and not structured data. The datas address (index) is based on it's content, which guarantees that the content or file isn't changed or manipulated in any way. Currently there is no satisfying way of an integration for IPFS on Substrate blockchains.

Currently, the easiest way to record IPFS CIDs on a Substrate-based blockchain, is to call an extrinsic and pass the IPFS CID as an input parameter to store it on chain. The CID is often related to some non-fungible token (NFT), and becomes a metadata of the token.
In NFT scenario, it would need much more affairs to the validation process on the chain side, if the developer wants to make sure and trust the input CID will point to the corresponding file on the chain. Besides that, the CID is listed via gRPC as a string field, it can not be a presented event if the browser already supports IPFS.

In the solution, it will need much more affairs to the validation process on the chain side, if the developer wants to make sure and trust the input CID will point to the corresponding file on the chain. Besides, the CID is listed via gRPC as a string field, it can not be presented event the browser already supports IPFS.
This project will follow a different approach. The upload and linking of a file to an NFT e.g. can be done by clients thru one extrinsic. On upload of a file with the IPFS pallet, the pallet will return the ticket id immediately. Once the file is uploaded to IPFS, the CID of the file on IPFS will be stored on chain. The ticket id and CID both can be used to fetch the file via RPC call. While the upload to IPFS is processing, a cache logic can already provide the file based on the ticket id. Once the CID is retrieved and the file is available on IPFS, the cache can be cleared and all fetch requests are redirected to IPFS.


### Project Details

#### Example: NFT with IPFS hosted file

This is a draft on how to integrate the IPFS util with an NFT. The upload process is async as it takes some time. During upload a ticket id links to the processed file. Once uploaded the CID is used.

![](https://tdsoftware-dev.de/w3f-grant-program/ipfs-util-components.png)

#### Upload utilities
In the first part, detailed research is needed to upload data to IPFS, including
In the first part, detailed research is needed to upload data to IPFS, including:
- Accepting bytes as an input parameter of extrinsic
- Uploading `&[u8]` or `[u8]` to IPFS, may or may not in off-chain worker
- Storing CID information on chain, also the CID version 0 and CID version 1 could be handled
- Uploading `&[u8]` or `[u8]` to IPFS thru an off-chain worker
- Storing CID information on chain
- Handling the CID version 0 and CID version 1
- Benchmarking on the extrinsic call to know the maximum size of bytes can work


#### Read/access utilities
In the second part, the redirect feature will be provided based on the gRPC mechanism, the details are listed
- Accept a function with `Result<String>` return, and take the content of String as the location to redirect
In the second part, the redirect and fetch feature will be provided based on the gRPC mechanism. This will allow users to fetch the linked files from IPGS. The details are listed:
- Accept a function with `Result<String>` as return value, and take the content of String as the location to redirect
- Developer can define the redirect location as CIDv0 or CIDv1.
- Base on Post/Redirect/Get ([PRG](https://en.wikipedia.org/wiki/Post/Redirect/Get)) pattern
- The return code is HTTP 303 See Other
Expand All @@ -53,6 +62,7 @@ Blockchain
- Rust
- IPFS


## Team :busts_in_silhouette:

### Team members
Expand Down Expand Up @@ -109,6 +119,8 @@ Team profiles:

A concept and solution draft was created as part of this application and can be found in the Project Details chapter.

We will reuse as much as possible the existing developed approach from: [offchain::ipfs](https://github.com/w3f/General-Grants-Program/blob/master/grants/speculative/offchain_ipfs.md).
This solution is not handling the CID in a proper way. E.g. instead of returning the CID, it's just logging it out. It also provides the reading of the file thru an extrinsic. As the file is public on IPFS, that is not necessary.


## Development Roadmap :nut_and_bolt:
Expand All @@ -119,37 +131,40 @@ A concept and solution draft was created as part of this application and can be
- **Full-Time Equivalent (FTE):** 2
- **Total Costs:** 89,440 DAI

### Milestone 1 - Research and PoC implementation on upload part
### Milestone 1 - Research and final implementation of file upload feature

- **Estimated duration:** 1 Month
- **FTE:** 2
- **Costs:** 44,720 DAI

After the first research, the PoC pallet implementation will be developed. The goal of milestone 1, is a fully working round trip (except the redirect feature). A PoC client, reading a file, calling an extrinsic and uploading the content of a file,, will be developed. The CID information from IPFS will be stored in the pallet, then the uploaded file is verified by other IPFS tools.
After the first research, the pallet implementation will be developed. The goal of milestone 1, is a fully working round trip (except the redirect feature). A web3 client, reading a file, calling an extrinsic and uploading the content of a file, will be developed. The CID information from IPFS will be stored in the pallet, then the uploaded file is verified by other IPFS tools.

Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense |
| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a developer can re-use the implementation. |
| 0c. | Testing | Core functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests. |
| 1. | Implement IPFS upload extrinsic | The pallet implementation will be added, that allow bytes to uploads. |
| 2. | Implement POC client | The client can read data from file, call extrinsic and upload the content in bytes. |
| 3. | Verification | Verify the file uploaded |
| 1. | Implement IPFS upload extrinsic | The pallet implementation will be added, that allows to upload bytes of files to IPFS. The data will be cached to provide it during processing. This will return a ticket id for the file. Once uploaded the CID is available too. |
| 2. | Implement client | The web3 client app can read data from file, call extrinsic and upload the content in bytes. |
| 3. | Verification | Verify the file uploaded and store the CID on chain. |

### Milestone 2 - PoC implementation on redirect part

- **Estimated Duration:** 1 Month
- **FTE:** 2
- **Costs:** 44,720

The goal of the second milestone is to redirect utilities of Substrate. A gRPC request can be based on a PRG mechanism to redirect to any file server, which is not limited by IPFS.
The goal of the second milestone is to redirect utilities of Substrate. A gRPC request can be based on a PRG mechanism to redirect to any file server, which is not limited by IPFS. A cache will be added to allow fetching the file, when the upload to IPFS is still in progress.

Number | Deliverable | Specification |
| -----: | ----------- | ------------- |
| 0a. | License | Apache 2.0 / GPLv3 / MIT / Unlicense |
| 0b. | Documentation | We will provide both **inline documentation** of the code and a basic **tutorial** that explains how a developer can re-use the implementation. |
| 0c. | Testing | Core functions will be covered by unit tests as far as reasonably applicable to ensure functionality and robustness. In the documentation, we will describe how to run these tests. |
| 1. | Implement | `#[prg(name = "nft_getFileById")]` will be designed and developed that allows users to redirect a request, which returns `Result<String>`, to a file server. |
| 0d. | Code | We will provide the whole code in a public GitHub repository. |
| 0e. | Article | We will write and publish a Medium article to spread the word and give developers an introduction to the project and how to use it. |
| 1. | Implement Fetch File | E.g. `#[prg(name = "nft_getFileById")]` will be designed and developed that allows users to redirect a request, which returns `Result<String>`, to a file server. |
| 2. | Implement Cache | Implement a file cache, that returns the file if upload to IPFS is still in progress. |



Expand Down

0 comments on commit e50b81f

Please sign in to comment.