Updating README and package.json

This commit is contained in:
Chris Troutner
2023-10-28 10:11:04 -07:00
parent a42c15c969
commit bc410678b4
5 changed files with 112 additions and 55 deletions
+93
View File
@@ -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.
+1 -1
View File
@@ -1,5 +1,5 @@
The MIT License (MIT) 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: 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:
+3
View File
@@ -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.
+14 -53
View File
@@ -18,7 +18,9 @@ This repository has been forked from the [koa-api-boilerplate](https://github.co
- [Koa](https://koajs.com/) framework for REST APIs - [Koa](https://koajs.com/) framework for REST APIs
- User management - 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: 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:
@@ -27,31 +29,15 @@ This boilerplate extends that code to provide the basic features required to be
If you are interested in creating your own service provider on the IPFS network, fork this repository and start building. If you are interested in creating your own service provider on the IPFS network, fork this repository and start building.
## Branches ## IPFS node
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). 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.
## Circuit Relay - *Video link will be added here*
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.
## 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
## Requirements ## Requirements
- node **^14.18.2** - node **^16.20.2**
- npm **^8.3.0** - npm **^8.19.4**
- Docker **^20.10.8** - Docker **^20.10.8**
- Docker Compose **^1.27.4** - Docker Compose **^1.27.4**
@@ -59,44 +45,18 @@ This project covers basic necessities of most APIs.
### Development Environment ### 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. Ubuntu v20 is the recommended OS for creating a dev environment. Other operating systems may cause issues.
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)
```bash ```bash
git clone https://github.com/Permissionless-Software-Foundation/ipfs-service-provider git clone https://github.com/Permissionless-Software-Foundation/ipfs-service-provider
cd ipfs-service-provider cd ipfs-service-provider
./install-mongo-sh ./install-mongo-sh
sudo npm install -g node-pre-gyp
npm install npm install
./ipfs-service-provider.sh npm start
``` ```
### Production Environment
The [docker](./production/docker) directory contains a Dockerfile for building a production deployment. ## File Structure
```
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
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 differs from the koa-api-boilerplate. Instead, it follows the file layout of [Clean Architecture](https://christroutner.github.io/trouts-blog/blog/clean-architecture).
@@ -110,9 +70,10 @@ The file layout of this repository differs from the koa-api-boilerplate. Instead
## Documentation ## 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/docs/` to view docs
There is additional developer documentation in the [dev-docs directory](./dev-docs). There is additional developer documentation in the [dev-docs directory](./dev-docs).
+1 -1
View File
@@ -1,6 +1,6 @@
{ {
"name": "ipfs-service-provider", "name": "ipfs-service-provider",
"version": "3.0.0", "version": "4.0.0",
"description": "A Koa-based combination of a REST API and IPFS JSON RPC. Boilerplate for starting new projects.", "description": "A Koa-based combination of a REST API and IPFS JSON RPC. Boilerplate for starting new projects.",
"main": "index.js", "main": "index.js",
"type": "module", "type": "module",