HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
amark
gun
JavaScript2014–2024
amark / gun

gun

An open source cybersecurity protocol for syncing decentralized graph data.

45Distinct people
291Mentions
2Explicit recommenders
19.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

An open source cybersecurity protocol for syncing decentralized graph data.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

I was very excited about Datomic as well, but disappointed it wasn't Open Source. I decided to fix that + build something that combines my favorite features from Postgres,…

marknadal used a recommendation phrase. 7 indexed comments match. 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 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 2:04:58 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 year291 dated mentions

Observed mentions: 2014-10-19 14:21:58 UTC to 2024-10-08 16:25:37 UTC.

02040602014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 8 mentions; 2 submissions, 6 comments20142015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 39 mentions; 2 submissions, 37 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 52 mentions; 7 submissions, 45 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 67 mentions; 14 submissions, 53 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 59 mentions; 2 submissions, 57 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 40 mentions; 2 submissions, 38 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 18 mentions; 0 submissions, 18 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 4 mentions; 3 submissions, 1 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 2 mentions; 1 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
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC826
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC39237
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC52745
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC671453
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC59257
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC40238
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC18018
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC431
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC110
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC211
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
GUN is an ecosystem of tools that let you build community run and encrypted applications - like an Open Source Firebase or a Decentralized Dropbox. The Internet Archive and 100s of other apps run GUN in-production. Multiplayer by default with realtime p2p state synchronization! Graph data lets you use key/value, tables, documents, videos, & more! Local-first, offline, and decentralized with end-to-end encryption. Decentralized alternatives to Zoom, Reddit, Instagram, Slack, YouTube, Stripe, Wikipedia, Facebook Horizon and more have already pushed terabytes of daily P2P traffic on GUN. We are a friendly community creating a free fun future for freedom: Quickstart GUN is super easy to get started with: Try the interactive tutorial in the browser (5min ~ average developer). Or npm install gun and run the examples with cd node_modules/gun && npm start (5min ~ average developer). Note: If you don't have node or npm, read this first. If the npm command line didn't work, you may need to mkdir node_modules first or use sudo. An online demo of the examples are available here: http://try.axe.eco/ Or write a quick app: (try now in a playground) <script src="https://cdn.jsdelivr.net/npm/gun/gun.js"></script> <script> // import GUN from 'gun'; // in ESM // GUN = require('gun'); // in NodeJS // GUN = require('gun/gun'); // in React gun = GUN(); gun.get('mark').put({ name: "Mark", email: "mark@gun.eco", }); gun.get('mark').on((data, key) => { console.log("realtime updates:", data); }); setInterval(() => { gun.get('mark').get('live').put(Math.random()) }, 9); </script> Or try something mind blowing, like saving circular references to a table of documents! (play) cat = {name: "Fluffy", species: "kitty"}; mark = {boss: cat}; cat.slave = mark; // partial updates merge with existing data! gun.get('mark').put(mark); // access the data as if it is a document. gun.get('mark').get('boss').get('name').once(function(data, key){ // `once` grabs the data once, no subscriptions. console.log("Mark's boss is", data); }); // traverse a graph of circular references! gun.get('mark').get('boss').get('slave').once(function(data, key){ console.log("Mark is the cat's slave!", data); }); // add both of them to a table! gun.get('list').set(gun.get('mark').get('boss')); gun.get('list').set(gun.get('mark')); // grab each item once from the table, continuously: gun.get('list').map().once(function(data, key){ console.log("Item:", data); }); // live update the table! gun.get('list').set({type: "cucumber", goal: "jumping cat"}); Want to keep building more? Jump to THE DOCUMENTATION! About First & foremost, GUN is a community of the nicest and most helpful people out there. So I want to invite you to come tell us about what you are working on & wanting to build (new or old school alike! Just be nice as well.) and ask us your questions directly. :) Watch the 100 second intro! The GUN ecosystem stack is a collection of independent and modular tools covering everything from CRDT conflict resolution, cryptographic security & encryption, radix storage serialization, mesh networking & routing algorithms, to distributed systems correctness & load testing, CPU scheduled JSON parser to prevent UI lag, and more! On that note, let's get some official shout outs covered first: Support Thanks to:                Robert Heessels, Lorenzo Mangani, NLnet Foundation, Sam Liu, Daniel Dombrowsky, Vincent Woo, AJ ONeal, Bill Ottman, Mike Lange, Sean Matheson, Alan Mimms, Dário Freire, John Williamson, Robin Bron, Elie Makhoul, Mike Staub, Bradley Matusiak, Jeff Cook, Nico, Aaron Artille, Tim Robinson, Fabian Stamm, Mike Staub, Hunter Owens, Jacob Millner, Gerrit Balindt, Gabriel Lemon, Murage Martin, Jason Stallings Join others in sponsoring code: https://www.patreon.com/gunDB ! Ask questions: http://stackoverflow.com/questions/tagged/gun ? Found a bug? Report at: https://github.com/amark/gun/issues ; Need help? Chat with us: http://chat.gun.eco . History GUN was created by Mark Nadal in 2014 after he had spent 4 years trying to get his collaborative web app to scale up with traditional databases. After he realized Master-Slave database architecture causes one big bottleneck, he (as a complete newbie outsider) naively decided to question the status quo and shake things up with controversial, heretical, and contrarian experiments: The NoDB - no master, no servers, no "single source of truth", not built with a real programming language or real hardware, no DevOps, no locking, not just SQL or NoSQL but both (all - graphs, documents, tables, key/value). The goal was to build a P2P database that could survive living inside any browser, and could correctly sync data between any device after assuming any offline-first activity. Technically, GUN is a graph synchronization protocol with a lightweight embedded engine, capable of doing 20M+ API ops/sec in just ~9KB gzipped size. Documentation API reference Tutorials Examples GraphQL Electron React & Native Vue Svelte Webcomponents CAP Theorem Tradeoffs How Data Sync Works How GUN is Built Crypto Auth Modules Roadmap This would not be possible without community contributors, big shout out to: ajmeyghani (Learn GUN Basics with Diagrams); anywhichway (Block Storage); beebase (Quasar); BrockAtkinson (brunch config); Brysgo (GraphQL); d3x0r (SQLite); forrestjt (file.js); hillct (Docker); JosePedroDias (graph visualizer); JuniperChicago (cycle.js bindings); jveres (todoMVC); kristianmandrup (edge); Lightnet (Awesome Vue User Examples & User Kitchen Sink Playground); lmangani (Cytoscape Visualizer, Cassandra, Fastify, LetsEncrypt); mhelander (SEA); omarzion (Sticky Note App); PsychoLlama (LevelDB); RangerMauve (schema); robertheessels (gun-p2p-auth); rogowski (AXE); sbeleidy; sbiaudet (C# Port); Sean Matheson (Observable/RxJS/Most.js bindings); Shadyzpop (React Na
Read the full README on GitHub

