-
Notifications
You must be signed in to change notification settings - Fork 1.3k
🌟 Parity to IPFS #763
Comments
from parity
while thats running, you can make requests by cid
|
i made this util to help with this https://github.com/kumavis/eth-ipld |
@kumavis let's pick up on this again, now that we have datastore bubbling up all the way :) |
whee |
seems simple enough https://github.com/ipfs/js-datastore-level how do you mount multiple stores? and can you mount one as read-only? |
also - do you have a preferred isomorphic xhr module? otherwise ill use what i usually do |
We shim The code for reaching to the block store, given that it exposes the same API as go-ipfs does for blocks, is exactly what js-ipfs-api does https://github.com/ipfs/js-ipfs-api/blob/master/src/api/block.js On Right now, ipfs-repo is mounting a single datastore for the blockstore (blocks folder) https://github.com/ipfs/js-ipfs-repo/blob/master/src/index.js#L136-L139, which is them used throughout blockstore code: https://github.com/ipfs/js-ipfs-repo/blob/master/src/blockstore.js#L34-L137 Tasks:
Note: blockstore will pass a base32 encoded CID to your parity-datastore, which you then have to decode to send through the js-ipfs-api block.get. |
would be nice if js-ipfs-repo's data store could be specified externally somehow |
Agreed, right now the decision is being made inside the ipfs-repo module by signalling through the browser property in the package.json, here: https://github.com/ipfs/js-ipfs-repo/blob/master/package.json#L8 I would rather have those options passed in, so that we can hot swap it per application basis, just like libp2p bundles. |
would be nice if we could boot the http api by passing in an instance of an ipfs node, instead of it needing to boot its own |
for now, i think this will work for ipfs-repo's datastore but NotAGoodIdea™ node.on('ready', () => {
console.log('node ready!')
// hacky late add to MountStore
console.log('Adding mount to Parity')
repo.store.mounts.push({
prefix: new Key('/'),
datastore: new RemoteIpfsDataStore({host: 'localhost', port: '5002', protocol: 'http'})
})
setupHttpApi()
}) |
hmmm seems bitswap is somehow not using my late-mounted datastore |
ipfs-inactive/js-ipfs-http-client#550 ( not blocking, using a string as a workaround ) |
ipfs-api uses POST for all requests, parity only implements GET for API spec seems to indicate it should be a GET |
PR for the http method fix here ipfs-inactive/js-ipfs-http-client#551 |
Remaining IPFS todo's
optional:
attn @diasdavid |
i have it working and deployed (via patched deps) https://github.com/kumavis/ipfs-eth-bridge |
Checked the boxes that are already done
Yeah, just call it @kumavis did you manage to figure out the bug of the other day? |
because of the GET/POST mismatch, ended up making a "read-only-hooked datastore" module, used here: https://github.com/kumavis/ipfs-eth-bridge/blob/master/index.js#L24-L39 |
@kumavis What are the next steps? |
how can I find the block data in IPFS format when i use parity with --ipfs-api --ipfs-api-hosts all? |
Currently, you can only get block headers, block lists, uncles, transactions, and the state-trie node. |
Do i need an ipfs instance running? if not, how the eth data is encode to ipfs data format? |
You need a Parity node running with IPFS enabled. There is no need for an additional IPFS node unless you want to access other content/APIs via IPFS. |
Is the eth data not saved in ipfs format? Is there no ipfs store indeed? I can't get any data directory about ipfs info, but when i start an additional ipfs node, i can find data in ~/.ipfs/ directory, so where is partiy's ipfs data store? |
It would be amazing to have a package on npm that downloads the Parity client and exposes the datastore with it to access the Eth network so that we can create a quick example on how to set it up. Does this sound like something you can handle in the near future, @kumavis @hermanjunge? |
That's right @diasdavid. This is one of our main pain points for the ethereum browser light client currently. I am working on extracting the functions I need from go-ethereum to store the K-V data into a Redis DB cluster. It would be nice to have a slim parity client version that synchronizes to the network, to store the data into a database we can easily mount as an IPFS client datastore. For now, we have this docker compose package to do the trick, is a js-ipfs client that mounts the parity HTTP IPFS, that way we can access eth dag nodes one by one. The ideal, of course, is unleash more capabilities. https://github.com/kumavis/ipfs-eth-bridge/blob/master/mustekala/docker-compose.yml |
Great work |
js-ipfs is being deprecated in favor of Helia. You can #4336 and read the migration guide. Helia accepts implementations of Closing as not planned but I would love to see this in a usable state still. |
Goal: Add a 'Storage Backend' for js-ipfs that backed by Parity, the Rust implementation of Ethereum. This will enable js-ipfs nodes to fetch content from the Ethereum Network as if it was just a big bucket with all the blocks from the chain.
TASKS
The text was updated successfully, but these errors were encountered: