Getting Started with IPFS

IPFS Documentation

Step1: Installation
Step2: Basic Use

Concepts:

1.Content Identifiers (CIDs): is a label used to point to material in IPFS. It doesn’t indicate where the content is stored, but it forms a kind of address based on the content itself. CIDs are short, regardless of the size of their underlying content.

CIDs are based on the content’s cryptographic hash ( SHA-1 (used by Git), SHA-256, or BLAKE2).

2. CID formats

Version 0
When IPFS was first designed, we used base 58-encoded multihashes as the content identifiers (This is simpler, but much less flexible than newer CIDs). CIDv0 is still used by default for many IPFS operations, so you should generally try to support v0. If a CID is 46 characters starting with “Qm”, it’s a CIDv0.

Version 1
CID v1 contains some leading identifiers that clarify exactly which representation is used, along with the content-hash itself. These include:

• A multibase prefix, specifying the encoding used for the remainder of the CID
• A CID version identifer, which indicates which version of CID this is
• A multicodec identifier, indicating the format of the target content — it helps people and software to know how to interpret that content after the content is fetched

3. DNSLink

DNSLink uses DNS TXT records to map a domain name (like ipfs.io) to an IPFS address.

Because you can edit your DNS records, you can use them to always point to the latest version of an object in IPFS (remember that an IPFS object’s address changes if you modify the object).

Because DNSLink uses DNS records, the names it produces are also usually easy to type and read.

A DNSLink address looks like an IPNS address, but it uses a domain name in place of a hashed public key:

/ipns/ipfs.io

Just like normal IPFS addresses, they can include links to other files:

/ipns/ipfs.io/media/

When an IPFS client or node attempts to resolve that address, it looks for a TXT record for ipfs.io with content like:

dnslink=/ipfs/<CID for your content here>

For example, if you look up ipfs.io’s DNS records, you’ll see its DNSLink entry:

$ dig +noall +answer TXT ipfs.io ipfs.io.  59 IN TXT "dnslink=/ipfs/QmYNQJoKGNHTpPxCBPh9KkDpaExgd2duMa3aF6ytMpHdao"

Based on that, this address:

/ipns/ipfs.io/media/

Will get you this block:

/ipfs/QmYNQJoKGNHTpPxCBPh9KkDpaExgd2duMa3aF6ytMpHdao/media/

Publishing via a Subdomain

You can also publish DNSLink records using a special subdomain named _dnslink. This is useful when you want to improve the security of an automated setup or delegate control over your DNSLink records to a third-party without giving away full control over the original DNS zone.

For example, docs.ipfs.io does not have a TXT record, but the page still loads because a TXT record exists for _dnslink.docs.ipfs.io:

$ dig +noall +answer TXT _dnslink.docs.ipfs.io _dnslink.docs.ipfs.io.  34  IN  TXT "dnslink=/ipfs/QmeveuwF5wWBSgUXLG6p1oxF3GKkgjEnhA6AAwHUoVsx6E"

4. Hashes

Hashes are functions that take some arbitrary input and return a fixed-length value. The particular value depends on the given hash algorithm in use, such as SHA-1 (used by Git), SHA-256, or BLAKE2, but a given hash algorithm always returns the same value for a given input. Have a look at the full list of hash functions for more.

As an example, the input:

Hello world

would be represented by SHA-1 as: (creates a 160 bit hash)

0x7B502C3A1F48C8609AE212CDFB639DEE39673F5E

However, the exact same input generates the following output using SHA-256: (creates a 256 bit hash)

0x64EC88CA00B268E5BA1A35678A1B5316D212F4F366B2477232534A8AECA37F3C

Hashes can be represented in different bases (base2, base16, base32, etc.). In fact, IPFS makes use of that as part of its Content Identifiers and supports mulitiple base representations at the same time, using the Multibase protocol.

Characteristics of cryptographic hashes

Cryptographic hashes come with a couple of very important characteristics:

• deterministic — the same input message always returns exactly the same output hash
• uncorrelated — a small change in the message should generate a completely different hash
• unique — it’s infeasible to generate the same hash from two different messages
• one-way — it’s infeasible to guess or calculate the input message from its hash

It turns out these features also mean we can use a cryptographic hash to identify any piece of data: the hash is unique to the data we calculated it from and it’s not too long (a hash is a fixed length, so the SHA-256 hash of a 1 Gigabyte video file is still only 32 bytes), so sending it around the network doesn’t take up a lot of resources.

4. IPNS

Inter-Planetary Name System (IPNS) is a system for creating and updating mutable links to IPFS content. Since objects in IPFS are content-addressed, their address changes every time their content does. That’s useful for a variety of things, but it makes it hard to get the latest version of something.

