specs
rust-libp2p
specs | rust-libp2p | |
---|---|---|
17 | 31 | |
1,492 | 4,165 | |
0.5% | 1.3% | |
6.5 | 9.8 | |
11 days ago | 3 days ago | |
Rust | ||
- | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
specs
-
Filecoin Foundation Successfully Deploys IPFS in Space
The beauty of ipfs is the transport protocols are completely modular. They do a pretty good job supporting a lot of variety a separating concerns via https://github.com/libp2p/specs
-
BlockChain Engineers
For p2p networking, I'd say things are pretty interesting and boring at the same time. (Read: https://github.com/libp2p/specs if you're interested and decide for yourself)
-
Theseus DHT Protocol
At the bottom is the link to the more technical specification: https://github.com/libp2p/specs/blob/master/kad-dht/README.m...
-
Avoiding HTTP/3 (for a while) as a pragmatic default
The problems you described are specific to implementations, not the protocol itself. I have read all of the QUIC specs in full (since I'm working on an implementation) and have seen nothing in any of them that mandates a centralised certificate infrastructure (caveat: I have not read the HTTP/3 spec, perhaps you point out the relevant section if its in there). Of course, the most common use case requires this, but in that respect it's no different to HTTPS.
IPFS uses QUIC as one of its supported transport protocols, and this works in the most common implementation, Kubo [1]. The spec for the QUIC transport used in IPFS [2] indicates the same certificate trust policy as for the TLS protocol [3]. The latter, in turn, relies on peer-to-peer authentication with automatically-generated self-signed certificates and the use of an additional extension.
IPFS is particularly well suited to the use case of personal websites you've mentioned, as it's specifically designed to operate without any form of centralisation.
[1] https://github.com/ipfs/kubo.
[2] https://github.com/libp2p/specs/tree/master/quic
[3] https://github.com/libp2p/specs/blob/master/tls/tls.md
-
What about a Zig implementation of lib2p2?
Yes, there is already a Rust version (https://github.com/libp2p/rust-libp2p) that behaves well at this level but I think we can reach a higher level of performance on this point with Zig. Also, if you look at the long term roadmap of libp2p (https://github.com/libp2p/specs/blob/master/ROADMAP.md), the mobile devices and IoT integrations for example are part of the considerations.
-
IPFS Relay server
A standalone daemon that provides libp2p circuit relay services, for both protocol versions v1 and v2.
-
Does peer B (has access to the internet) help other peer A (who is behind the nat) to transfer data from peer C (has access to the internet) using ipfs?
Interestingly, that section also links to one about relay connections, which seems to be closely related to the original question: https://github.com/libp2p/specs/blob/master/relay/circuit-v2.md
-
Call HN: Decentralized Nat Hole Punching Measurement Campaign
Hi HN,
during December 2022, we are running a measurement campaign to investigate decentralized NAT hole punching success rates using the libp2p DCUtR protocol [0]. Ubiquitous peer-to-peer connectivity is still a big challenge. If successful, NAT Hole Punching can be a game-changer for decentralised applications and networks!
For that we are searching for participants who would run a lean client on their machines that performs hole punches with other peers and then reports back the results to our server. We explained the measurement methodology in this video [1] and the linked repository above.
Running such a client certainly has privacy implications which are documented here [2]. Most importantly, we record public IP addresses, successful NAT port mappings, and the login router page (to draw conclusions about which routers work better than others).
Optionally, you can also sign up here [3] and provide additional information about your personal network and receive a personal API key so that we can link your data to your information. Obviously, this has stronger privacy implications - but this is totally optional.
The most frictionless way to participate is to head to the releases page [4] and download a client that suits your platform and needs. No sign-up required.
[0] https://github.com/libp2p/specs/blob/master/relay/DCUtR.md
-
CCS Proposal: XMR-BTC Atomic Swaps GUI Desktop App - Continued development for 4 months
Rendezvous point: The rendezvous protocol is a lightweight mechanism for generalized peer discovery. It allows for the discovery of peers in a decentralized fashion. We operate a community rendezvous point through which swap providers can make themselves known to users, and through which users can find swap providers with whom they want to swap.(/dns4/discover.unstoppableswap.net/tcp/8888/p2p/12D3KooWA6cnqJpVnreBVnoro8midDL9Lpzmg8oJPoAGi7YYaamE)
-
This dude made an alternative Reddit on a blockchain. Crazy
It's not regular pubsub, it's "peer to peer pubsub". It's a pubsub, but p2p, anyone can join, subscribe, publish. The libp2p project has an implementation of this https://github.com/libp2p/specs/blob/master/pubsub/gossipsub/gossipsub-v1.0.md
rust-libp2p
-
On Implementation of Distributed Protocols
Substrate and Lighthouse use libp2p as a networking stack for communication between nodes. The libp2p framework is a versatile modular peer-to-peer networking stack. It provides a collections of abstractions, mechanisms, and protocols for facilitating communication in P2P systems. In particular, libp2p supports multiple transport mechanisms (TCP, QUIC, WebSocket, WebTransport, etc.), encryption schemes (TLS and Noise), and stream multiplexing. Higher-level protocols in libp2p are implemented on top of reliable, ordered, bidirectional binary streams, which are transparently encrypted and multiplexed by the framework.
-
Bifrost: A peer-to-peer communications engine with pluggable transports
It's a peer-to-peer "engine" with switchable components. Seems to run on different platforms (browsers, mobile, desktop, server).
At a glance, it looks pretty much like libp2p (https://libp2p.io/) but seems to integrate with libp2p as well (meaning you should be able to use Bifrost on one end, and libp2p on the other), so I'm guessing there is at least some fundamental difference, but I cannot spot it. Seems to use slightly different terminology compared to libp2p.
- Libp2p – A Modular Network Stack
- [AskJS] Any js browser based p2p libraries?
-
Decentralized Databases: ComposeDB
ComposeDB is a graph database created by 3BoxLabs, a company well-known in the Web3 ecosystem for their work on decentralized identifiers (DIDs) and their main product the Ceramic network. Ceramic is a network of nodes that store and share composable data streams on top of libp2p, the network stack that also powers IPFS.
-
What about a Zig implementation of lib2p2?
Yes, there is already a Rust version (https://github.com/libp2p/rust-libp2p) that behaves well at this level but I think we can reach a higher level of performance on this point with Zig. Also, if you look at the long term roadmap of libp2p (https://github.com/libp2p/specs/blob/master/ROADMAP.md), the mobile devices and IoT integrations for example are part of the considerations.
-
A Rust client library for interacting with Microsoft Airsim https://github.com/Sollimann/airsim-client
libp2p
-
Social Media on the Decentralized Web
At Filecoin Foundation, we see the technologies in the Filecoin ecosystem offering rock-steady stepping stones to this better future. Libp2p lets individual users find and talk to each other, without needing central servers. IPFS gives new services a way to find data, wherever it is stored — freeing them from dependence on one social media company over another and letting users move from one service to another. The Filecoin network itself, with incentivized storage, not only provides a provably stable basis for hosting content, but also shines a light on the kind of incentive systems that will enable independent social media to sustain and provide for itself for the long run, without relying on the largesse of the current tech giants.
-
Good sources to learn about IPFS?
Maybe https://libp2p.io
-
Fula: a new, innovative way to develop decentralized applications
So, after rolling my eyes and saying to myself 'not another web3 protocol', I began to understand the need for something new that not only takes advantage of the cutting edge in peer to peer networking but also acknowledges the fact that the client-server architecture is also not going away (which is incredibly important in a world full of low-powered, embedded devices).
What are some alternatives?
tribler - Privacy enhanced BitTorrent client with P2P content discovery
cosmos-sdk - :chains: A Framework for Building High Value Public Blockchains :sparkles:
py-ipv8 - Python implementation of Tribler's IPv8 p2p-networking layer
go-livepeer - Official Go implementation of the Livepeer protocol
komodo-wallet-desktop - Komodo Wallet Desktop GUI
y-crdt - Rust port of Yjs
xmr-btc-swap - Bitcoin–Monero Cross-chain Atomic Swap
freenet-core - Declare your digital independence
komodo-defi-framework - This is the official Komodo DeFi Framework repository
consensus-specs - Ethereum Proof-of-Stake Consensus Specifications
whitepaper
rust-crdt - a collection of well-tested, serializable CRDTs for Rust