Giter Club home page Giter Club logo

js-dag-service's Introduction

DAGService

Chat on IRC Chat on Matrix GitHub package.json version npm (scoped) Release docs standard-readme compliant

DAGService is a library for storing and replicating hash-linked data over the IPFS network.

DAGService is aiming to be a bare minimum needed for IPLD-based applications to interact with the IPFS network by getting and putting blocks to it.

NOTE For now, this is a highly experimental library. Use with caution.

This project was originally developed under the @textileio organization, and was contributed to the IPFS community for ongoing maintenance and development.

Table of Contents

Background

The goal of DAGService to provied a minimal layer between data model of IPLD and full blown IPFS. It provides bare minimum functionality for any application to interact with the IPFS network (by getting and putting IPLD blocks) without having to deal with the complexities of operating a full IPFS node. It is an attempt to remake core piece of IPFS node reusable on it's own.

Why?

Because 99% of the time, a browser or mobile (d)App only needs to be able to add and get small bits of data over the IPFS network. This library provides that, in a much smaller package (currently less than 1/2 the size of js-ipfs without much optimization -- we will continue to optimize further). It is also highly extensible, so developers need only include the features they need, keeping load times fast, and (d)Apps feeling snappy. Additionally, Textile needed a Typescript-based IPFS solution, and we think others will find the type safety useful as well. Feel free to use the Typescript declarations in your own projects.

Install

npm install dag-service

Usage

import { Peer, BlockStore } from "dag-service"
// Use any interface-datastore compliant store
import { MemoryDatastore } from "interface-datastore"
import Libp2p from "libp2p"

const store = new BlockStore(new MemoryDatastore())

const main = async () => {
  // Bring your own libp2p host....
  const host = new Libp2p({ ...libp2Options })
  const lite = new Peer(store, host)

  await lite.start()

  const cid = "QmWATWQ7fVPP2EFGu71UkfnqhYXDYH566qy47CnJDgvs8u"
  const data = await lite.getFile(cid)
  console.log(data.toString())
  // Hello World
  await lite.stop()
}

There are also several useful examples included in the tests of this repo, with tools for creating a default libp2p host exported by default. We've also thrown in some useful interfaces to use when building on IPFS Lite, as well as the Buffer API for use in the browser.

API

See https://ipfs.github.io/js-dag-service/

Maintainers

Contribute

Feel free to dive in! Open an issue or submit PRs.

To contribute to IPFS in general, see the contributing guide.

Project follows the IPFS Community Code of Conduct

License

The js-dag-service project is dual-licensed under Apache 2.0 and MIT terms:

js-dag-service's People

Contributors

andrewxhill avatar carsonfarmer avatar dependabot-preview[bot] avatar dependabot[bot] avatar gozala avatar ipfs-mgmt-read-write[bot] avatar mithray avatar pcowgill avatar web-flow avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

js-dag-service's Issues

Migrating this repo to ipfs-shipyard

We should do #336 before migrating this anywhere (or maybe it can be part of it, can't remember if you can do the rename).

If we want to explore ipfs/notes#436 based on this project I think it would make sense to migrate it (or fork it) into https://github.com/ipfs-shipyard/

Alternatively we could consider creating separate org as both IPLD and IPFS projects have one. I do not personally have strong preferences where to migrate or whether to just iterate over this here, but this did come up multiple times so I think it's best to have discussion here.

Clean-up ipfs-lite projects

  • Create common table across four repos to point users to the right way to use
  • Clean up js-ipfs-lite test suite to understand browser capabilities

Better browser builds and ES6 module support

Ideally, we'd take a page from the https://github.com/multiformats/js-multiformats book and support cjs, esm, etc builds via rollup and friends to support multiple platforms/use-cases. Since this is designed to be a light-weight alternative to other ipds-based libraries, it should have a really low barrier to usage out of the box. In fact, moving forward, this should be a pretty critical requirement. Further (planned) dependency reduction will help here significantly, but we need a sustainable path to ESM builds that makes it really easy to consume this lib.

See also #73 and #74

React-Native support

Describe the bug
Uncaught Error
Cannot read property '__extends' of undefined

To Reproduce
Setup a RN project with rn-nodeify with following post-install script
"postinstall": "rn-nodeify --install events,dgram --hack"
rm -rf ./node_modules
npm install
cd ios
pod deintegrate
pod install

