HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
libp2p
rust-libp2p
Rust2018–2024
libp2p / rust-libp2p

rust-libp2p

The Rust Implementation of the libp2p networking stack.

Systems & InfrastructureNetworking
Explore on GitHubRead Hacker News discussions
10Distinct people
12Mentions
1Explicit recommenders
5.6KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Rust Implementation of the libp2p networking stack.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

Not sure what exactly you are looking for, but I find IPFS / libp2p pretty easy to use once you know the basic concepts. For a simple web based GUI app you can use the js…

rklaehn used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 12:54:37 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year12 dated mentions

Observed mentions: 2018-04-08 15:41:09 UTC to 2024-06-14 02:17:12 UTC.

01232018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC303
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC303
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC312
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

What Hacker News says

12 sources
r3trohack3r·Jun 14, 2024
That's wild (in a good/interesting way) to me. I've found the BitTorrent protocol tries to be more suited to accessing popular data on-demand (i.e. streaming a popular file) vs. archival. IPFS' BitSwap protocol strikes me as trying to be optimized for longer-term preservation (higher latency time to first byte in exchange for more resilient pinning/discovery/propagation of rare data). It's cool you're observing the opposite. I've had a growing suspicion that both protocols haven't quite realized the benefits they were hoping to get from the trade-offs they made in their transfer/discovery protocols. Would love to compare notes at some point if you'd be open to it. We've been playing around with both BitTorrent and IPFS. Some of the datasets we are working towards supporting are approaching the scale you work at (100TB archives). Ultimatel
Read the rest
y both BitTorrent and IPFS have fallen short for me when trying to seed 100TB datasets. I've got a hunch that we're going to need to roll a new protocol to tackle these larger datasets that merges some of HTTP's, BitTorrent's, and IPFS' approaches to sharing content. I have personal R&D list for pushing a file sharing protocol past the 100TB limit (not in any particular order): * Better chunking using a mix of: * Rolling hashes * File boundary splitting * (should enable deduplication of identical files across nonhomogeneous archives, and allow for adding content to an archive with without losing the existing seeders) * (inspired by prior art in container storage: https://github.com/hinshun/ipcs) * "online" deterministic archive formats w/ detached metadata * Ability to share a directory as an archive, or partial slice of an archive, without having to generate the archive on disk. (Announce a "tarball" like archive on the DHT without having to generate it by being able to generate the "chunks" on demand from the directory) * Detatch the manifest containing the archive's contents from the archive, so you can download/parse the manifest without downloading the full dataset. (You can use this to find the chunks specific files are in. So you can download a single file from a 1TB archive, and the client can seed that file back to the network as part of the archive.) * Chunking of manifest files for large datasets, since the manifest itself might grow to many GBs in size (manifest resolution inspired by IPLD's data structure) * Normalize file metadata in the archive header so timestamps etc. don't muck up your CIDs * Deterministic ordering of files in an archive * Chunking/Transfers/Announcing/Discovering * Supporting increasing the chunk sizes for large files past 1MB. A 100TB dataset w/ 1MB chunks requires ~209M CIDs just for the chunks, that's a lot of load on the DHT and a lot of work on the seeding node to keep the data available. * Support interruptible/resumable/recoverable downloads from peers using something similar HTTP RANGE header semantics * Merge BitTorrent's DHT query approach w/ IPFS' DHT query approach, asking connected peers for CIDs and tit-for-tat reciprocity while simultaneously hedging your bet by kicking off the slower DHT traversal to find more peers * Connectivity * Bringing mobile devices and browser tabs into the fold as first class peers that can both download and seed content * (i.e. WebRTC: https://github.com/libp2p/rust-libp2p/tree/master/examples/browser-webrtc) * (proof-of-concept NAT hole punching appliance for end-users: https://github.com/retrohacker/turn-it-up) Thank you for everything you do
In You can help Anna's Archive by seeding torrents
rklaehn·Apr 11, 2022
Yes, there is a lot of awesome stuff that just works. SSB, the entire DAT/hypercore community, tools like syncthing that just do one thing well. I like the SSB approach of just embracing subjectivity. I was quite amazed when discovering all this at dtn.is (Before I only knew the IPFS community). But I feel there is still something missing for very wide spread adoption. What we are trying to do with TLFS is to combine - a CRDT with strict schema ( Adapted from https://arxiv.org/abs/1603.01529 ) - a built in way to do schema evolution ( Adapted from https://www.inkandswitch.com/cambria/ ) - local first / p2p deployment and operation even for native apps, based on https://github.com/libp2p/rust-libp2p , faciliated by https://github.com/cloudpeers/x We're not nearly there yet, but ideally it should be so easy to write small collaborative apps
Read the rest
that it is a good option even if you don't care about the idealistic motivations for decentralized apps.
In Locutus: A platform for building decentralized apps, from the creator of Freenet
akubera·Jul 21, 2019
https://github.com/libp2p/rust-libp2p There's the Rust repository, and the auto-generated documentation can be found at https://docs.rs/libp2p/0.11.0/libp2p/ I'm curious what about a C implementation is the requirement for you? Is it the ability for to link against your C/C++ code, or for reading and understanding the structures and algorithms with the simplicity of C parlance, or another reason? If the first one, it is possible to create a C shared-library "cdylib" with Rust (included in cargo by default), and using cbindgen[1] you can generate the headers to use the c-api. It doesn't look like anybody has done that yet, unfortunately. But know that it should be a lot easier to create C/C++ compatibility than doing a rewrite or port. [1] https://github.com/eqrion/cbindgen EDIT: Or as the sibling comment points out, there ARE C implementa
Read the rest
tions out there, so you can ignore this post.
In Understanding IPFS in Depth(5/6): What Is Libp2p?
vasa_develop·Jul 21, 2019
Hi dingo_bat! Here are a few unofficial implementations on Libp2p in C. - https://github.com/squishyhuman/c-libp2p - https://github.com/Agorise/c-libp2p Here are Go, and Rust (Official)implementations: - https://github.com/libp2p/go-libp2p - https://github.com/libp2p/rust-libp2p You can find the interfaces in the codebase. If you are having a hard time finding the interfaces in the codebase, or not able to figure out how to use them, then PLEASE head over to discuss.libp2p.io. There are a ton of people who will be more than happy to help you :) I will try to add all this info in the article wherever possible. Is there anything else that you what to be improved in the article?
In Understanding IPFS in Depth(5/6): What Is Libp2p?
rklaehn·Feb 16, 2019
There is a version of libp2p written in rust, developed by parity.io: https://github.com/libp2p/rust-libp2p . IPFS is much younger than bittorrent, so it is not surprising that there are not as many implementations. I am not sure why that makes it "a joke". All that is needed for IPFS to function in a russia-only internet are a few russian bootstrap nodes. Bootstrap nodes are not in any way special, so any node can serve as a bootstrap node.
In Distributed web not ready for Runet cutoff from the Internet
rklaehn·Nov 22, 2018Recommendation phrase
Not sure what exactly you are looking for, but I find IPFS / libp2p pretty easy to use once you know the basic concepts. For a simple web based GUI app you can use the js version of IPFS or interact with a locally running go-IPFS node using a pretty simple REST api. Once you got your feet wet, or if you have a more demanding use case, you can use libp2p directly, from js, go or rust. Since you mentioned rust: https://github.com/libp2p/rust-libp2p libp2p could be described as an attempt to implement a common networking stack for the distributed web. IPFS builds on libp2p, as does filecoin. I work for a company https://www.actyx.io/en that does industrial applications based on IPFS / libp2p, so I use IPFS every day. Obviously it is bleeding edge technology with a lot of rough edges. But I find the current state and the rate of improvement q
Read the rest
uite promising.
In Ask HN: Can you recommend a modern, accessible P2P framework/library?

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.