IPLD and Compatibility slide: https://hackmd.io/@adin/ipld-compat The Vision Use IPFS to move around any hash-linked data Existing (or future) formats like Git, BitTorrent, OCI containers, check-summed files, etc. The Problems

slides: https://hackmd.io/@adin/wasm-ipld#/ What we have WAC Codec (Complete + Fitted IPLD Codec designed for moving data in/out of WASM) Bencode WASM codec BitTorrent File WASM ADL WAC - Motivation WebAssembly Codec (better name TBD)

slides: https://hackmd.io/@adin/bt-ipld#/ What we have ADL Plugin in go-ipfs Bencode codec BitTorrent v1 file ADL Gateway patch for rendering any IPLD node presenting as Bytes as a file Code (location likely to change):

[x] github.com/ipfs/go-datastore [x] github.com/ipfs/go-ds-badger github.com/ipfs/go-datastore [x] github.com/ipfs/go-ds-leveldb github.com/ipfs/go-datastore [x] github.com/libp2p/go-libp2p-peerstore

Slides slide: https://hackmd.io/@adin/H18k1e7OK#/ Infra Network Infrastructure Help the browsers :newspaper: Public HTTP Gateways Preload Nodes

[x] Merge + tag fs-repo-migrations [x] ipfs/distributions for fs-repo-migrations [x] run against master [x] deploy [x] PR to ipfs/distributions [x] pinbot [x] PR to protocol/infra

Background We are designing IPLD to be a general framework for working with content-addressed and content-linked data. While we have designed some of our own formats and preferences (i.e. DagPB, DagCBOR, etc.) we also endeavor to be compatible with existing formats as long as they use content based linking (i.e. Bitcoin, Ethereum, Git, etc.) Problem In trying to interoperate with existing systems sometimes we come across content addressed data which while IPLD can technically handle IPFS cannot. The biggest offender in this regard is block size. While IPFS has a maximum block size of 1MiB (it's actually more like 2, but we recommend people go with 1 to be safe), some systems like Git have blocks that are much larger (apparently GitHub allows up to 100 MiB). This means that while all content addressed data can be added to a local IPFS node it cannot actually be communicated over the network. Why do we have a (1MiB) maximum block size? Without a maximum block size there's nothing stopping an attacker from sending us lots of bogus data. With a maximum block size we are ( theoretically since AFAIK we don't actually implement this in go-ipfs) able to just block peers that send us blocks that we don't want with a fixed cost. Without a maximum block size we could ask for CID bafyabc and be sent a never ending stream of data. While this attack costs the attacker in upload bandwidth, it's still something we'd like to prevent.

Normally used as a binary that runs on your machine with CLI + HTTP API interfaces More advanced usage by utilizing go-ipfs as a library or build go plugins is possible Doing a walkthrough with the CLI, but almost anything you can do with the CLI can also be done with the HTTP API Terminals Start up two terminals ipfs id, we're running a libp2p node here are stats ipfs add/get/cat/ls

Local Pinning All commands under ipfs pin local add <ipfs-path> [--name=<name>] [--meta=<json>] [--type={recursive, direct}] Name is restricted to UTF-8 and <= 255 characters multiple pins can have the same name Meta field can be implemented later

SHA(x,y)=z SHA[x1|x2|...|xn] = SHA(SHA[x1|...|x(n-1)], xn) parent = { SHA} Root = DAG'(X) from above Proof computed using X Instead of Normal: CID(DAG(X)), use CID(DAG(Y)) // ref_to_oneblock: SHA(SHA[x1|...|x(n-1)],xn) = SHA[x1|...|xn]