# p2p-index: a curated catalogue of peer-to-peer projects > p2p-index is a single README that indexes peer-to-peer projects into seven categories, from web and messaging through to finance and storage. It is a directory rather than software, which makes its value a question of curation quality and link survival, not of features. **moshest/p2p-index** — 👯‍♂️ A collection of peer-to-peer decentralized projects. - Repository: https://github.com/moshest/p2p-index - Stars: 617 · Forks: 107 - Language: Unknown - License: GPL-3.0 - Published: 2026-10-22 · Updated: 2026-10-22 · Language: en - Canonical page: https://hysenlabs.com/projects/moshest-p2p-index ## What p2p-index actually contains The repository is three things on disk: a README, a LICENSE file and a .github directory. There is no source code, no build system and no package to install. The README calls itself a collection of peer-to-peer decentralized projects and invites submissions with a pull request, and the whole artefact is the README itself. That framing matters for anyone evaluating it as a project. It is not a framework, a library or a tool that does something for you. It is a hand-maintained index with one line of prose per entry, and its usefulness depends entirely on the judgement of whoever maintains it. The README is published under the GNU GPLv3, and it points readers to the links page of GNUnet for additional projects, which is an implicit admission that no single list can be complete. The index is organised with an explicit table of contents at the top, and each entry follows the same shape: the project name in bold, a link to the project's own site or repository, and a one-line description. Some entries add a second link to source code, which is where the list becomes more useful than a plain bookmark set. P2Party, for instance, lists a source repository alongside its project page, and Spixi and Valhalla do the same. ## The seven sections and what each one collects The categories are the structure that makes a list this long navigable, and they are functional rather than technological. Web covers browser and publishing systems, including LokiNet as an onion routing network for publishing and messaging, ZeroNet for decentralized websites, I2P, which the list describes as similar to Freenet, GNUnet and Tor, Aether as anonymous reddit without servers, and Plume, a fully client-side blogging platform built on Solid standards. The section also holds Freenet and YaCy, the latter a peer-to-peer search engine, plus browsers built for these networks such as Beaker Browser and Agregore Browser. Communication is the largest section in the index and it splits along two axes, transport and encryption. Session appears as a decentralized fork of Signal running on LokiNet, while Jami, Tox and Riot are each described as peer-to-peer, end-to-end encrypted, cross-platform messaging with calls. Matrix sits in the Platforms section rather than here, and Secure Scuttlebutt is listed as a Twitter-like network using a decentralized gossip protocol. Platforms and Frameworks collects the underlying protocols and networks, from WebRTC and its proposed successor Salsify, through Telehash, Meshnet, Matrix and GNUnet, to blockchain platforms such as Ethereum and Blockstack and simulators such as PeerSim. Finance is a short section of Bitcoin, OpenBazaar, LaZooz, Weifund, Unstoppable and CoinAwesome, and Data Transfer and Streaming holds BitTorrent, WebTorrent, PeerCDN, Tribler, GitTorrent and Floe. Storage and an In Progress section complete the index. ## What the entries reveal about the peer-to-peer ecosystem Read as a set rather than as a list, the index shows a clear imbalance. Many entries are clients aimed at end users, browsers and messengers, while the protocol layer is comparatively thin, and several of the client entries are explicitly built on top of a protocol named elsewhere in the same list. Plume is built on Solid, Beaker Browser browses the Dat protocol, WebTorrent is a streaming client, and Session runs on LokiNet. A second pattern is the emphasis on verifiable identity of the author rather than on the transport. The list describes Valhalla as peer-to-peer rooms shared by AI agents and the people who run them, where every post is signed by the key that wrote it, and Spixi as a decentralized messenger with post-quantum encryption and no servers, running on Ixian. Ixian itself is described as a decentralized platform with a distributed ledger, presence-based discovery and post-quantum cryptography. ParaHub adds a Web-of-Trust sybil defense alongside non-custodial Lightning payments. A third pattern is that several of the newest entries are decentralised applications rather than infrastructure. Parahub covers local communities with marketplace, liquid democracy, transit and energy cooperatives on mesh networking. The list also carries projects that convert familiar ideas into peer-to-peer form, such as RemoteLib, which turns JavaScript code into a remote service, and Orbit, a serverless chat application on IPFS. ## Contributing to the list and what the repository does not do The contribution path is a pull request, and the README states the request plainly: send a pull request with your project. There is no template, no scoring rubric and no stated criteria for inclusion visible in the README, which is the central limitation of the artefact. The categories are a taxonomy rather than a filter, so an entry says what a project does and nothing about whether it is maintained, how widely it is used or how it compares with the other entries in its own section. For a reader trying to choose, that gap is decisive. The description lines are short and written in a house style, so a project that solves a hard problem and a project that has not been touched in a decade look identical on the page. The In Progress section is the only signal of status the index offers, and the README does not define what belongs there or how entries leave it. Link survival is the second structural weakness, and it is the kind that gets worse quietly. The entries point at project homepages, project pages and source repositories, sometimes at code hosting sites and sometimes at project domains. A list of this size accumulates dead links over time, and the only maintenance visible in the repository is the pull request route, so accuracy depends on readers reporting broken entries as well as proposing new ones. ## The alternative to a link list: a directory you can query The practical alternative is to keep your own structured list, or to use the index as a seed for one. The difference in approach is not the number of links but what you can do with them afterwards. The README gives you a name, a URL and one sentence per project, which is enough to decide where to look and not enough to compare, filter or track. The README itself points at a second directory, the links page of GNUnet, for more projects, and the two together cover more ground than either alone without changing the nature of the resource. A structured alternative goes further: a table with fields for protocol, licence, last release date, language and activity would answer the questions the index leaves open, at the cost of someone maintaining those fields rather than one description line. Where the index does have an edge is coverage and categorisation. Sifting seven functional categories of peer-to-peer projects by hand, with the notes on each line carrying real information such as that BitTorrent is a file sharing protocol, that GitTorrent shares Git repositories over BitTorrent, or that Floe moves files over WebRTC without the data touching a server, is a job worth not repeating from scratch. The list is best used as a map, and the value it adds is the map rather than the analysis. ## Conclusion p2p-index earns a place in a bookmarks folder for anyone starting a survey of peer-to-peer software, since it groups real projects by function and points at source code for some of them. It is the wrong tool for picking what to deploy, because nothing in the entries says whether a project is alive or how it compares to its alternatives. Verify first that the category a project lands in matches your use case, and that the project link still resolves before you plan around it, since a list of this kind is only as good as the links it holds. ## FAQ ### What is p2p-index? It is a collection of peer-to-peer decentralized projects published as a README with an index table of contents and one line of description per project. The repository contains a README, a LICENSE file and a .github directory, with no source code to install. ### How do I add a project to p2p-index? The README asks for a pull request with your project. The repository also points readers to the GNUnet links page for additional projects beyond those in the index. ### Which categories does the p2p-index cover? The index of contents lists Web, Communication, Platforms and Frameworks, Finance, Data Transfer and Streaming, Storage, and an In Progress section. Entries under Communication include Session, Retroshare, Bitmessage, Jami, Tox and Matrix. ### What licence does p2p-index use? The README states that the list is published under the GNU GPLv3. The licence covers the list itself, and the projects it links to carry their own terms. ### Does p2p-index say whether the projects it lists are still maintained? No. Each entry gives a name, a link and a one-line description, with some entries adding a source code link. The material documents no criteria for inclusion and no per-project status markers beyond the In Progress section. ## Sources - [Issues](https://github.com/moshest/p2p-index/issues) - [License: GPL-3.0](https://github.com/moshest/p2p-index/blob/master/LICENSE) - [moshest/p2p-index on GitHub](https://github.com/moshest/p2p-index) - [README](https://github.com/moshest/p2p-index/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moshest-p2p-index