import { BlockStore,Peer } from '@textile/ipfs-lite'
import { MemoryDatastore } from '@textile/ipfs-lite/dist/setup/index.js';

const store = new BlockStore(new MemoryDatastore()); <-- error
const lite = new Peer(store, host);
await lite.start()

Expected behavior

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • iOS 17.0

Smartphone (please complete the following information):

  • Device: [e.g. iPhone6]
  • OS: iOS 17.0

Additional context
Add any other context about the problem here.

Start pulling in all the new types...

Lets rename this project to a thing that better represents what it is

As per ipfs/notes#436 I would love to use ipfs-lite as foundation for IPLD with persistence and (IPFS) network. However I think ipfs-lite is a controversial because it sets up wrong expectations for API (compatibility) and inter-op.

I think it would be a good idea to recognize this as a separate layer in the IPFS stack and give it it's own name & attempt to design best API for the DAG storage & replication without being tied to on that IPFS exposes today.

[error] bad ES6 import paths in "modular" example code in README?

Disclaimer: I could be wrong about this, because personally.. I only use CommonJS module imports.

But.. I was looking at the README and noticed that the ES6 module import paths don't jive with the directory structure published to npm.

Specifically, every instance of:
from '@textile/ipfs-lite/

...should be replaced by:
from '@textile/ipfs-lite/dist/

..unless ES6 module imports are somehow smart enough to search paths relative to main in package.json when the verbatim path isn't found, which I highly doubt.. but can't say for sure.

PLEASE remove dist folder from .gitignore

Please, just simply remove the dist line from .gitignore, it would be SOOOO helpful so that you git repo will include a prebuilt file that can be used in the browser.

When trying to build this, I am forced to download Chromium(ugh, WHY?!?!, why download 120mb just to build this?), and webpack throws errors at me about peer dependencies I need to manually install. In addition I have multiple versions of webpack installed and none of them are detected. I could work this out, but it's a pain to do this with many dependencies!

In addition to this, maybe it does compile for me finally, what's to say a space is missing, I get a different hash, and then the file isn't massively available from IPFS peers? Doesn't it make so much more sense on a content addressed network to have widely shared official, canonical versions ?

import 'ipfs-lite' caused BUNDLE error with metro resolver in React Native

Describe the bug

      import { Peer, BlockStore } from '@textile/ipfs-lite/core';
      import { setupLibP2PHost, MemoryDatastore } from '@textile/ipfs-lite/setup/';

The import statements above causes path related error:

  [Tue May 19 2020 16:23:51.370]  BUNDLE  ./index.js
  error: TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received     type boolean (false)
   at validateString (internal/validators.js:117:11)
   at Object.dirname (path.js:583:5)
   at resolveFileOrDir (C:\D\code\js\ipat_js\node_modules\metro-resolver\src\resolve.js:256:24)
   at Object.resolve (C:\D\code\js\ipat_js\node_modules\metro-resolver\src\resolve.js:151:20)
   at ModuleResolver.resolveDependency (C:\D\code\js\ipat_js\node_modules\metro\src\node-   haste\DependencyGraph\ModuleResolution.js:143:31)
   at ResolutionRequest.resolveDependency (C:\D\code\js\ipat_js\node_modules\metro\src\node-   haste\DependencyGraph\ResolutionRequest.js:52:18)
   at DependencyGraph.resolveDependency (C:\D\code\js\ipat_js\node_modules\metro\src\node-   haste\DependencyGraph.js:287:16)
   at Object.resolve (C:\D\code\js\ipat_js\node_modules\metro\src\lib\transformHelpers.js:267:42)
   at C:\D\code\js\ipat_js\node_modules\metro\src\DeltaBundler\traverseDependencies.js:434:31
   at Array.map (<anonymous>)

To Reproduce
Steps to reproduce the behavior:

  1. Create a React Native app
  2. install rn-nodeify and all shims
  3. Install ipfs-lite
  4. Add the import in App.js and launch the app

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS] Win10
  • React Native 0.62.2
  • Nodejs : 12.16
  • Browser [e.g. chrome, safari]
  • Version [e.g. 22]

Smartphone (please complete the following information):

  • Device: [e.g. iPhone6] Android 8.1 simulator
  • OS: [e.g. iOS8.1] Android 8.1
  • Browser [e.g. stock browser, safari]
  • Version [e.g. 22]

Additional context

package.json:

{
"name": "ipat_js",
"version": "0.0.1",
"private": true,
"scripts": {
"android": "react-native run-android",
"ios": "react-native run-ios",
"start": "react-native start",
"test": "jest",
"lint": "eslint .",
"postinstall": "./node_modules/.bin/rn-nodeify --install fs,path,process,buffer,crypto,stream,vm --hack"
},
"dependencies": {
"@textile/ipfs-lite": "^0.1.6",
"@tradle/react-native-http": "^2.0.0",
"assert": "^1.1.1",
"browserify-zlib": "^0.1.4",
"buffer": "^4.9.1",
"console-browserify": "^1.1.0",
"constants-browserify": "^1.0.0",
"dns.js": "^1.0.1",
"domain-browser": "^1.1.1",
"events": "^1.0.0",
"https-browserify": "0.0.1",
"path-browserify": "0.0.0",
"process": "^0.11.0",
"punycode": "^1.2.4",
"querystring-es3": "^0.2.1",
"react": "16.11.0",
"react-native": "0.62.2",
"react-native-crypto": "^2.1.0",
"react-native-level-fs": "^3.0.0",
"react-native-os": "^1.0.1",
"react-native-randombytes": "^3.0.0",
"react-native-tcp": "^3.2.1",
"react-native-udp": "^2.1.0",
"readable-stream": "^1.0.33",
"stream-browserify": "^1.0.0",
"string_decoder": "^0.10.31",
"timers-browserify": "^1.0.1",
"tty-browserify": "0.0.0",
"url": "^0.10.3",
"util": "^0.10.4",
"vm-browserify": "0.0.4"
},
"devDependencies": {
"@babel/core": "^7.9.6",
"@babel/runtime": "^7.9.6",
"@react-native-community/eslint-config": "^1.1.0",
"babel-jest": "^25.5.1",
"eslint": "^6.8.0",
"jest": "^25.5.3",
"metro-react-native-babel-preset": "^0.59.0",
"react-test-renderer": "16.11.0",
"rn-nodeify": "^10.2.0"
},
"jest": {
"preset": "react-native"
},
"react-native": {
"zlib": "browserify-zlib",
"console": "console-browserify",
"constants": "constants-browserify",
"crypto": "react-native-crypto",
"dns": "dns.js",
"net": "react-native-tcp",
"domain": "domain-browser",
"http": "@tradle/react-native-http",
"https": "https-browserify",
"os": "react-native-os",
"path": "path-browserify",
"querystring": "querystring-es3",
"fs": "react-native-level-fs",
"_stream_transform": "readable-stream/transform",
"_stream_readable": "readable-stream/readable",
"_stream_writable": "readable-stream/writable",
"_stream_duplex": "readable-stream/duplex",
"_stream_passthrough": "readable-stream/passthrough",
"dgram": "react-native-udp",
"stream": "stream-browserify",
"timers": "timers-browserify",
"tty": "tty-browserify",
"vm": "vm-browserify",
"tls": false
},
"browser": {
"zlib": "browserify-zlib",
"console": "console-browserify",
"constants": "constants-browserify",
"crypto": "react-native-crypto",
"dns": "dns.js",
"net": "react-native-tcp",
"domain": "domain-browser",
"http": "@tradle/react-native-http",
"https": "https-browserify",
"os": "react-native-os",
"path": "path-browserify",
"querystring": "querystring-es3",
"fs": "react-native-level-fs",
"_stream_transform": "readable-stream/transform",
"_stream_readable": "readable-stream/readable",
"_stream_writable": "readable-stream/writable",
"_stream_duplex": "readable-stream/duplex",
"_stream_passthrough": "readable-stream/passthrough",
"dgram": "react-native-udp",
"stream": "stream-browserify",
"timers": "timers-browserify",
"tty": "tty-browserify",
"vm": "vm-browserify",
"tls": false
},
"metro": {
"resolver": {

  }
}

}

API Design Discussion

