12 ms·

Show HN: Gun v0.1.0 – The Easiest Database Ever

173 points by marknadal 12y ago

Yadi 12y ago
Hey Mark! Congrats, it looks awesome, good to see this here!
marknadal 12y ago
Hey everyone! If you have any questions, I'll be here for the next several hours. Also check out the GitHub Wiki: https://github.com/amark/gun/wiki https://github.com/amark/gun/wiki .
SlyShy 12y ago
I don't know if I should consider this "the easiest database ever" or "gun is not a database" (from the FAQ). Github says "a distributed, embedded, graph database engine". I think some clarification around the marketing could do a world of good.
- marknadal 12y ago
  Good point, oh boy - caught me red handed. shameshame. What I'm trying to get across is that it is the easiest database because it is not your traditional master-slave database, and it doesn't require maintaining any database process. It is indeed just a cache, but it has all the benefits of a database.
  - lberger 12y ago
    I'm lost. How does it have all the benefits of a database, without any persistence? That doesn't sound like a database at all.
    - marknadal 12y ago
      Persistence is just a plugin/module/hook. Currently it plugs into a very never-should-ever-be-deployed file on disk (for easy local testing only) and S3. We're going to be adding more storage engines though! Hopefully building an open source S3 that uses fancy algorithms to store on disk and on peers. However I don't know that stuff, somebody else is doing it (or I'm hiring - we're funded!).
- mdcox 12y ago
  Agreed. I read through the whole site and never saw the word "graph" until I came back and read this comment which puts me a bit on edge. Seems like a good idea, but when the marketing seems to imply a purpose defined via shotgun approach, I start to get wary of a possible hype machine.
  - marknadal 12y ago
    Other than a few contributors, it is basically just me. But I'm hiring! (We're funded). So TBH, I kinda have to try doing the hypemachine thing to get the word out. :( Does that make me evil?
    - mdcox 12y ago
      Hype and marketing can be great! It's empty hype with nothing to back it up that worries me. I don't think that's Gun, but the "throw buzz word" style marketing (especially if there are contradictions) instantly puts me on guard. If Gun solves a problem, then by all means get the word out about it any way you can!
theseoafs 12y ago
I dislike that the webpage actually has very little information about what the tool does, what use cases it is suitable for, what the architecture is like, etc. Here's an important question the homepage doesn't answer: is it ACID?
- marknadal 12y ago
  Good point, I'll try and move the blog to another page and replace it with more details. The fastest summary is that it is an Open Source Firebase. Flat up answer for ACID: honestly, not how you traditionally would think, as it favors AP of the CAP theorem. However, ACID terminology is actually pretty vague (http://en.wikipedia.org/wiki/ACID http://en.wikipedia.org/wiki/ACID). Here is my comments about ACID in the code: A - Atomic, if you set a full node, or nodes of nodes, if any value is in error then nothing will be set. If you want sets to be independent of each other, you need to set each piece of the data individually. C - Consistency, if you use any reserved symbols or similar, the operation will be rejected as it could lead to an invalid read and thus an invalid state. I - Isolation, the conflict resolution algorithm guarantees idempotent transactions, across every peer, regardless of any partition, including a peer acting by itself or one having been disconnected from the network. D - Durability, if the acknowledgement receipt is received, then the state at which the final persistence hook was called on is guaranteed to have been written. The live state at point of confirmation may or may not be different than when it was called. If this causes any application-level concern, it can compare against the live data by immediately reading it, or accessing the logs if enabled. If you have any specific further questions I am happy to answer. It has support for vector-clock/timestamp "state" transactions.
  - akerl_ 12y ago
    I'm attempting to draw a connection between your comments on ACID and what ACID actually means, and there doesn't appear to be any parallel.
    - marknadal 12y ago
      I understand what you mean. Could you do me a favor and point me to your favorite description of ACID?
protomyth 12y ago
Congrats. What is the license? I must be missing where it is and the source code I checked doesn't have it.
- marknadal 12y ago
  Thanks! Honestly, I might put this up to an open-source vote. I personally learn towards the MIT and the ZLIB license, http://en.wikipedia.org/wiki/Zlib_License http://en.wikipedia.org/wiki/Zlib_License . However I also know a lot of other databases are doing AGPL, I think for monetary reasons. Which :/ I might also want to consider. But as I said, I honestly think this should be a combination of community decision. Could people reply back with what license they'd like?
  - wongarsu 12y ago
    If you want everyone to use your database, MIT or ZLIB are clearly superior. For you(r company) that would limit your monetization options to support and similar, which is certainly not ideal. If you value free software (as opposed to open source), AGPL is a good option and allows you to sell more permissive licenses to everyone who needs one. If you actually want to make money with this, it's really a question of your business model. I would use it with either license.
    - lclarkmichalek 12y ago
      Why would using AGPL imply not valuing open source?
      - jackbravo 12y ago
        Because open source guys value having more people using your code, and using AGPL discourages some people from using it because they can't keep their modifications private?
samuelcouch 12y ago
This is really awesome! Excited to use it.
lux 12y ago
As a "self-hosted Firebase", I'd love to see something like their integrations with various JS frameworks, for ex: https://www.firebase.com/docs/web/libraries/react/ https://www.firebase.com/docs/web/libraries/react/
- marknadal 12y ago
  YES! We're actively working on trying to get adapters built for React, Angular, Ember, Backbone, etc. but we're a super tiny team. Would you be interested in contributing? You could really help make a big difference.
  - lux 12y ago
    Awesome! I've starred the project on Github. I'm in startup mode and juggling way too many things these days, but maybe I can find a free evening :)
    - marknadal 12y ago
      sweet, shoot me an email mark@gunDB.io to talk more.
fiatjaf 12y ago
The demo is a little confusing because it loads two iframes and seen to be faking it, but yes it works and no, it is not faking it. https://dl.dropboxusercontent.com/u/4374976/gun/web/tabs.html?key=random/sdcws4mU0 https://dl.dropboxusercontent.com/u/4374976/gun/web/tabs.htm...
- marknadal 12y ago
  Thank you for noticing this. :) My original tutorial actually required the user to physically open up multiple tabs and have them be side-by-side. However it was a mess and people didn't like it. So I opted to fake it... while still depending upon the real tech underneath. HOWEVER, it is just running on a freebie heroku box, so it is probably bound to crash/fall-over soon.
