SMsmartmic·Apr 22, 2026Submission
OpenDHT – Distributed Hash Table Implementation
1 points · Open discussionsavoirfairelinux
opendht
C++2015–2026
savoirfairelinux / opendht
opendht
OpenDHT: a C++17 Distributed Hash Table implementation
6Distinct people
7Mentions
1Explicit recommenders
1.2KGitHub stars
What to know before exploring
What it is
OpenDHT: a C++17 Distributed Hash Table implementation
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
Probably, but it is quite a neat technology. As people in this industry, we know what else it is being used for, and it serves those purposes pretty well. I love torrents. I…
johnisgood 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
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 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 year7 dated mentions
Observed mentions: 2015-05-08 19:51:36 UTC to 2026-04-22 20:36:29 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
7 sourcesHey, thanks! I've been into messaging for quite a long time - network protocols and particularly those involving online communication are among my favourite tech topics :) So yeah, I follow various projects.
You're right that there are pros and cons. Obviously, not having to run a server is a big pro for many. However, the first thing to remember when researching messaging solutions - no matter what anyone tells you - there are always servers! What differs between projects/platforms is what the servers do, and who runs them.
Jami uses a network of public servers that form a distributed hash table (see https://github.com/savoirfairelinux/opendht ). It's a neat design, and they have done a good job tackling the challenges of P2P messaging. Last time I looked in, it still required both users to be connected at the same time for message deliv
Read the rest
ery/sync to work (the devices use the DHT to discover each other, and then exchange messages). This is a fairly common issue for P2P systems, and can be frustrating in a mobile-dominated world. Their DHT software does support push notifications, which helps with that though.
Another project in this category is Briar, which uses the existing network of Tor servers - and therefore adds IP address masking and a layer of metadata protection (as always, there are limitations, e.g. https://code.briarproject.org/briar/briar/-/wikis/FAQ#does-b... ). Briar built the concept of "mailbox" nodes you can run ( https://briarproject.org/download-briar-mailbox/ ) to overcome some of the problems with P2P messaging.
With Snikket, instead of using existing publicly shared infrastructure, you just run your own server (e.g. VPS or Raspberry Pi or whatever) which is responsible just for your users, and your users connect directly to it, improving (meta)data locality. This makes the design very simple, reliable and efficient (e.g. with battery/bandwidth). It also enables some important (for our use case) convenience/UX features, such as the ability to add restrictions on certain accounts (e.g. for children), and server-managed contact lists so all your family members don't have to manually add each other as contacts one-by-one. Things like that.
No approach is universally better than every other, but I much prefer the Snikket model for the family-and-friends use case. Not that we don't have our own challenges. Our iOS app is probably the weakest part right now (in terms of UX and general polish). Something I'm working hard to get fixed in 2025.
Probably, but it is quite a neat technology. As people in this industry, we know what else it is being used for, and it serves those purposes pretty well. I love torrents. I love the technologies that it uses. Many other projects use it, for example take a look at https://docs.ipfs.io/concepts/dht and https://github.com/savoirfairelinux/opendht just for DHT alone. There is also https://en.wikipedia.org/wiki/Magnet_URI_scheme. There are many more, just too lazy to find them at the moment, but believe me, the things you will encounter once you go down this road, is truly amazing. Worth it!
In Ask HN: What is your favorite method of sending large files?OpenDHT: A C++14 Distributed Hash Table implementation
2 points · Open discussionThis is the classic "Gnutella problem" of scalability and is still I believe very much an open problem. One runs into it in WebRTC multicast scenarios. But fortunately there are many vendors such as Twilio that provide cloud solutions ;)
Best solution is to overlay a distributed hash table as k-v store over the p2p network. Nodes can then query that instead of each other. You can make your implementation more robust by exploiting and rewarding nodes in the network that have faster net connections, more compute power, etc. Best of luck!
OpenDHT: A C++11 Distributed Hash Table implementation
https://github.com/savoirfairelinux/opendht
In Ask HN: What's a good algorithm to distribute data in a P2P networkIt may not be the implementation you referred to, but
https://github.com/savoirfairelinux/opendht
exist and is used by the Ring distributed communication platform along with SIP (ring.cx) to implement the account less, P2P and PKI encrypted communication.
(disclaimer, I have previously worked on Ring.cx)
In Distributed Hash Table Protocol (2008)In all honesty, the decision was taken by the project sponsor and is final. We built this https://github.com/savoirfairelinux/opendht and it is already used by some other projects distributed outside of Savoir-faire Linux. So far things look well for OpenDHT so I don't think Savoir-faire Linux will change its mind of the decision at this point. I know you think this is a duplicated effort, but it might not be as true as you think. I respect and understand your frustration, but the decision is final.
However, do you have a link about the Tox 4chan DOS? A quick Google search failed to turn interesting results.
In Ring: Free software for distributed and secured communication