As per ipfs/notes#436 I would like to use ipfs-lite as a foundation for providing IPLD storage & replication system. At the same time I would like to use this as an opportunity to explore / design API fit best for that system instead of trying to provide backwards compatibility with ipfs.dag and ipfs.block APIs that were designed for different set of constraints and use cases. Here is a my short (constraint / wish) list:

  • Interops with (new) IPLD stack instead of mimicing or wrapping it.

    E.g ipfs.dag under the hood creates IPLD BLocks, serializes them and stores them. Instead we should just take serializable IPLD Block and store it's bytes.

  • Interop layer should be extremely minimal to reduce coordination to a bare minimum.

    E.g. Block API could change and may have many bells and whistles, instead of assuming Block instances we should have a minimal Block interface that can be serialized, identified, ...

  • Interop layer should enable case specific Block implementations

    This should be achieved from the above goal, but I wanted to calling it out explicitly.

  • Designed for multi-threaded use.

    Copying things across threads in JS can be costly. API should consider that and create a room for optimizations. That means instead of blocks telling how to consume data they should allow flexibility for a consumer to choose a best way to consume it. E.g Web Response is good example allowing consumer to consume it as stream, blob, text etc... while AsyncIterable<Uint8Array> is not because:

    • It can be read only in one way
    • It is impossible to tell if underlying content is in memory or being allocated as it's being consumed.
    • It provides no information about the amount of content.
    • It provides no context regarding if individual chunks can be consumed (transferred) or need to be copied.
    • Isn't peekable
  • First class batching

    • js-ipfs uses AsyncIterables to put consumer in control providing (pull interface).
    • New car format is used to pack multiple blocks and push them out in one go (push interface).

    What we need is a first class primitive for representing multiple blocks which

    • Allows consumer to pull on it's own schedule.
    • Allow producer to push multiple blocks on it's own schedule.
    • Allows application author decide how tightly two should coordinate.

    This may seem familiar

peer-info dependency issue

I haven’t been able to dig in too deep and I’ve found workaround for now, but there’s a dependency issue somewhere with peer-info.

When I try to setup libp2p w/ the latest js-ipfs-lite I see “callback is a not a function error” because the version of peer-info in node_modules is 0.15.x and pre-dates the promises work. 0.17.x is in the devDependencies of js-ipfs-lite so you probably don’t see this during local testing. Maybe the main project, but perhaps a dependency of the main project, is not actually depending on peer-info in package.json and relying on it being installed by another package which opened the door to this version mismatch.

path could not be found within the project.

I have initialized a project from react native in typescript template.
Now when I am writing these lines for import :

import { Peer, BlockStore } from '@textile/ipfs-lite';
//Use any interface-datastore compliant store;
import { MemoryDatastore } from 'interface-datastore';
import Libp2p from 'libp2p';

const store = new BlockStore(new MemoryDatastore());

Then when i do runandroid i get
Error: Unable to resolve module path from node_modules/interface-datastore/src/utils.js: path could not be found within the project.

What should I do?

Re-license to MIT + Apache 2

Following ipfs/kubo#6302 path which determined that dual-licensing as MIT and Apache 2 is a best practice.

This has two major benefits:

  • There are concerns in the open source community about whether the MIT license leaves users vulnerable to patent infringement claims. We think the pure legal risk is small, but the way the open source community interacts with our project is really important. It makes sense to pick the license that makes the largest number of people comfortable.
  • There's now no reason to adopt a separate DCO, since the Apache-2 license grant addresses the same issue.

Why use a dual license, instead of just Apache-2? The Apache-2 license is incompatible with the GPLv2 license, which includes things like the Linux kernel. With a dual license, GPLv2 projects can just use the MIT license instead. Our goal is to make our software available to as many projects as possible, so we'd rather adopt a licensing scheme that doesn't exclude anyone.

What we need to do:

I have updated the licenses in #381 , the next step is to get an explicit OK from our current and past contributors to consent to the relicensing. To keep track of things, below is a contributor sign-off list. Contributors can either check the box next to their github handle, or comment on this issue thread with the following text:

I license past and future contributions under the dual MIT/Apache-2.0 license, allowing licensees to choose either at their option.

Pull the `setup` module into its own submodule w/ its own deps

This will decrease the size of the overall lib bundle for those that don't need automagic setup things, and also simplifies the browser/node end of things (separate main/browser entries). This also means its useful for other libs building on libp2p and want an equivalent client in browser/node envs...

[request] include webpack browser bundle to npm package

Hi. I totally get that "Packaging for browsers is currently highly experimental".