fiatjaf 12y ago
If it "is just a cache" and the data is distributed among every client, where is the data at each time before it is persisted to S3?
- marknadal 12y ago
  Great question, I'm going to C&P a reply I did previously: 1. In memory in the browser tab's process. 2. If available, in the browser's localstorage or fallback. 3. In the server process's memory. 4. If available, on disk in the server. 5. If in a multi-machine setup, any other connected server that is subscribed to that data set, being in memory (3) or in disk (4) if available. 6. If configured, in a machine log on S3. 7. Persisted to S3, which replicates and shards it for you internally. 8. If configured, in a revision file on S3. 9. If configured, in a multi-region S3 setup, redundantly in many places. (2) is not cleared till an acknowledgment that (7) is confirmed. (1) is not cleared until an acknowledgement that (7) is confirmed or if the tab is exited. In the case of (7) it is no longer the delta/diff, but a snapshot of that current data set with that delta/diff's update. Retries from (1) ~ (5) will happen at various events, if the confirmations are not satisfied. If a conflict has already occurred by (3) the acknowledgement from (5) will include a notification that the value has already been updated, along with the standard delta/diff of that conflicting update being sent down. Meaning (5) does not guarantee that your delta/diff has "won", only that it has been saved or is already outdated. Worst case condition is that (2, 4, 5, 6, 8, 9) are turned off, in which your user's data is as volatile as them preemptively leaving the page (although I suppose you could use an onbeforeunload to warn them) - however this behavior is the current norm for most http post based forms and apps. Actually, pardon me, worst case condition is that everything is offline simultaneously, however this is not really interesting because then users won't even be able to access your app in the first place.
glittershark 12y ago
You guys seriously need to work on your SEO - Googling "gundb" has the page show up with the text "Your browser does not support frames...".
- marknadal 12y ago
  Oh my goodness #fail. Thank you for spotting this. I'll try to figure out how to fix it (probably by not being cheap by domain masking).
gkya 12y ago
I wanted to read the text on the page, but the styling, with the shadow, or the gloss, or whatever it is, it is giving my astigmatic eyes pain, so I couldn't, I'm sorry.
- sanderjd 12y ago
  Ha, yeah, I thought my eyes were broken. Turns out it's using the `text-shadow` css property. Much more readable after I turned that off.
- marknadal 12y ago
  sorry about that. IDK why but it makes it easier on my eyes, maybe I should do a survey (I'm probably just weird) and then fix it.
  - evilduck 12y ago
    text-shadow: 0px 0px 7px #DDD; That 3rd number is a 7px blur radius starting from a 0,0 point and #DDD is light grey, blurring between solid black and solid white. I think you're just weird, very few people consider blurry text preferable.
  - adambard 12y ago
    I definitely remember complaining about this exact thing a year ago :P. At least you toned down the shadow a bit.
    - marknadal 12y ago
      awwwe you remember me! Happy face! For... being "that guy" that had blurry text. Shoot, sad face. Thanks for sticking around :).
      - adambard 12y ago
        Heh, I remembered the project too, I was just reminded of the blurry text by the blurry text. If you find a high contrast hard on the eyes you could drop it a bit by just making the lettering a lighter grey in leiu of the drop shadow. Just don't overdo it or you'll get people complaining about that.
barakm 12y ago
From the blog: > Because gun is not a database (NoDB), it is a persisted distributed cache. This I believe. > The fatal flaw with databases is that they assume some centralized authority. While this may be the case initially when you are small, it always ceases to be true when you become large enough that concurrency is unavoidable. Partially true. Though that's not necessarily a "fatal flaw", and calling it such is troubling. Yes, concurrency is unavoidable when you become large enough but you also want your data to be, well, consistent and persistent, but then you go on... > No amount of leader election and consensus algorithms can patch this without facing an unjustified amount of complexity. Gun resolves all this by biting the bullet - it solves the hard problems first, not last. Where in the code, pray tell, is it solving these problems? The fact that you also claim to be an AP system (and conflate this with ACID) makes me strongly wonder what your notions on Consistency actually are. "Just a cache" needs some consistency as well, I'll point out, but you may not care as much about stale reads. > It gets data synchronization and conflict resolution right from the beginning, so it never has to rely on vulnerable leader election or consensus locking. From what I'm starting to understand you're, at best, shuffling that off to S3 or "other storage engines" -- you've still got to pay the cost. You can't really claim to do linearizability without, well, actually doing linearizability. So, maybe it's a cache, sure. And you seem to like to work on the developer API, nothing wrong there. But there's nothing new under the sun and I'm really skeptical that hard distributed database problems are solved in one large JS file.
- stephanfroede 12y ago
  What are "hard distributed database problems"? I came to the conclusion that they do exist, but I have observed a need to manage millions of tiny write transactions per second-> IoT.
  - marknadal 12y ago
    I've come to a similar conclusion. The smaller your updates are the better, and allow for cleaner data sync. Check out my other reply.
- marknadal 12y ago
stephanfroede 12y ago
Cool approach. I had some fights with Neo4J and taming IO. I did fall back on a 2nd Level Cache, which is nothing else than a huge hash map/KV store in memory.
- marknadal 12y ago
  Thanks! Interested in joining and working on these types of problems? You seem to have some pretty good skills. Shoot me an email mark@gunDB.io
eridius 12y ago
Why is it called Gun? The name is a little off-putting. What's next, a database called Kill? How about Murder? Genocide? Edit: The fact that I'm being downvoted for voicing a concern about the naming is really disappointing. This is a serious issue, and I would appreciate a response, not being buried.
- tlrobinson 12y ago
  The fact that you're being downvoted suggests most people strongly disagree that this is a "serious issue".
- marknadal 12y ago
  I didn't downvote you, so please don't think I'm the one trying to bury you. I'm calling it GUN because it is powerful and therefore a dangerous tool to wield. Because I'm going with a fully decentralized/distributed system, it has also generated some controversy with people. Fact is, centralized/master-slave consensus based databases are incredibly popular right now. Things like Riak, Cassandra's CRDTs are not getting enough traction as they should - but probably because they can be difficult to set up. I'm trying to blow this all out of the water and make distributed database systems easy for developers. So I'm admittedly going for an edgy name. I'm not wanting to kill anybody, just centralized software.
  - eridius 12y ago
    Thanks for the response. I didn't think you were the one trying to bury me, but I appreciate the fact that you care. I'm glad to hear that you are aware of the fact that this is a loaded term and that you intentionally chose it because you wanted an edgy name. While I'm still not a fan of it, I feel much better about it knowing the reason behind the naming. And I think you need to put this info somewhere on the site and the GitHub project. I read gunned.io, and I skimmed the README of your GitHub, and nowhere did you even acknowledge that the name was edge, much less indicate that this was an intentional choice. I would urge you to add a FAQ entry on gundb.io, add a wiki page to your GitHub repo, and put a line somewhere in the README (perhaps at the bottom) linking to that wiki page. Otherwise, you're going to end up with more people than just me thinking that you chose a potentially-offensive name as opposed to a deliberately edgy one. Speaking of your GitHub repo, you should also add gundb.io as the webpage for the repo, and probably link to it in the README.