What Hacker News says

39 sources
There seems to be a lot of interest in sync related protocols in this thread and dismissal of JMAP as a result. This is bad, because the current state if synchronization protocols still kinda sucks - full disclosure, I work on http://GitHub.com/amark/gun which is a JavaScript based syncing database. Getting synch right in p2p or federated systems (email) entails more detail than centralized ones. So any work on synchronization should be seen as favorable compared to how bad other protocols are for sync.
In Progress on JMAP, better standard for synchronising mail, calendars and contacts
It really is a challenge. I don't think it'll be realistic to build mid-size, fully offline web apps (excluding tools like electron) until indexedDB has wider support. One solution is to garbage collect the oldest data from localStorage and sync with a server when you've got connection, but once you're offline you're kinda stuck with 5mb. However, caniuse.com/#feat=indexeddb is optimistic about the future. The company I work for is trying to make offline/decentralized apps more realistic (gundb.io, github.com/amark/gun) and storage limitations can be aggravating at times.
In Kinto – open-source alternative to Firebase and Parse
I'm sad to hear I did a poor job explaining the concepts, thank you for this honest review. Next time around, I'll see if I can be more clear. One minor detail - while lexical sort is used in the conflict resolution algorithm it is only part of the equation (see https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... ). As I mentioned in my talk, lexical ordering is intentionally naive because I rely upon deterministic behavior (not PAXOS, RAFT, consensus, or gossip protocols) which guarantees convergence.
In I Dreamed of a Perfect Database
Thanks for the comment but I'm going to provide a hard rebuttal: 1) You assume that you have to have lots of code in order to solve hard problems. If that is your approach to code then I cannot appease you. GUN takes the UNIX/NodeJS philosophy - it is suppose to do one thing well and everything else is solved via extensions and plugins. What GUN focuses on is conflict resolution which you can see demos and learn more about here: https://youtu.be/-i-11T5ZI9o , https://github.com/amark/gun/wiki/Conflict-Resolution-with-G... , and towards the end of this tech talk https://youtu.be/kzrmAdBAnn4 . 2) I'm sorry you think my javascript is shoddy, however this is either a matter of arbitrary aesthetic opinion or some objective measure. You provide no objective measure. I'll propose one instead - does it work? And it does, however I'll be the first
Read the rest
to admit it is not free of bugs. We're actually dealing with some bad bugs that emerge when you do more complicated permutations of commands, to which we're in the middle of a big rewrite. I hope you'll find the new version (0.3.x, not out yet) as less shoddy. However apart from subjective aesthetics, I don't find your comment to have any justification. 3) What do you mean that we have scratch test data in there intermingled with the main code? I don't think this is true, but I'm not sure what you mean. If you think this is an issue it would be great if you raised an issue on the project. Thanks in advance. :) Please let me know if you've actually read through the entire wiki ( https://github.com/amark/gun/wiki ) and if there is anything you need to learn more about (which I'm sure there is) please don't hesitate to ask me and I'd be happy to write documentation on it. In fact, we need people like you to report what parts of the documentation are confusing or incomplete in order for us to know to fill it in. Thanks for your comments, and please don't take me harshly - I just want to be hard on dispelling the terrible assumption that lines of code equates to quality or problem solving. Often times more lines just creates more bloat, monolithism, and increased bug complexity.
In I Dreamed of a Perfect Database
Sorry, this is a terrible article. It reads more as a stream of consciousness about his own mistakes and sad regrets, and does not add any new or interesting insight into anything regarding databases. There are plenty of new cool things we can do now - and the graph database we're building ( http://github.com/amark/gun ) is doing several of those things. Like realtime by default, like what Firebase and RethinkDB are starting to push. Fully decentralized and fault tolerant, like what Riak and Cassandra tried to do. Graph (and not just triples) so you can have relational documents as ArangoDB and Neo4j allow. And absolutely totally offline-first, like what Pouch/CouchDB wanted to pioneer. The truth is the world of databases are only getting better and more exciting - in large part due to new algorithms like CRDTs that push what we can do. G
Read the rest
UN is one player in that along with others. But this article? Just depressing and overlooking all the new opportunities.
In I Dreamed of a Perfect Database
From your description I'm not quite sure where in the stack Irmin belongs? Is this to be used by web application developers? I assume note, as this looks like it is targeting more OS level development work? Pretty cool stuff. I am also working on a distributed database, https://github.com/amark/gun , that operates at the high level (web/javascript) rather than the low level. Although it looks like Irmin can be used in the browser? https://github.com/talex5/irmin-js ? Would love to hear some clarification.
In Irmin: Git-like distributed DB
No worries, getting database stuff correct is important and you have a right to know how things work before building anything on top of it. You don't want to build a house on a cracked foundation, I'm the same way and I'm trying my best to engineer these things properly. Here is a link explaining the algorithm https://github.com/amark/gun/issues/87#issuecomment-13636276... pretty briefly, it is also in a terrible location that nobody would know to look for (I need to move it out into the wiki or something). And to answer your question directly, here is how they compensate each other: 1. Timestamps' vulnerability is to accidental or malicious clock drift. I can change my machine's local clock to be 2 years in the future. If you use timestamps to decide who "wins" in a conflict, my edits will win for the next 2 years. That sucks and is evil
Read the rest
. 2. Vector clocks were invented to get around some of these problems. You increment a vector on every local change such that it is higher than the highest known vector. So Alice updates a value to "Hello World" at state 1, then to "Hello Mars" at state 2, if she then receives an update from Bob of "Hello Jupiter" at state 5, Alice then has to jump all the way up to and past Bob to change the value - say "Hello Pluto" at state 6. This gets around the timestamp vulnerability, because even if Bob were to say the update is at state 999998 all Alice has to do is increment it again to 999999, she doesn't have to wait 2 years or corrupt her clock. 3. Vector clocks' vulnerability is that since the clock is relative to the machine, if the machine reboots it loses its clock. Or even if the machine persists it, it has to play "catch up" when it comes back online - but while it is coming back online nothing stops two machines from accidentally incrementing to the same conflicting clock. At this point you are skrewed, unless you implement some other deterministic resolution - and plenty do exist. But the point of this is that vector clocks were designed for fairly permanent machines, but we now live in a emphemeral world where we might spin up a hundred servers to handle some load and then shut them down. If you do this, you lose the machine's vectors. 4. But timestamps don't have this problem, machines spinning up and down usually do some sort of NTP that gives them a rough estimate of time - drift aside, they don't need to remember anything. So when you combine these two together you get a vector timestamp relative to other vector timestamps. Aka every update includes its local timestamp (which might have drift) but the receiving computer calculates a vector relative to its own local timestamp (which might also have drift). If the sending peer is being malicious, the computed vector will be large which then receiving peer can use to mitigate the timestamp exploit. Equally as much, you can have any number of ephemeral peers coming and going through the network without fear of conflicts occurring or losing vectors. Does that make sense? I'll be presenting on these subjects at the conference, which Kyle Kingsbury is doing the keynote. So I'll have an opportunity to talk to him and I'm hoping he'll also review the algorithm (the actual algorithm is in the code which you should look at, and I linked to a brief explanation of it at the top of this post) and help me set up Jepsen tests. Overall, I need a LOT more documentation on this and I'm also wanting to formally verify it with TLA or Coq. We'll also be building a battle testing suite to hammer gun on in real deployed environments to see where problems lie. So please, give it a shot and slam me with any questions or problems you encounter. Have you seen this demo? https://medium.com/@marknadal/gun-0-2-0-pre-release-auto-rec... Cheers!
In Gun – “Self-hosted Firebase”
Good point, I'm definitely lacking coverage on my documentation. But we're working on it. GUN is a AP system, so you do not get Strong (Global) Consistency, instead it is Eventually Consistent and Highly Available. For more information on this, check out the wiki: https://github.com/amark/gun/wiki/CAP-Theorem . Basically you do NOT get linearizability for free, you have to build that ontop where it is baked explicitly into the data, with a CRDT or DAG or something. In the future, there should be extensions for this so you don't have to worry about it.
In Gun – “Self-hosted Firebase”

Showing the 15 most recent of 39 sources. Enable JavaScript to search and browse every indexed mention.

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.