The main repository for discussing multiformats
Currently, we have the following multiformat protocols:
See the project directory, below, for implementations and other related repositories.
Table of Contents
- Project Directory
Every choice in computing has a tradeoff. This includes formats, algorithms, encodings, and so on. And even with a great deal of planning, decisions may lead to breaking changes down the road, or to solutions which are no longer optimal. Allowing systems to evolve and grow is important.
Multiformats is a collection of protocols which aim to future-proof systems, today. They do this mainly by allowing data to be self-describable. This allows interoperability, protocol agility, and helps us avoid lock in. Currently, our protocols (both works in progress and implemented) cover the following areas:
- multiaddr: network addresses
- multibase: base encodings
- multicodec: serialization codes
- multigram: protocol negotiation and multiplexing over datagrams
- multihash: cryptographic hashes
- multikey: cryptographic keys and artifacts
- multistream: stream wire protocols
- multistream-select: Friendly protocol multiplexing.
The self-describing aspects of the protocols have a few stipulations:
- they must be in the value (not passed in out of band, in function calls, implicit choices, or documentation);
- they must be compact and have a binary-packed representation (as opposed to a sparser encoding) or they will hinder performance;
- they must have a human readable representation.
Several of the multiformats are stable, and we're working on the others. We are trying to prioritize their usage as soon as possible. What they offer -- protocol interoperability and future-proofing -- would have real-world consequences.
Towards that end, we are encouraging implementations of these protocols; if you know of any, please link them here (or add them to the organization!).
A note on the word Multiformats
Multiformats is the name for the organization, but it can also be used to refer to protocols; for instance, in the sentence "Use one of the multiformats". Formats is interchangeable with protocols, here. We try to capitalize Multiformats when it refers to the organization, on GitHub.
Below, a list of all of the projects in the Multiformats organization is listed.
Captains are the active leads for each project. Their responsibilities are to make sure that issues and pull requests are attended to in a timely manner, and general upkeep. If you have questions about a repository, or need feedback, please contact them as appropriate.
As well as specifications, we also have some implementations in the organization
|c-multihash||@Kubuxu||Only parsing and encoding, and not hashing.|
|hash-overlay (Java 9)||@jamespedwards42|
|specs||@nicola||Specification work regarding multihash, multiaddr, and others. WIP.|
|unsigned-varint||@jbenet||unsigned varint in use in multiformat specs. WIP.|
|clj-varint||@ekroon||Simple wrapper around Bazel VarInt code.|
|website||@victorbjelkholm||The multiformats website|
Please contribute! Dive into the issues!
Check out our contributing document for more information on how we work, and about contributing in general. Please be aware that all interactions related to multiformats are subject to the IPFS Code of Conduct.
If you're interested in proposing a new format (in addition to multihash, multistream, and so on), open an issue in this repository, explaining the name of the format, what it is for, and why you think it should become one of the multiformats. Pointing to any existing implementations would also be great, if there are any. If you want to implement a multiformat in a new language, open an issue in the main repository for the relevant multiformat: for instance, if you want to write rust-multicodec, open an issue in the multiformats/multicodec repository. This will allow others to know that you're working on it, and potentially join in the effort.
Small note: If editing the README, please conform to the standard-readme specification.