mmagin 12y ago
"With all new flavors like banana, fizzbitch, and GUN!" https://www.youtube.com/watch?v=t-3qncy5Qfk https://www.youtube.com/watch?v=t-3qncy5Qfk
ArekDymalski 12y ago
It looks very promising. However I wonder who is the intended user of Gun: 1. "full-stack" developers who just want to save time and/or benefit from NoDB aspect 2. Beginners and front-end developers who don't anything about databases? In case of group 1 your marketing seems to be insufficiently technical as many people here have already noted. In case of group 2 (which I belong to) things look completely different. As a beginner whose learning efforts are constantly disheartened by tutorials and courses which end at "locally hosted HelloWorld app" phase, I'd be more than happy seeing: 1. step-by-step, layman-friendly tutorial on installing Gun on S3 and other platforms. 2. very well commented example app demonstrating how to create typical functionalities. With such approach you will keep the "Dropbox of databases" promise which sounds very exciting. Actually I think that something like this should be an obligatory feature on Codeacademy or any web development MOOC dedicated to beginners.
- marknadal 12y ago
  Great questions. 1. As of right now, focusing on beginner/front-end devs who just want an easy open source Firebase like database. People building small experimental apps, since we have finished our battle-testing suite yet. However, I'd also highly encourage full stack developers to get involved and try it out and give us feedback. For small projects it'll probably save you time, but the plugin/modules ecosystem (aka features) aren't mature enough that you'll be writing a lot of your own logic. Which please do! We need them! If you don't want to run GUN on localhost, I'll host a GUN server for you. :) You are right, I need to get better docs/tutorials and information out on this, so laymen don't get disheartened. Is there anything I can do to help? Thanks for your comment!
  - ArekDymalski 12y ago
    Thanks Mark, I'll keep an eye on the docs page then. I'll also keep the thumbs up :)
rawnlq 12y ago
Have you heard of sharejs http://sharejs.org/ http://sharejs.org/? It's made by an ex-Google-wave engineer and uses operational transforms for eventual consistency. It seems like you guys are solving similar problems. I mention this because Dropbox has their own "Dropbox for Databases" called Datastore: https://www.dropbox.com/developers/datastore https://www.dropbox.com/developers/datastore which is based on Operational Transforms: https://blogs.dropbox.com/developers/2013/07/how-the-datastore-api-handles-conflicts-part-1-basics-of-offline-conflict-handling/ https://blogs.dropbox.com/developers/2013/07/how-the-datasto...
- marknadal 12y ago
  Actually yes! I'm one of the people who accidentaly sparked a long discussion in the #1 issues thread: https://github.com/share/ShareJS/issues/1 https://github.com/share/ShareJS/issues/1 that I've seen other people on HN link to. GUN doesn't have OT-style text collaboration yet, so go with ShareJS if that is what you need now. I do plan on implementing it on top of GUN though, or trying to get ShareJS integrated with GUN. Joseph is a really great guy. Yupe, I've talked to Steve Marx at Dropbox Datastore at a hackathon before. He's a great guy as well. They're using algorithms that require some centralized conflict resolution though. Which is great, but I'm interested in the decentralized side.
kainolophobia 12y ago
I've looked at your "Hypothetical Amnesia Machine algorithm" and have a few questions. First though, I'd like you to read this: http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...
- marknadal 12y ago
  Yes, I've looked at this paper before - I should reread it though. I've done a tech talk (not recorded though) on the pros/cons of vector-clocks and timestamps. I have some very specific insights which I should probably write a paper on. Or at least get the tech talk recorded or written down. There are some slides at the bottom of: https://github.com/amark/gun/wiki/How-to-Create-GUN https://github.com/amark/gun/wiki/How-to-Create-GUN . What questions may I answer?
bhz 12y ago
Have you tried redis? http://try.redis.io/ http://try.redis.io/
- marknadal 12y ago
  I love redis! My first proof of concept of GUN used redis as the persistence/storage layer. But I moved off of it since I wanted a fully embedded solution. Data wise the difference is that Redis doesn't support graphs. But you could easily build that on top of Redis, so you could argue GUN is just graph data ontop of Redis (well, not anymore) with a conflict resolution algorithm baked in.
  - bhz 12y ago
    I'll have to give Gun a go when I have the chance. Thank you for providing the contrast.
nolanl 12y ago
Interesting project! It seems to share a lot of the goals and design choices of PouchDB/CouchDB: distributed, offline-first, eventually consistent, deterministic conflict resolution, etc. One big difference I can see is that it's only using LocalStorage, which has good cross-browser support, but only allows 5-10MB maximum. Are there plans to add IndexedDB/WebSQL support so that users can store more data?
- marknadal 12y ago
  Yes! Thanks. LocalStorage implementation is just the default plugin, and I chose it first because of its compatibility. I'd like to get IndexedDB support in there as well. Interested in helping?
karlgrz 12y ago
I would really love if this actually worked as promised. Way too much skepticism and not nearly enough proof. Kudos for actually putting this out there, though. It'd be great to prove everyone wrong, but I will not hold my breath. Good luck!
- marknadal 12y ago
  You can try messing with it yourself by, doing (if you already have node/npm/git installed and familiar with terminal): git clone http://github.com/amark/gun cd gun/examples && npm install node express.js 8080 Then open it in a couple of browser tabs on different devices, change their system clock, try refreshing data, crashing things. etc. I'm also trying to figure out how to write simulated tests (like Jepsen) that will do all of this for you and give you the results of what failed/succeeded. Till then, let me know if you see anything break.
  - karlgrz 12y ago
    I'm not going to spin this up on 1000 nodes to make sure it handles the kind of load needed to simulate actual production traffic (which is what you would need to actually figure out if this would hold up to some kind of large scale load that Riak or Cassandra would be able to handle). Maybe you should do that yourself and document it to prove how good your product is!
    - marknadal 12y ago
      You don't need to spin up a 1,000 nodes. You can just spin up a 1,000 tabs. Since they all run the same algorithm! Yes, I am working on more tests to prove myself wrong or right. Please bare with me as I/we make progress, because it is literally only a few contributors and me. This is v0.1.0 for a reason, not v1. Lots ahead, but please play with it while we work on developing the test suite.
      - karlgrz 12y ago
        I appreciate the suggestion and response. Understand it is v.0.1.0 but you should also understand that when you bring something like this out with next to no academic backing behind your theories and algorithms there is DEFINITELY going to be skepticism and doubt. You are exactly right, though. It's early, and I'll give you the benefit of the doubt that you will achieve what you want. Also know that there is a TON of research in these areas (which you clearly are aware of based on your comments in this thread) that basically refutes a lot of what you are claiming. I would love to see more clear documentation along with actual proofs showing how your algorithm is sound. Until then, good luck, and I look forward to hearing about your success!
danbruc 12y ago
There is no way this can work. Merging data changes can inherently not be automated in the general case. Deciding if a change from foo to bar should win over a change from foo to baz depends on the semantics of those strings. There are some cases, for example counters, with simple and clear semantics where you can build reusable and robust solutions for. You can also handle the general case with simple policies like last write wins. But there is no way any algorithm will ever be able to figure out whether to choose bar or baz, not at last because I could arbitrarily declare any of the two outcomes correct.
- marknadal 12y ago
  Every change can be preserved in a history/append-only/log/stream. So you don't have to "lose" data from another "winning". However, the algorithm will by default select one, you can then code it at the app level for the user to select a new winner. The general case here is very UUID based key/value pairs. Anything beyond that, you should be using CRDTs and OT like algorithms, which I will be building on top of GUN. However, in the meanwhile, I challenge you to try running the example folder from the GitHub ReadMe and seeing if you can break the automated sync and cause data divergence! Edit: This person (in the comments below, please upvote him), and my reply, best addresses the most important questions: https://news.ycombinator.com/item?id=9077969 https://news.ycombinator.com/item?id=9077969
curiously 12y ago
this seems like a great tool. hosting firebase on my own is what I want to build real time apps, is this possible? I have the same concerns for meteor which I have for this as well, which is security and scalability. How does Gun address those two things?
- marknadal 12y ago
  Great questions. Hosting on your own: Yes. Security: Currently a "Roll Your Own" approach, where you wrap GUN behind some firewall/throttling like system. Why? Because permissions are so app-specific behavior, I haven't figured out how to generalize it. I don't think it is possible to do it, so in the future we'll probably provide various security plugins that come with app specific assumptions. Scalability: Run the example folder in the GitHub Readme, and open up hundreds of tabs. Gun is running individually in all of them. See how it handles that. I'm trying to have a production-grade battle-testing suite developed soon, such that you could just run a script, it would ask you how much you want to spend on the test, and then it would deploy a ton of GUN peers to the cloud and generate a ton of traffic and load. This is not available yet, but something I'm focusing on within the next 6months or year. Anything I can help with?
tomphoolery 12y ago
> 400 Bad Request https://github.com/amark/gun https://github.com/amark/gun
- marknadal 12y ago
  oh snap, the HN "DDOS" has peaked! I'll see what I can do to get things back online. Thanks for putting the github link in here in case others get the same issue.
bitanarch 12y ago
A few questions. 1. How do you define the operating boundaries for your time stamps? What is too low and too high and why? 2. What are the expected use cases for your conflict resolution algorithm? The HAM function you proposed would just overwrite one string with another and so for things like collaborative document editing, user intention isn't preserved. 3. Where is the vector clock defined in your code? I can only see Gun.time.is() in a brief glance at your code... and it is just getting the UNIX timestamp in milliseconds.
- marknadal 12y ago
  Wonderful questions! Actually some of the best in the entire thread I think. 1. See (3) but first read: A) The upper boundary is defined by the current machine's local clock, which could have skew or drift. B) The lower boundary is defined by the last known update on an individual record (down to the UUID+field). 2. The expected use case is for this conflict resolution algorithm is for basic field/value pairs (terms defined here: https://github.com/amark/gun/wiki/semantics https://github.com/amark/gun/wiki/semantics, and here: https://github.com/amark/gun/wiki/JSON-Data-Format https://github.com/amark/gun/wiki/JSON-Data-Format) within a UUID an object (called a node, as in a node in a graph). This is what HAM works off and is considered the lowest level atomic pieces (the value). In order to sync on collaborative text you need to build an OT layer on top of this (I plan on doing this, possibly integrating with ShareJS as another mentioned). You cannot collaboratively sync on atomic values by themselves, you must define a CRDT for that - plugins/modules for them will be coming later. 3. Vector Clocks. HAM does not assume what the sort key is for state, it just assumes it is a value it can do <, <=, ===, =>, > comparisons on. A) Vector clocks have a vulnerability that if you are working with temporary/ephemeral machines, the clocks will constantly get reset and have to play "catch up". However, network partitions are highly likely, so there is no guarantee that two machines won't issue a conflicting vector clock. If this happens, there is no standard way of dealing with this, although there are plenty of work arounds. B) Timestamps also have a vulnerability, that is if you set your local clock ahead (say 2 years in the future) then it will "always win" wiping out other peers valid values. However you unfortunately cannot determine in an untrusted network whether a peer is being malicious about being 2 years in the future, or if they are actually at a different point in timespace - like a GPS satellite or on Mars, or went offline in the subway. C) As a result, this is why I combine them together via the boundary function. The upper and lower boundaries of the state machine provide the relative "vector" for the untrusted timestamp in the delta update. The benefits of this technique are two fold: 1) You get deterministic and idempotent resolution within a special-relativity timeframe in a decentralized system without gossip (consensus). 2) If you do run GUN within your own trusted network, you can use the timestamps to calculate drift between machines and then readjust the boundary function of the state machine. Thus giving you a highly accurate "objective" view of your data across peers, which if the latency is low enough could indicate it is worth creating locks (but thus sacrificing Availability). Hope this was clear enough! Any questions? I'm going to be reposting this in the rest of the thread.
trithagoras 12y ago
...Is there a glow effect around all the text?
sigmonsays 12y ago
This is the best troll ever
dang 12y ago
A few disagreements in this thread have crossed over into being disrespectful. This is a gentle reminder that you can (and on Hacker News, please do) disagree without calling names. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html
nathan7 12y ago
Awesome to finally see Gun on here, Mark! What still worries me is the reliance on external storage services, although a good local storage service could be built for Gun. Other than that, I'm glad to finally see docs!

173 points by marknadal 12y ago

Yadi 12y ago

Hey Mark! Congrats, it looks awesome, good to see this here!

Hey everyone! If you have any questions, I'll be here for the next several hours. Also check out the GitHub Wiki: https://github.com/amark/gun/wiki https://github.com/amark/gun/wiki .

SlyShy 12y ago

I don't know if I should consider this "the easiest database ever" or "gun is not a database" (from the FAQ). Github says "a distributed, embedded, graph database engine". I think some clarification around the marketing could do a world of good.

marknadal 12y ago
Good point, oh boy - caught me red handed. shameshame. What I'm trying to get across is that it is the easiest database because it is not your traditional master-slave database, and it doesn't require maintaining any database process. It is indeed just a cache, but it has all the benefits of a database.
- lberger 12y ago
  I'm lost. How does it have all the benefits of a database, without any persistence? That doesn't sound like a database at all.
  - marknadal 12y ago
    Persistence is just a plugin/module/hook. Currently it plugs into a very never-should-ever-be-deployed file on disk (for easy local testing only) and S3. We're going to be adding more storage engines though! Hopefully building an open source S3 that uses fancy algorithms to store on disk and on peers. However I don't know that stuff, somebody else is doing it (or I'm hiring - we're funded!).
mdcox 12y ago
Agreed. I read through the whole site and never saw the word "graph" until I came back and read this comment which puts me a bit on edge. Seems like a good idea, but when the marketing seems to imply a purpose defined via shotgun approach, I start to get wary of a possible hype machine.
- marknadal 12y ago
  Other than a few contributors, it is basically just me. But I'm hiring! (We're funded). So TBH, I kinda have to try doing the hypemachine thing to get the word out. :( Does that make me evil?
  - mdcox 12y ago
    Hype and marketing can be great! It's empty hype with nothing to back it up that worries me. I don't think that's Gun, but the "throw buzz word" style marketing (especially if there are contradictions) instantly puts me on guard. If Gun solves a problem, then by all means get the word out about it any way you can!

theseoafs 12y ago

I dislike that the webpage actually has very little information about what the tool does, what use cases it is suitable for, what the architecture is like, etc. Here's an important question the homepage doesn't answer: is it ACID?

marknadal 12y ago
Good point, I'll try and move the blog to another page and replace it with more details. The fastest summary is that it is an Open Source Firebase. Flat up answer for ACID: honestly, not how you traditionally would think, as it favors AP of the CAP theorem. However, ACID terminology is actually pretty vague (http://en.wikipedia.org/wiki/ACID http://en.wikipedia.org/wiki/ACID). Here is my comments about ACID in the code: A - Atomic, if you set a full node, or nodes of nodes, if any value is in error then nothing will be set. If you want sets to be independent of each other, you need to set each piece of the data individually. C - Consistency, if you use any reserved symbols or similar, the operation will be rejected as it could lead to an invalid read and thus an invalid state. I - Isolation, the conflict resolution algorithm guarantees idempotent transactions, across every peer, regardless of any partition, including a peer acting by itself or one having been disconnected from the network. D - Durability, if the acknowledgement receipt is received, then the state at which the final persistence hook was called on is guaranteed to have been written. The live state at point of confirmation may or may not be different than when it was called. If this causes any application-level concern, it can compare against the live data by immediately reading it, or accessing the logs if enabled. If you have any specific further questions I am happy to answer. It has support for vector-clock/timestamp "state" transactions.
- akerl_ 12y ago
  I'm attempting to draw a connection between your comments on ACID and what ACID actually means, and there doesn't appear to be any parallel.
  - marknadal 12y ago
    I understand what you mean. Could you do me a favor and point me to your favorite description of ACID?

protomyth 12y ago

Congrats. What is the license? I must be missing where it is and the source code I checked doesn't have it.

marknadal 12y ago
Thanks! Honestly, I might put this up to an open-source vote. I personally learn towards the MIT and the ZLIB license, http://en.wikipedia.org/wiki/Zlib_License http://en.wikipedia.org/wiki/Zlib_License . However I also know a lot of other databases are doing AGPL, I think for monetary reasons. Which :/ I might also want to consider. But as I said, I honestly think this should be a combination of community decision. Could people reply back with what license they'd like?
- wongarsu 12y ago
  If you want everyone to use your database, MIT or ZLIB are clearly superior. For you(r company) that would limit your monetization options to support and similar, which is certainly not ideal. If you value free software (as opposed to open source), AGPL is a good option and allows you to sell more permissive licenses to everyone who needs one. If you actually want to make money with this, it's really a question of your business model. I would use it with either license.
  - lclarkmichalek 12y ago
    Why would using AGPL imply not valuing open source?
    - jackbravo 12y ago
      Because open source guys value having more people using your code, and using AGPL discourages some people from using it because they can't keep their modifications private?

samuelcouch 12y ago

This is really awesome! Excited to use it.

lux 12y ago

As a "self-hosted Firebase", I'd love to see something like their integrations with various JS frameworks, for ex: https://www.firebase.com/docs/web/libraries/react/ https://www.firebase.com/docs/web/libraries/react/

marknadal 12y ago
YES! We're actively working on trying to get adapters built for React, Angular, Ember, Backbone, etc. but we're a super tiny team. Would you be interested in contributing? You could really help make a big difference.
- lux 12y ago
  Awesome! I've starred the project on Github. I'm in startup mode and juggling way too many things these days, but maybe I can find a free evening :)
  - marknadal 12y ago
    sweet, shoot me an email mark@gunDB.io to talk more.

fiatjaf 12y ago

The demo is a little confusing because it loads two iframes and seen to be faking it, but yes it works and no, it is not faking it. https://dl.dropboxusercontent.com/u/4374976/gun/web/tabs.html?key=random/sdcws4mU0 https://dl.dropboxusercontent.com/u/4374976/gun/web/tabs.htm...

marknadal 12y ago
Thank you for noticing this. :) My original tutorial actually required the user to physically open up multiple tabs and have them be side-by-side. However it was a mess and people didn't like it. So I opted to fake it... while still depending upon the real tech underneath. HOWEVER, it is just running on a freebie heroku box, so it is probably bound to crash/fall-over soon.

fiatjaf 12y ago

If it "is just a cache" and the data is distributed among every client, where is the data at each time before it is persisted to S3?

marknadal 12y ago
Great question, I'm going to C&P a reply I did previously: 1. In memory in the browser tab's process. 2. If available, in the browser's localstorage or fallback. 3. In the server process's memory. 4. If available, on disk in the server. 5. If in a multi-machine setup, any other connected server that is subscribed to that data set, being in memory (3) or in disk (4) if available. 6. If configured, in a machine log on S3. 7. Persisted to S3, which replicates and shards it for you internally. 8. If configured, in a revision file on S3. 9. If configured, in a multi-region S3 setup, redundantly in many places. (2) is not cleared till an acknowledgment that (7) is confirmed. (1) is not cleared until an acknowledgement that (7) is confirmed or if the tab is exited. In the case of (7) it is no longer the delta/diff, but a snapshot of that current data set with that delta/diff's update. Retries from (1) ~ (5) will happen at various events, if the confirmations are not satisfied. If a conflict has already occurred by (3) the acknowledgement from (5) will include a notification that the value has already been updated, along with the standard delta/diff of that conflicting update being sent down. Meaning (5) does not guarantee that your delta/diff has "won", only that it has been saved or is already outdated. Worst case condition is that (2, 4, 5, 6, 8, 9) are turned off, in which your user's data is as volatile as them preemptively leaving the page (although I suppose you could use an onbeforeunload to warn them) - however this behavior is the current norm for most http post based forms and apps. Actually, pardon me, worst case condition is that everything is offline simultaneously, however this is not really interesting because then users won't even be able to access your app in the first place.

glittershark 12y ago

You guys seriously need to work on your SEO - Googling "gundb" has the page show up with the text "Your browser does not support frames...".

marknadal 12y ago
Oh my goodness #fail. Thank you for spotting this. I'll try to figure out how to fix it (probably by not being cheap by domain masking).

gkya 12y ago

I wanted to read the text on the page, but the styling, with the shadow, or the gloss, or whatever it is, it is giving my astigmatic eyes pain, so I couldn't, I'm sorry.

sanderjd 12y ago
Ha, yeah, I thought my eyes were broken. Turns out it's using the `text-shadow` css property. Much more readable after I turned that off.
marknadal 12y ago
sorry about that. IDK why but it makes it easier on my eyes, maybe I should do a survey (I'm probably just weird) and then fix it.
- evilduck 12y ago
  text-shadow: 0px 0px 7px #DDD; That 3rd number is a 7px blur radius starting from a 0,0 point and #DDD is light grey, blurring between solid black and solid white. I think you're just weird, very few people consider blurry text preferable.
- adambard 12y ago
  I definitely remember complaining about this exact thing a year ago :P. At least you toned down the shadow a bit.
  - marknadal 12y ago
    awwwe you remember me! Happy face! For... being "that guy" that had blurry text. Shoot, sad face. Thanks for sticking around :).
    - adambard 12y ago
      Heh, I remembered the project too, I was just reminded of the blurry text by the blurry text. If you find a high contrast hard on the eyes you could drop it a bit by just making the lettering a lighter grey in leiu of the drop shadow. Just don't overdo it or you'll get people complaining about that.

barakm 12y ago

From the blog: > Because gun is not a database (NoDB), it is a persisted distributed cache. This I believe. > The fatal flaw with databases is that they assume some centralized authority. While this may be the case initially when you are small, it always ceases to be true when you become large enough that concurrency is unavoidable. Partially true. Though that's not necessarily a "fatal flaw", and calling it such is troubling. Yes, concurrency is unavoidable when you become large enough but you also want your data to be, well, consistent and persistent, but then you go on... > No amount of leader election and consensus algorithms can patch this without facing an unjustified amount of complexity. Gun resolves all this by biting the bullet - it solves the hard problems first, not last. Where in the code, pray tell, is it solving these problems? The fact that you also claim to be an AP system (and conflate this with ACID) makes me strongly wonder what your notions on Consistency actually are. "Just a cache" needs some consistency as well, I'll point out, but you may not care as much about stale reads. > It gets data synchronization and conflict resolution right from the beginning, so it never has to rely on vulnerable leader election or consensus locking. From what I'm starting to understand you're, at best, shuffling that off to S3 or "other storage engines" -- you've still got to pay the cost. You can't really claim to do linearizability without, well, actually doing linearizability. So, maybe it's a cache, sure. And you seem to like to work on the developer API, nothing wrong there. But there's nothing new under the sun and I'm really skeptical that hard distributed database problems are solved in one large JS file.

stephanfroede 12y ago
What are "hard distributed database problems"? I came to the conclusion that they do exist, but I have observed a need to manage millions of tiny write transactions per second-> IoT.
- marknadal 12y ago
  I've come to a similar conclusion. The smaller your updates are the better, and allow for cleaner data sync. Check out my other reply.
marknadal 12y ago

stephanfroede 12y ago

Cool approach. I had some fights with Neo4J and taming IO. I did fall back on a 2nd Level Cache, which is nothing else than a huge hash map/KV store in memory.

marknadal 12y ago
Thanks! Interested in joining and working on these types of problems? You seem to have some pretty good skills. Shoot me an email mark@gunDB.io

eridius 12y ago

Why is it called Gun? The name is a little off-putting. What's next, a database called Kill? How about Murder? Genocide? Edit: The fact that I'm being downvoted for voicing a concern about the naming is really disappointing. This is a serious issue, and I would appreciate a response, not being buried.

tlrobinson 12y ago
The fact that you're being downvoted suggests most people strongly disagree that this is a "serious issue".
marknadal 12y ago
I didn't downvote you, so please don't think I'm the one trying to bury you. I'm calling it GUN because it is powerful and therefore a dangerous tool to wield. Because I'm going with a fully decentralized/distributed system, it has also generated some controversy with people. Fact is, centralized/master-slave consensus based databases are incredibly popular right now. Things like Riak, Cassandra's CRDTs are not getting enough traction as they should - but probably because they can be difficult to set up. I'm trying to blow this all out of the water and make distributed database systems easy for developers. So I'm admittedly going for an edgy name. I'm not wanting to kill anybody, just centralized software.
- eridius 12y ago
  Thanks for the response. I didn't think you were the one trying to bury me, but I appreciate the fact that you care. I'm glad to hear that you are aware of the fact that this is a loaded term and that you intentionally chose it because you wanted an edgy name. While I'm still not a fan of it, I feel much better about it knowing the reason behind the naming. And I think you need to put this info somewhere on the site and the GitHub project. I read gunned.io, and I skimmed the README of your GitHub, and nowhere did you even acknowledge that the name was edge, much less indicate that this was an intentional choice. I would urge you to add a FAQ entry on gundb.io, add a wiki page to your GitHub repo, and put a line somewhere in the README (perhaps at the bottom) linking to that wiki page. Otherwise, you're going to end up with more people than just me thinking that you chose a potentially-offensive name as opposed to a deliberately edgy one. Speaking of your GitHub repo, you should also add gundb.io as the webpage for the repo, and probably link to it in the README.

mmagin 12y ago

"With all new flavors like banana, fizzbitch, and GUN!" https://www.youtube.com/watch?v=t-3qncy5Qfk https://www.youtube.com/watch?v=t-3qncy5Qfk

ArekDymalski 12y ago

It looks very promising. However I wonder who is the intended user of Gun: 1. "full-stack" developers who just want to save time and/or benefit from NoDB aspect 2. Beginners and front-end developers who don't anything about databases? In case of group 1 your marketing seems to be insufficiently technical as many people here have already noted. In case of group 2 (which I belong to) things look completely different. As a beginner whose learning efforts are constantly disheartened by tutorials and courses which end at "locally hosted HelloWorld app" phase, I'd be more than happy seeing: 1. step-by-step, layman-friendly tutorial on installing Gun on S3 and other platforms. 2. very well commented example app demonstrating how to create typical functionalities. With such approach you will keep the "Dropbox of databases" promise which sounds very exciting. Actually I think that something like this should be an obligatory feature on Codeacademy or any web development MOOC dedicated to beginners.

marknadal 12y ago
Great questions. 1. As of right now, focusing on beginner/front-end devs who just want an easy open source Firebase like database. People building small experimental apps, since we have finished our battle-testing suite yet. However, I'd also highly encourage full stack developers to get involved and try it out and give us feedback. For small projects it'll probably save you time, but the plugin/modules ecosystem (aka features) aren't mature enough that you'll be writing a lot of your own logic. Which please do! We need them! If you don't want to run GUN on localhost, I'll host a GUN server for you. :) You are right, I need to get better docs/tutorials and information out on this, so laymen don't get disheartened. Is there anything I can do to help? Thanks for your comment!
- ArekDymalski 12y ago
  Thanks Mark, I'll keep an eye on the docs page then. I'll also keep the thumbs up :)

rawnlq 12y ago

Have you heard of sharejs http://sharejs.org/ http://sharejs.org/? It's made by an ex-Google-wave engineer and uses operational transforms for eventual consistency. It seems like you guys are solving similar problems. I mention this because Dropbox has their own "Dropbox for Databases" called Datastore: https://www.dropbox.com/developers/datastore https://www.dropbox.com/developers/datastore which is based on Operational Transforms: https://blogs.dropbox.com/developers/2013/07/how-the-datastore-api-handles-conflicts-part-1-basics-of-offline-conflict-handling/ https://blogs.dropbox.com/developers/2013/07/how-the-datasto...

marknadal 12y ago
Actually yes! I'm one of the people who accidentaly sparked a long discussion in the #1 issues thread: https://github.com/share/ShareJS/issues/1 https://github.com/share/ShareJS/issues/1 that I've seen other people on HN link to. GUN doesn't have OT-style text collaboration yet, so go with ShareJS if that is what you need now. I do plan on implementing it on top of GUN though, or trying to get ShareJS integrated with GUN. Joseph is a really great guy. Yupe, I've talked to Steve Marx at Dropbox Datastore at a hackathon before. He's a great guy as well. They're using algorithms that require some centralized conflict resolution though. Which is great, but I'm interested in the decentralized side.

kainolophobia 12y ago

I've looked at your "Hypothetical Amnesia Machine algorithm" and have a few questions. First though, I'd like you to read this: http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf http://research.microsoft.com/en-us/um/people/lamport/pubs/t...

marknadal 12y ago
Yes, I've looked at this paper before - I should reread it though. I've done a tech talk (not recorded though) on the pros/cons of vector-clocks and timestamps. I have some very specific insights which I should probably write a paper on. Or at least get the tech talk recorded or written down. There are some slides at the bottom of: https://github.com/amark/gun/wiki/How-to-Create-GUN https://github.com/amark/gun/wiki/How-to-Create-GUN . What questions may I answer?

bhz 12y ago

Have you tried redis? http://try.redis.io/ http://try.redis.io/

marknadal 12y ago
I love redis! My first proof of concept of GUN used redis as the persistence/storage layer. But I moved off of it since I wanted a fully embedded solution. Data wise the difference is that Redis doesn't support graphs. But you could easily build that on top of Redis, so you could argue GUN is just graph data ontop of Redis (well, not anymore) with a conflict resolution algorithm baked in.
- bhz 12y ago
  I'll have to give Gun a go when I have the chance. Thank you for providing the contrast.

nolanl 12y ago

Interesting project! It seems to share a lot of the goals and design choices of PouchDB/CouchDB: distributed, offline-first, eventually consistent, deterministic conflict resolution, etc. One big difference I can see is that it's only using LocalStorage, which has good cross-browser support, but only allows 5-10MB maximum. Are there plans to add IndexedDB/WebSQL support so that users can store more data?

marknadal 12y ago
Yes! Thanks. LocalStorage implementation is just the default plugin, and I chose it first because of its compatibility. I'd like to get IndexedDB support in there as well. Interested in helping?

karlgrz 12y ago

I would really love if this actually worked as promised. Way too much skepticism and not nearly enough proof. Kudos for actually putting this out there, though. It'd be great to prove everyone wrong, but I will not hold my breath. Good luck!

marknadal 12y ago
You can try messing with it yourself by, doing (if you already have node/npm/git installed and familiar with terminal): git clone http://github.com/amark/gun cd gun/examples && npm install node express.js 8080 Then open it in a couple of browser tabs on different devices, change their system clock, try refreshing data, crashing things. etc. I'm also trying to figure out how to write simulated tests (like Jepsen) that will do all of this for you and give you the results of what failed/succeeded. Till then, let me know if you see anything break.
- karlgrz 12y ago
  I'm not going to spin this up on 1000 nodes to make sure it handles the kind of load needed to simulate actual production traffic (which is what you would need to actually figure out if this would hold up to some kind of large scale load that Riak or Cassandra would be able to handle). Maybe you should do that yourself and document it to prove how good your product is!
  - marknadal 12y ago
    You don't need to spin up a 1,000 nodes. You can just spin up a 1,000 tabs. Since they all run the same algorithm! Yes, I am working on more tests to prove myself wrong or right. Please bare with me as I/we make progress, because it is literally only a few contributors and me. This is v0.1.0 for a reason, not v1. Lots ahead, but please play with it while we work on developing the test suite.
    - karlgrz 12y ago
      I appreciate the suggestion and response. Understand it is v.0.1.0 but you should also understand that when you bring something like this out with next to no academic backing behind your theories and algorithms there is DEFINITELY going to be skepticism and doubt. You are exactly right, though. It's early, and I'll give you the benefit of the doubt that you will achieve what you want. Also know that there is a TON of research in these areas (which you clearly are aware of based on your comments in this thread) that basically refutes a lot of what you are claiming. I would love to see more clear documentation along with actual proofs showing how your algorithm is sound. Until then, good luck, and I look forward to hearing about your success!

