Skip to content

Commit

Permalink
Update readme
Browse files Browse the repository at this point in the history
  • Loading branch information
guseggert committed Jan 25, 2023
1 parent c444cbb commit a8b2ff4
Show file tree
Hide file tree
Showing 2 changed files with 57 additions and 8 deletions.
64 changes: 56 additions & 8 deletions README.md
Original file line number Diff line number Diff line change
@@ -1,17 +1,65 @@
go-libipfs
=======================
<h1 align="center">
go-libipfs 🍌
<br>
<img src="https://raw.githubusercontent.com/ipfs/go-libipfs/feat/readme/logo.svg" alt="go-libipfs logo" title="go-libipfs logo" width="200">
<br>
</h1>
<p align="center" style="font-size: 1.2rem;">A library for building IPFS applications and implementations.</p>

> A library for building IPFS implementations
<hr />

Go-libips is a library for building IPFS implementations and tools in Go. It contains reusable functionality useful for interacting and experimenting with IPFS.
[![Go Test](https://github.com/ipfs/go-libipfs/actions/workflows/go-test.yml/badge.svg)](https://github.com/ipfs/go-libipfs/actions/workflows/go-test.yml)
[![Go Docs](https://img.shields.io/badge/godoc-reference-blue.svg)](https://pkg.go.dev/github.com/ipfs/go-libipfs)
[![codecov](https://codecov.io/gh/ipfs/go-libipfs/branch/main/graph/badge.svg?token=9eG7d8fbCB)](https://codecov.io/gh/ipfs/go-libipfs)
##

This is also used by [Kubo](https://github.com/ipfs/kubo) for its core functionality.
Go-libips is a component library for building IPFS applications and implementations in Go.

Currently this library is a target for consolidating Go IPFS repositories, and will receive minor version releases as repositories are consolidated into it. We are initially focused on merely consolidating repositories, *not* refactoring across packages. Once repositories are mostly consolidated, *then* we will begin refactoring this library holistically. Individual components can still be worked on and refactored individually, but please refrain from trying to refactor across components.
Some scenarios in which you may find go-libipfs helpful:

## Contributing
* You are building an application that interacts with the IPFS network
* You are building an IPFS implementation
* You want to reuse some components of IPFS such as its Kademlia DHT, Bitswap, data encoding, etc.
* You want to experiment with IPFS

Go-libipfs powers [Kubo](https://github.com/ipfs/kubo), which is the most popular IPFS implementation, so its code has been battle-tested on the IPFS network for years, and is well-understood by the community.

## What kind of components does go-libipfs have?

Go-libipfs includes high-quality components useful for interacting with IPFS protocols, public and private IPFS networks, and content-addressed data, such as:

- Content routing (DHT, delegated content routing, providing)
- Data transfer (gateways, Bitswap, incremental verification)
- Naming and mutability (name resolution, IPNS)
- Interacting with public and private IPFS networks
- Working with content-addressed data

Go-libipfs aims to provide a cohesive interface into these components. Note that not all of the underlying components necessarily reside in this respository.

## Getting started
TODO

## Should I add my IPFS component to go-libipfs?
We happily accept external contributions! However, go-libipfs maintains a high quality bar, so code accepted into go-libipfs must meet some minimum maintenance criteria:

* Actively maintained
* Must be actively used by, or will be included in software that is actively used by, a significant number of users or production systems. Code that is not actively used cannot be properly maintained.
* Must have multiple engineers who are willing and able to maintain the relevant code in go-libipfs for a long period of time.
* If either of these changes, go-libipfs maintainers will consider removing the component from go-libipfs.
* Adequately tested
* At least with unit tests
* Ideally also including integration tests with other components
* Adequately documented
* Godocs at minimum
* Complex components should have their own doc.go or README.md describing the component, its use cases, tradeoffs, design rationale, etc.
* If the maintainers are not go-libipfs maintainers, then the component must include a CODEOWNERS file with at least two code owners who can commit to reviewing PRs

If you have some experimental component that you think would benefit the IPFS community, we suggest you build the component in your own repository until it's clear that there's community demand for it, and then open an issue in this repository to discuss including it in go-libipfs.

## Help

If you have questions, feel free to open an issue. You can also find the go-libipfs maintainers in [Slack](https://filecoin.io/slack/) at #go-libipfs-maintainers.

Contributions are welcome! This repository is part of the IPFS project and therefore governed by our [contributing guidelines](https://github.com/ipfs/community/blob/master/CONTRIBUTING.md).

## License

Expand Down
1 change: 1 addition & 0 deletions logo.svg
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit a8b2ff4

Please sign in to comment.