Merge pull request #114 from Permissionless-Software-Foundation/helia

Helia refactor. v4.0.0

.gitignore

@@ -66,5 +66,6 @@ orbitdb
 ipfsdata
 .ipfsdata
 data/
+run-dev.sh
 
 !README.md

CONTRIBUTING.md

@@ -0,0 +1,93 @@
+# Permissionless Software Foundation Community Contributing Guide 1.0
+
+This document describes a very simple process suitable for most projects under
+the PSF umbrella. It is based on [this Medium article](https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951) and the [Node.js Community Contribution Guide](https://github.com/nodejs/TSC/blob/master/BasePolicies/CONTRIBUTING.md).
+Projects are encouraged to adopt this whether they
+are hosted under the PSF or not.
+
+The goal of this document is to create a contribution process that:
+
+* Encourages new contributions.
+* Encourages contributors to remain involved.
+* Avoids unnecessary processes and bureaucracy whenever possible.
+* Creates a transparent decision making process which makes it clear how
+contributors can be involved in decision making.
+
+This document is based on much prior art in the Node.js community, io.js,
+and the Node.js project.
+
+Additional guidance can be found at the [Permissionless Software Foundation Telegram Channel](https://t.me/permissionless_software).
+
+## Vocabulary
+
+* A **Contributor** is any individual creating or commenting on an issue or pull request.
+* A **Committer** is a subset of contributors who have been given write access to the repository.
+* A **TC (Technical Committee)** is a group of committers representing the required technical
+expertise to resolve rare disputes.
+
+# Logging Issues
+
+Log an issue for any question or problem you might have. When in doubt, log an issue,
+any additional policies about what to include will be provided in the responses. The only
+exception is security disclosures which should be sent privately.
+
+Committers may direct you to another repository, ask for additional clarifications, and
+add appropriate metadata before the issue is addressed.
+
+Please be courteous, respectful, and every participant is expected to follow the
+project's Code of Conduct.
+
+# Contributions
+
+Any change to resources in this repository must be through pull requests. This applies to all changes
+to documentation, code, binary files, etc. Even long term committers and TC members must use
+pull requests.
+
+No pull request can be merged without being reviewed.
+
+For non-trivial contributions, pull requests should sit for at least 36 hours to ensure that
+contributors in other timezones have time to review. Consideration should also be given to
+weekends and other holiday periods to ensure active committers all have reasonable time to
+become involved in the discussion and review process if they wish.
+
+The default for each contribution is that it is accepted once no committer has an objection.
+During review committers may also request that a specific contributor who is most versed in a
+particular area gives a "LGTM" before the PR can be merged. There is no additional "sign off"
+process for contributions to land. Once all issues brought by committers are addressed it can
+be landed by any committer.
+
+In the case of an objection being raised in a pull request by another committer, all involved
+committers should seek to arrive at a consensus by way of addressing concerns being expressed
+by discussion, compromise on the proposed change, or withdrawal of the proposed change.
+
+If a contribution is controversial and committers cannot agree about how to get it to land
+or if it should land then it should be escalated to the TC. TC members should regularly
+discuss pending contributions in order to find a resolution. It is expected that only a
+small minority of issues be brought to the TC for resolution and that discussion and
+compromise among committers be the default resolution mechanism.
+
+# Becoming a Committer
+
+All contributors who land a non-trivial contribution should be on-boarded in a timely manner,
+and added as a committer, and be given write access to the repository.
+
+Committers are expected to follow this policy and continue to send pull requests, go through
+proper review, and have other committers merge their pull requests.
+
+# TC Process
+
+The TC uses a "consensus seeking" process for issues that are escalated to the TC.
+The group tries to find a resolution that has no open objections among TC members.
+If a consensus cannot be reached that has no objections then a majority wins vote
+is called. It is also expected that the majority of decisions made by the TC are via
+a consensus seeking process and that voting is only used as a last-resort.
+
+Resolution may involve returning the issue to committers with suggestions on how to
+move forward towards a consensus. It is not expected that a meeting of the TC
+will resolve all issues on its agenda during that meeting and may prefer to continue
+the discussion happening among the committers.
+
+Members can be added to the TC at any time. Any committer can nominate another committer
+to the TC and the TC uses its standard consensus seeking process to evaluate whether or
+not to add this new member. Members who do not participate consistently at the level of
+a majority of the other members are expected to resign.

LICENSE.md

@@ -1,5 +1,5 @@
 The MIT License (MIT)
-Copyright (c) 2021-2022 Permissionless Software Foundation
+Copyright (c) 2021-2023 Permissionless Software Foundation
 
 Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
 

PEDIGREE.md

@@ -0,0 +1,3 @@
+# Pedigree
+
+This repository was forked from [koa-api-boilerplate](https://github.com/christroutner/koa-api-boilerplate). Code changes from that upstream repository is frequently pulled in and merged to this repository.

README.md

@@ -4,109 +4,76 @@
 
 ## Overview
 
-This is a 'boilerplate' repository. It's intended to be forked to start new projects. However, it can also be run as a stand-alone Circuit Relay, for supporting the PSF network.
+This is a 'boilerplate' repository. It's intended to be forked to start new projects. Some code projects that are forks of this repository and regularly pull in changes:
+- [pay-to-write database (P2WDB)](https://p2wdb.com/)
+- [ipfs-bch-wallet-consumer](https://github.com/Permissionless-Software-Foundation/ipfs-bch-wallet-consumer)
+- [ipfs-bch-wallet-service](https://github.com/Permissionless-Software-Foundation/ipfs-bch-wallet-service)
+
+
+In addition to being forked as a boilerpalte, it can also be run as a stand-alone application to create a [Circuit Relay](https://cashstack.info/docs/local-back-end/circuit-relay), which can support the [PSF](https://psfoundation.info) IPFS network. It can also be used for experimenting with [helia-coord](https://github.com/Permissionless-Software-Foundation/helia-coord) and the [psf-bch-wallet](https://github.com/Permissionless-Software-Foundation/psf-bch-wallet) command-line wallet.
 
 ## Boilerplate
 
 This repository has been forked from the [koa-api-boilerplate](https://github.com/christroutner/koa-api-boilerplate). It has all the same features as that boilerplate:
 
 - [Koa](https://koajs.com/) framework for REST APIs
 - User management
-- Access and rate-limit control using [JWT tokens](https://jwt.io/).
+- Access and rate-limit control (authentication and authorization) using [JWT tokens](https://jwt.io/)
+- Logging system with API access
+- Email contact integration
 
 This boilerplate extends that code to provide the basic features required to be a 'service provider' on the [IPFS](https://ipfs.io) network. This is a core concept in the [web3 Cash Stack](https://cashstack.info). These basic features include:
 
-- [ipfs-coord](https://www.npmjs.com/package/ipfs-coord) for coordinating service providers and consumers across the IPFS network.
+- [helia-coord](https://github.com/Permissionless-Software-Foundation/helia-coord) for coordinating service providers and consumers across the IPFS network.
 - JSON RPC for creating an API between providers and consumers.
 
-If you are interested in creating your own service provider on the IPFS network, fork this repository and start building.
-
-## Branches
-This code repository was refactored from CommonJS format to ECMA Script Modules (ESM) format because js-ipfs made the same change, and this repository depends heavily on that one. A CommonJS format version of this code repository is maintained in the [`cjs` branch](https://github.com/Permissionless-Software-Foundation/ipfs-service-provider/tree/cjs). This is useful for projects that can not make use of ESM yet, like [Electron.js](https://www.electronjs.org/) and [P2WDB](https://p2wdb.com).
+If you are interested in creating your own service provider on the IPFS network, fork this repository and start building. This repository is used in serveral PSF projects:
 
-## Circuit Relay
+- [P2WDB](https://github.com/Permissionless-Software-Foundation/ipfs-p2wdb-service) - the [pay-to-write database](https://p2wdb.com) is a censorship-resistent, p2p database for storing data and pinning files to the IPFS network.
+- [ipfs-bch-wallet-consumer](https://github.com/Permissionless-Software-Foundation/ipfs-bch-wallet-consumer) and [ipfs-bch-wallet-service](https://github.com/Permissionless-Software-Foundation/ipfs-bch-wallet-service) creates a web3, censorship-resistent API for apps to communicate with a blockchain. This software is documented in [the Cash Stack](https://cashstack.info).
 
-This 'production' environment for this boilerplate sets up a series of Docker containers, orchestrated with Docker Compose. This boilerplate code can be run without modification, in order to set up a [Circuit Relay](https://docs.libp2p.io/concepts/circuit-relay/) and support the PSF network. You can get paid a [bounty](https://github.com/Permissionless-Software-Foundation/bounties) for doing so, in PSF tokens. See the section below on setting up a Production Docker Container.
+## IPFS node
+This web server spins up an embedded IPFS ([Helia](https://github.com/ipfs/helia)) node. This node can be controlled and interrogated via the REST API. [psf-bch-wallet](https://github.com/Permissionless-Software-Foundation/psf-bch-wallet) is a command-line app (CLI) that can easily tap into this REST API in order to interact with the embedded IPFS node.
 
-## Features
-
-This project covers basic necessities of most APIs.
-
-- [Koa](https://koajs.com/) framework for REST APIs
-- Authentication (passport & jwt)
-- Database (mongoose)
-- Testing (mocha)
-- Doc generation with apidoc
-- Linting using [Standard](https://github.com/standard/standard)
-- Packaged for production environment as a Docker container
-- [ipfs-coord](https://www.npmjs.com/package/ipfs-coord) for coordinating peers over IPFS
-- JSON RPC for mirroring the REST API over IPFS
+- *Video link will be added here*
 
 ## Requirements
 
-- node **^14.18.2**
-- npm **^8.3.0**
+- node **^16.20.2**
+- npm **^8.19.4**
 - Docker **^20.10.8**
 - Docker Compose **^1.27.4**
 
 ## Installation
 
 ### Development Environment
 
-**Note:** This software now uses an external go-ipfs IPFS node. The instructions below have not been updated to reflect this.
-
-A development environment will allow you modify the code on-the-fly and contribute to the code base of this repository. [PM2](https://www.npmjs.com/package/pm2) is recommended for running this code base as an IPFS Circuit Relay.
-
-- [Video: Installing ipfs-service-provider](https://youtu.be/Z0NsboIVN44)
-- [Step-by-step installation instructions](https://gist.github.com/christroutner/3304a71d4c12a3a3e1664a438f64d9d0)
+A development environment will allow you modify the code on-the-fly and contribute to the code base of this repository. Ubuntu v20 is the recommended OS for creating a dev environment. Other operating systems may cause issues.
 
 ```bash
 git clone https://github.com/Permissionless-Software-Foundation/ipfs-service-provider
 cd ipfs-service-provider
 ./install-mongo-sh
-sudo npm install -g node-pre-gyp
 npm install
-./ipfs-service-provider.sh
-```
-
-### Production Environment
-
-The [docker](./production/docker) directory contains a Dockerfile for building a production deployment.
-
+npm start
 ```
-docker-compose pull
-docker-compose up -d
-```
-
-You can bring the containers back up with `docker-compose up -d`.
-
-### Operation Notes
-
-- There is a memory leak in the version of js-ipfs. The app is currently configured to shut down every 8 hours to flush memory. It relies on a process manager like pm2, Docker, or systemd to restart the app after it shuts down, in order to ensure continuous operation.
-
-- The PSF network operates as a private network. It does not connect or interact with the wider PSF network, relying instead on gateways to bridge the two networks, when they need to share content. This improves the performance and experience for everyone in the PSF network. To join the network, you'll need to add the [swarm.key](./swarm.key) file to the IPFS data folder.
-
-- [Instructions on setting up IPFS private networks.](https://github.com/ipfs/go-ipfs/blob/master/docs/experimental-features.md#private-networks)
-- For external installations, the swarm.key file will typically go in `~/.ipfs/swarm.key`
-- For production Docker containers, the key would go in `ipfs-service-provider/production/data/go-ipfs/data/swarm.key`
 
-## Structure
+## File Structure
 
-The file layout of this repository differs from the koa-api-boilerplate. Instead, it follows the file layout of [Clean Architecture](https://christroutner.github.io/trouts-blog/blog/clean-architecture).
+The file layout of this repository follows the file layout of [Clean Architecture](https://christroutner.github.io/trouts-blog/blog/clean-architecture). Understaning the principles laid out this article will help developers navigate the code base.
 
 ## Usage
 
 - `npm start` Start server on live mode
 - `npm run docs` Generate API documentation
 - `npm test` Run mocha tests
-- `docker-compose build` Build a 'production' Docker container
-- `docker-compose up` Run the docker container
 
 ## Documentation
 
-API documentation is written inline and generated by [apidoc](http://apidocjs.com/).
+API documentation is written inline and generated by [apidoc](http://apidocjs.com/). Docs can be generated with this command:
+- `npm run docs`
 
-Visit `http://localhost:5000/docs/` to view docs
+Visit `http://localhost:5020/` to view docs
 
 There is additional developer documentation in the [dev-docs directory](./dev-docs).
 

config/index.js

@@ -14,8 +14,4 @@ if (env === 'test') {
   config = production
 }
 
-// const importStr = `./env/${env}.js`
-// console.log('importStr: ', importStr)
-// import config from importStr
-
 export default Object.assign({}, common, config)

config/passport.js

@@ -53,7 +53,4 @@ function applyPassportMods (passport) {
   return true
 }
 
-// For testing
-// export default { passport, passportCallback };
-// export default applyPassportMods
 export { applyPassportMods, passportCallback }