danbruc 12y ago

There is no way this can work. Merging data changes can inherently not be automated in the general case. Deciding if a change from foo to bar should win over a change from foo to baz depends on the semantics of those strings. There are some cases, for example counters, with simple and clear semantics where you can build reusable and robust solutions for. You can also handle the general case with simple policies like last write wins. But there is no way any algorithm will ever be able to figure out whether to choose bar or baz, not at last because I could arbitrarily declare any of the two outcomes correct.

marknadal 12y ago
Every change can be preserved in a history/append-only/log/stream. So you don't have to "lose" data from another "winning". However, the algorithm will by default select one, you can then code it at the app level for the user to select a new winner. The general case here is very UUID based key/value pairs. Anything beyond that, you should be using CRDTs and OT like algorithms, which I will be building on top of GUN. However, in the meanwhile, I challenge you to try running the example folder from the GitHub ReadMe and seeing if you can break the automated sync and cause data divergence! Edit: This person (in the comments below, please upvote him), and my reply, best addresses the most important questions: https://news.ycombinator.com/item?id=9077969 https://news.ycombinator.com/item?id=9077969

curiously 12y ago

this seems like a great tool. hosting firebase on my own is what I want to build real time apps, is this possible? I have the same concerns for meteor which I have for this as well, which is security and scalability. How does Gun address those two things?

marknadal 12y ago
Great questions. Hosting on your own: Yes. Security: Currently a "Roll Your Own" approach, where you wrap GUN behind some firewall/throttling like system. Why? Because permissions are so app-specific behavior, I haven't figured out how to generalize it. I don't think it is possible to do it, so in the future we'll probably provide various security plugins that come with app specific assumptions. Scalability: Run the example folder in the GitHub Readme, and open up hundreds of tabs. Gun is running individually in all of them. See how it handles that. I'm trying to have a production-grade battle-testing suite developed soon, such that you could just run a script, it would ask you how much you want to spend on the test, and then it would deploy a ton of GUN peers to the cloud and generate a ton of traffic and load. This is not available yet, but something I'm focusing on within the next 6months or year. Anything I can help with?

tomphoolery 12y ago

> 400 Bad Request https://github.com/amark/gun https://github.com/amark/gun

marknadal 12y ago
oh snap, the HN "DDOS" has peaked! I'll see what I can do to get things back online. Thanks for putting the github link in here in case others get the same issue.

bitanarch 12y ago

A few questions. 1. How do you define the operating boundaries for your time stamps? What is too low and too high and why? 2. What are the expected use cases for your conflict resolution algorithm? The HAM function you proposed would just overwrite one string with another and so for things like collaborative document editing, user intention isn't preserved. 3. Where is the vector clock defined in your code? I can only see Gun.time.is() in a brief glance at your code... and it is just getting the UNIX timestamp in milliseconds.

marknadal 12y ago
Wonderful questions! Actually some of the best in the entire thread I think. 1. See (3) but first read: A) The upper boundary is defined by the current machine's local clock, which could have skew or drift. B) The lower boundary is defined by the last known update on an individual record (down to the UUID+field). 2. The expected use case is for this conflict resolution algorithm is for basic field/value pairs (terms defined here: https://github.com/amark/gun/wiki/semantics https://github.com/amark/gun/wiki/semantics, and here: https://github.com/amark/gun/wiki/JSON-Data-Format https://github.com/amark/gun/wiki/JSON-Data-Format) within a UUID an object (called a node, as in a node in a graph). This is what HAM works off and is considered the lowest level atomic pieces (the value). In order to sync on collaborative text you need to build an OT layer on top of this (I plan on doing this, possibly integrating with ShareJS as another mentioned). You cannot collaboratively sync on atomic values by themselves, you must define a CRDT for that - plugins/modules for them will be coming later. 3. Vector Clocks. HAM does not assume what the sort key is for state, it just assumes it is a value it can do <, <=, ===, =>, > comparisons on. A) Vector clocks have a vulnerability that if you are working with temporary/ephemeral machines, the clocks will constantly get reset and have to play "catch up". However, network partitions are highly likely, so there is no guarantee that two machines won't issue a conflicting vector clock. If this happens, there is no standard way of dealing with this, although there are plenty of work arounds. B) Timestamps also have a vulnerability, that is if you set your local clock ahead (say 2 years in the future) then it will "always win" wiping out other peers valid values. However you unfortunately cannot determine in an untrusted network whether a peer is being malicious about being 2 years in the future, or if they are actually at a different point in timespace - like a GPS satellite or on Mars, or went offline in the subway. C) As a result, this is why I combine them together via the boundary function. The upper and lower boundaries of the state machine provide the relative "vector" for the untrusted timestamp in the delta update. The benefits of this technique are two fold: 1) You get deterministic and idempotent resolution within a special-relativity timeframe in a decentralized system without gossip (consensus). 2) If you do run GUN within your own trusted network, you can use the timestamps to calculate drift between machines and then readjust the boundary function of the state machine. Thus giving you a highly accurate "objective" view of your data across peers, which if the latency is low enough could indicate it is worth creating locks (but thus sacrificing Availability). Hope this was clear enough! Any questions? I'm going to be reposting this in the rest of the thread.

trithagoras 12y ago

...Is there a glow effect around all the text?

sigmonsays 12y ago

This is the best troll ever

dang 12y ago

A few disagreements in this thread have crossed over into being disrespectful. This is a gentle reminder that you can (and on Hacker News, please do) disagree without calling names. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html

nathan7 12y ago

Awesome to finally see Gun on here, Mark! What still worries me is the reliance on external storage services, although a good local storage service could be built for Gun. Other than that, I'm glad to finally see docs!