A name in IPNS is the hash of a public key. It is associated with a record containing information about the hash it links to that is signed by the corresponding private key.

When looking up an IPNS address, use the /ipns/ prefix:

/ipns/QmSrPmbaUKA3ZodhzPWZnpFgcPMFWF4QsxXbkWfEptTBJd

IPNS is not the only to create mutable addresses on IPFS. You can also use DNSLink (which is currently much faster than IPNS and also uses more readable names).

5. Mutable File System (MFS)

Because files in IPFS are content-addressed and immutable, they can be complicated to edit. Mutable File System (MFS) is a tool built into IPFS that lets you treat files like you would a normal name-based filesystem — you can add, remove, move, and edit MFS files and have all the work of updating links and hashes taken care of for you.

MFS is accessed through the files commands in the IPFS CLI and API.

6. Pinning

IPFS nodes treat the data they store like a cache, meaning that there is no guarantee that the data will continue to be stored. Pinning a CID tells an IPFS server that the data is important and mustn’t be thrown away.

You should pin any content you consider important, to ensure that content is retained long-term. Since data important to someone else may not be important to you, pinning lets you have control over the disk space and data retention you need.

7. UnixFS

A file in IPFS isn’t just content. It might be too big to fit in a single block, so it needs metadata to link all its blocks together. It might be a symlink or a directory, so it needs metadata to link to other files. UnixFS is the data format used to represent files and all their links and metadata in IPFS, and is loosely based on how files work in Unix. When you add a file to IPFS, you are creating a block (or a tree of blocks) in the UnixFS format.

UnixFS is a protocol-buffers-based format. You can find the definitions for it at: https://github.com/ipfs/go-ipfs/blob/master/unixfs/pb/unixfs.proto.

Basic Examples:

https://ipfs.io/ipfs/QmP79iV1oLZ6TgHtQM3uypjPjayLM14TX3of8ZwtSVsuKn

Siraj IPFS Demo:

Example: Building a Fully Decentralised Application with IPFS

Watch full tutorial here: http://www.dappuniversity.com/articles/the-ultimate-ethereum-dapp-tutorial

Full

Here is the short tutorial that let you get started quickly

short

Install dependencies
# node
$ node -v
# install truffle
$ node install -g truffle

install Ganache

Truffle Suite | Ganache

https://truffleframework.com/boxes

https://truffleframework.com/boxes/pet-shop

install Metamask

MetaMask

Now let’s create a project directory for our dApp in the command line like this:

$ mkdir election
$ cd election

Now that we’re inside our project, we can get up and running fast with a Truffle box. We’ll be using the Pet Shop box for this tutorial. From within your project directory, install the pet shop box from the command line like this:

$ truffle unbox pet-shop

Let’s see what the pet shop box gave us:

• contracts directory: this is where all smart contacts live. We already have a Migration contract that handles our migrations to the blockchain.
• migrations directory: this is where all of the migration files live. These migrations are similar to other web development frameworks that require migrations to change the state of a database. Whenever we deploy smart contracts to the blockchain, we are updating the blockchain’s state, and therefore need a migration.
• node_modules directory: this is the home of all of our Node dependencies.
• src directory: this is where we’ll develop our client-side application.
• test directory: this is where we’ll write our tests for our smart contracts.
• truffle.js file: this is the main configuration file for our Truffle project

Start writing Smart Contract (contain business logic of dApp)

• smart contract will contain all the business logic of our dApp
• It will be in charge reading from and write to the Ethereum blockchain
• will allow us to list the candidates that will run in the election, and keep track of all the votes and voters

$ truffle migrate --reset

Now that we have successfully migrated our smart contract to the local Ethereum blockchain, let’s open the console to interact with the smart contract. You can open the truffle console from the command line like this:

$ truffle console

Now that we’re inside the console, let’s get an instance of our deployed smart contract and see if we can read the candidate’s name from the contract. This come from smart contract that we wrote

let’s continue building out the smart contact by listing out the candidates that will run in the election. We need a way to store multiple candidates, and store multiple attributes about each candidate. We want to keep track of a candidate’s id, name, and vote count. Here is how we will model the candidate:

#TODO

Next start development server

then create dist folder

then copy file to dist folder

$ rsync -r src/ dist/
$ rsync -r build/contracts/ dist/
$ ls -l dist/

start IPFS server

$ ipfs swarm peers
$ ipfs add -r dist/

$ ipfs name publish QmTUqXV1Jf8Qedm7vAoSadfUcekJEKstShk2HBvseTG8y5

https://gateway.ipfs.io/ipfs/QmTUqXV1Jf8Qedm7vAoSadfUcekJEKstShk2HBvseTG8y5/