But to make it easier to play with.. would there be an objection to updating the prepublishOnly npm script

  • from:
      "prepublishOnly": "npm run build",
  • to:
      "prepublishOnly": "npm run build && npm run browser:build",
  • so for subsequent releases:
      <script type="text/javascript" src="ipfs-lite.all.min.js"></script>

If the size the bundle adds to the npm package is an issue, then could it be attached to its corresponding tagged release?

PS. If size is a concern, you may also consider adding an .npmignore file to exclude everything in the repo except the dist/ directory generated by the build tasks.

Use Lerna to manage subpackages/components.

This would be a major refactor, but at this early stage, definitely worth the effort. It would reduce the size of the core bundle, and make it easier to only use the components you really need. This would also provide a really nice 'extension' framework.

Not able to add or get a file greater than 256 KB

Describe the bug

let { Peer, BlockStore } = require('../js-dag-service/dist/index')
let { setupLibP2PHost } = require('../js-dag-service/dist/setup/index')
let { MemoryDatastore } = require('interface-datastore')
const fs = require("fs");
const store = new BlockStore(new MemoryDatastore())
const main = async () => {
    // Bring your own libp2p host....
    const host = await setupLibP2PHost()
    const lite = new Peer(store, host)
    await lite.start()
    let content = fs.createReadStream('./a.txt');
    var source = [
        {
            path: "bar",
            content: content,
        },
    ];
    var data = await lite.addFile(source, { format: "raw", hashAlg: "sha2-256" })
    const cid = data.cid
    const data2 = await lite.getFile(cid)
    fs.writeFile("b.txt", data2, "text", function (err) {
        if (err) {
            console.log(err);
        } else {
            console.log("The file was saved!");
        }
    });
    await lite.stop()
}
main()

file size
-rw-rw-r-- 1 8725848 Aug 26 17:17 a.txt
-rw-rw-r-- 1 1710 Aug 26 17:25 b.txt

To Reproduce
Steps to reproduce the behavior:

  1. git clone js-dag-service and create a dist folder
  2. run the above code like 'node index.js'

Expected behavior
A file b.txt should have the content of file a.txt

Desktop :

  • OS: ubuntu 18.04.4

Nodejs
v12.18.3

Thank you for any help

Switch to a single PR template that works for all types of PRs so that you can use it without copying and pasting

Is your feature request related to a problem? Please describe.
It's extra work to copy and paste a PR template of a certain type when GitHub has a feature to click a button and use the right template directly.

Describe the solution you'd like
I would like a button added when someone creates a PR so that they can click on the type of template they would like to use.

Describe alternatives you've considered
Status quo

Additional context
n/a

Cannot Install

Describe the bug
Installation through npm fails, both when following the documentation installation instructions and when attempting to install it directly via git.

To Reproduce
Either:
1a. npm i @textile/ipfs-lite
1b. npm i https://github.com/textileio/js-ipfs-lite.git

Expected behavior
I expected @textile/ipfs-lite to be installed.

Additional context

Here are the errors:

1a.

npm ERR! code E404
npm ERR! 404 Not Found - GET https://registry.npmjs.org/@textile%2fipfs-lite - Not found
npm ERR! 404
npm ERR! 404  '@textile/ipfs-lite@latest' is not in the npm registry.
npm ERR! 404 You should bug the author to publish it (or use the name yourself!)
npm ERR! 404
npm ERR! 404 Note that you can also install from a
npm ERR! 404 tarball, folder, http url, or git url.

npm ERR! A complete log of this run can be found in:
npm ERR!     /Users/robert/.npm/_logs/2019-11-04T20_54_37_279Z-debug.log

1b.
A lot of errors here, but here's some very relevant-sounding snippets.

npm ERR! prepareGitDep > [email protected] install /Users/robert/.npm/_cacache/tmp/git-clone-29d3f6a7/node_modules/ursa-optional
npm ERR! prepareGitDep > node rebuild.js
npm ERR! prepareGitDep
npm ERR! prepareGitDep
npm ERR! prepareGitDep > assemblyscript@github:assemblyscript/assemblyscript#3ed76a97f05335504166fce1653da75f4face28f postinstall /Users/robert/.npm/_cacache/tmp/git-clone-29d3f6a7/node_modules/assemblyscript
npm ERR! prepareGitDep > opencollective-postinstall || exit 0
npm ERR! prepareGitDep
npm ERR! prepareGitDep Thank you for using assemblyscript!
npm ERR! prepareGitDep If you rely on this package, please consider supporting our open collective:
npm ERR! prepareGitDep > https://opencollective.com/assemblyscript/donate
npm ERR! prepareGitDep
npm ERR! prepareGitDep
npm ERR! prepareGitDep > @textile/[email protected] prepare /Users/robert/.npm/_cacache/tmp/git-clone-29d3f6a7
npm ERR! prepareGitDep > npm run build
npm ERR! prepareGitDep
npm ERR! prepareGitDep
npm ERR! prepareGitDep > @textile/[email protected] build /Users/robert/.npm/_cacache/tmp/git-clone-29d3f6a7
npm ERR! prepareGitDep > tsc -p ./tsconfig.build.json
npm ERR! prepareGitDep
npm ERR! prepareGitDep src/blockservice/index.ts(3,10): error TS2724: Module '"../../../../../../../../Users/robert/.npm/_cacache/tmp/git-clone-29d3f6a7/src/blockstore"' has no exported member 'Blockstore'. Did you mean 'BlockStore'?
npm ERR! prepareGitDep npm ERR! code ELIFECYCLE
npm ERR! prepareGitDep npm ERR! errno 2
npm ERR! prepareGitDep npm ERR! @textile/[email protected] build: `tsc -p ./tsconfig.build.json`
npm ERR! prepareGitDep npm ERR! Exit status 2
npm ERR! prepareGitDep npm ERR!
npm ERR! prepareGitDep npm ERR! Failed at the @textile/[email protected] build script.
npm ERR! prepareGitDep npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! prepareGitDep
npm ERR! prepareGitDep npm ERR! A complete log of this run can be found in:
npm ERR! prepareGitDep npm ERR!     /Users/robert/.npm/_logs/2019-11-04T20_47_27_665Z-debug.log
npm ERR! prepareGitDep npm ERR! code ELIFECYCLE
npm ERR! prepareGitDep npm ERR! errno 2
npm ERR! prepareGitDep npm ERR! @textile/[email protected] prepare: `npm run build`
npm ERR! prepareGitDep npm ERR! Exit status 2
npm ERR! prepareGitDep npm ERR!
npm ERR! prepareGitDep npm ERR! Failed at the @textile/[email protected] prepare script.
npm ERR! prepareGitDep npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
npm ERR! prepareGitDep

Prefer web APIs over node APIs

I often struggle using JS-IPFS in the browser because it predates all the nice web APIs that made working with binary data and files convenient. Often time this implies to using some node polyfills and / or needing to convert node constructs to browser ones so that other browser APIs can interact with it.

Here are few things that I have noticed.

  • addFile depends on node read stream etc..
    https://github.com/textileio/js-ipfs-lite/blob/0bb38fc91e10c480aef3109fde9ef98612a9c5a4/src/index.ts#L110-L124

    I would suggest to use web native File API instead which can have a path and can be constructed in arbitrary ways.

    As of files bundles there is FormData and I think it would make more sense to us that instead. It also has advantage that web forms can directly be written to IPFS. And all this works well with fetch and XMLHTTPRequest stuff.

  • getFile returns node Buffer. Which luckily in browser pollyfill implemented as a subclass of Uint8Array so it is somewhat more usable. However that still implies allocating memory for the whole content etc... On the other hand web has a Response API available who's body can be read as string, bytes, json, FormData or a stream. In fact it's also possible to use slices over the whole thing and also has notion of Error. It also can be stored in browser cache etc...

I would propose to draw inspiration from web native APIs and try to be as similar to fetch API as possible so it can be used as a drop in replacement. Specifically I'd very much prefer following intterface:

interface Peer {
  put(FormData|File|Blob):Promise<CID>
  get(CID|Path):Response;
  head(CID|Path):Response; // 404 if not found, 502 if network is spotty
  delete(CID):Response; // Delete from local storage
}

Move libp2p client init functions from tests to core API

This is a temporary 'fix' to make it easier to initialize a new IPFS Lite peer. It is not required to use this library, so it should be made pluggable at a later date. Ideally, you can 'bring your own libp2p', but we'll provide the 'batteries' here to make it easier for developers to start playing around.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.