Did any of the demos work for anyone? HN hug of death?
Shouldn't a distributed, non-centralized DB handle HN hugs without a hiccup?
OrbitDB: Peer-to-peer databases for the decentralized web
91–100 of 119 posts
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#92Earlier quoted context omitted.
> How does OrbitDB compare to GUN? I went to a meetup where the creator of GUN gave a presentation. To this day, it was the single strangest presentation I've ever experienced. The presentation had numerous obvious errors. The audience kept pointing out major misunderstandings and errors about distributed systems. I remember one awkward moment where someone pointed out a glaring error in the author's model of conflic…
I wasn't at this specific presentation, but I've seen other presentations by the author, and had basically the same takeaway. Snake oil.
What are the alternatives for offline-first databases? I have a project in the back of my head where clients to a simple central database would be frequently offline and I had GUN in my notes for doing that.
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#93Earlier quoted context omitted.
> Last-Writer-Wins is a conflict resolution strategy that can be used by any kind of data type that needs conflicts resolved, CRDTs included. Unfortunately it's not a very good one: even if you use vector clocks instead of wall clocks, it doesn't give you much stronger guarantees than determinism. That is, given two concurrent writes, the winner is essentially arbitrary. LWW is a merge strategy of last resort; if tha…
OK, I've read the paper; can you help me reason through a scenario? As I understand it, the Merkle-CRDT represents a Merkle tree as a grow-only set of 3-tuples. When you add a new event to the thing (as a tuple) you have to reference all of the current concurrent root nodes of the data structure, in effect becoming the new single root node; and your event data, which must be a CRDT, gets merged with the CRDTs of thos…
almost! :) let me elaborate on few points.
> you have to reference all of the current concurrent root nodes of the data structure, in effect becoming the new single root node
correct, and more precisely the union of heads is the current "single root node". in practise, and this is where the merge strategy comes in, the "latest value" is the value of the event that is "last" (as per LWW sorting).
> and your event data, which must be a CRDT, gets merged with the CRDTs of those root nodes.
the event data itself doesn't have to be a CRDT, can be any data structure. the "root nodes" (meaning the heads of the log) don't get merged with the "event data" (assuming you mean the database/model layer on top of the log), the merge strategy of the log picks the "last/latest event data" to be the latest value of your data structure.
> It's time to write a new value, so I create a new tuple with references to 4 and 6, and merge their CRDT values.
when a new value is written, correct that the references to 4 and 6 are stored, but the new value doesn't merge the values of the previous events and rather, it's a new value of its own. it may replace the value from one or both of the previous events, but that depends on the data model (layer up from the log).
1 --> 2 --> 3 --> 4
`--> 5 --> 6
no writes are lost. the result in your example depends what 4 and 6 refer to. in a log database, the ordered log would be eg. 1<-2<-3<-5<-4<-6, so all values are preserved. in the case of a key-value store, it could be that 4 is a set operation to key a and 6 is a set operation to key b, thus the writes don't effect each other. if 4 and 6 are both a set operation on key a, it would mean that key a would have the value from 6 and the next write to key a would overwrite the value in a. makes sense?
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#94Earlier quoted context omitted.
Yes sorry for not doing this. In the source code folder, please open any random file and try to understand what the code does. I once tried to fix a bug that I found in GUN but I gave up after just trying to figure out what the code is supposed to do.
That is very readable javascript. old school javascript like this have an advantage: you can ship as is, without the need to obfuscate under the excuse of performance. if you load two hundred build dependencies and then write twenty word long variables, it might look nice for you at development, but a user trying to debug or validate code on the fly would be in a very bad position as you would have to 'minify' (i.e.…
No this is not readable. You can write readable old school javascript, but just try to tell me what this line does: https://github.com/amark/gun/blob/master/src/type.js#L111
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#95Earlier quoted context omitted.
OK, I've read the paper; can you help me reason through a scenario? As I understand it, the Merkle-CRDT represents a Merkle tree as a grow-only set of 3-tuples. When you add a new event to the thing (as a tuple) you have to reference all of the current concurrent root nodes of the data structure, in effect becoming the new single root node; and your event data, which must be a CRDT, gets merged with the CRDTs of thos…
almost! :) let me elaborate on few points. > you have to reference all of the current concurrent root nodes of the data structure, in effect becoming the new single root node correct, and more precisely the union of heads is the current "single root node". in practise, and this is where the merge strategy comes in, the "latest value" is the value of the event that is "last" (as per LWW sorting). > and your event data…
> in a log database, the ordered log would be eg. 1How do you know that? It's not inferrable from the DAG. Is sequencing also provided "a layer up"?
> if 4 and 6 are both a set operation on key a, it would mean that key a would have the value from 6 and the next write to key a would overwrite the value in a.
Yes, I mean for all of my events to be reads and writes of the same key. And you've proven my point, I think: if the resolution of this causal tree is Last-Writer-Wins, 6-domiantes-4, and "key a [gets] the value from 6", then whichever poor user was operating on the 3-4 causal branch has lost their writes.
This is a problem! If you claim to be a CRDT and offline-first or whatever, then as a user, I expect that the operations I make while I'm disconnected aren't just going to be destroyed when I reconnect, because someone else happened to be using a computer with a lexicographically superior hostname (or however you derive your vector clocks).
And if you want to say something like, well, when the unlucky user reconnects and sees that their work has been overwritten, they can just look in the causal history, extract their edits, and re-apply them to the new root -- there's no reason for any of this complex machinery! You don't need CRDTs to just replicate a log of all operations. Of course, you also can't do any meaningful work with such a data structure as a foundation, because it immediately becomes unusably large.
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#96Hey folks! I'm https://twitter.com/aphelionz . One of the maintainers of OrbitDB. Happy to answer any questions you might have. I'll also be in the thread answering folks as well.
What happen if someone posts illegal content?
Also, what happens if someone posts content that is legal in one country, but illegal in another? Can end users filter the content they host to content within their own country?
Examples: content about Tiananmen Square 1989.
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#97Re: OrbitDB: Peer-to-peer databases for the decentralized web
#98Earlier quoted context omitted.
almost! :) let me elaborate on few points. > you have to reference all of the current concurrent root nodes of the data structure, in effect becoming the new single root node correct, and more precisely the union of heads is the current "single root node". in practise, and this is where the merge strategy comes in, the "latest value" is the value of the event that is "last" (as per LWW sorting). > and your event data…
> in a log database, the ordered log would be eg. 1 How do you know that? It's not inferrable from the DAG. Is sequencing also provided "a layer up"? > if 4 and 6 are both a set operation on key a, it would mean that key a would have the value from 6 and the next write to key a would overwrite the value in a. Yes, I mean for all of my events to be reads and writes of the same key. And you've proven my point, I think:…
It's inferable from the fact that the writer saw both chains and produced a new node that merges these heads. So that writer "resolves" the conflict - according to whatever strategy it is programmed to use. (It might be as simple as just storing a JSON that says {"conflict": true, "values": [4, 6]} , and the user will have to pick.)
If it's possible to model operations in a commutative way (eg. instead of assigning values to keys one just stores differences), then the conflict resolution is mathematically proven, just apply all operations in whatever order, they're commutative, great. Of course it doesn't help with "real world data", but that's where mathematically we can use and oracle (the user, or whatever linearizer service we choose).
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#99Hey folks! I'm https://twitter.com/aphelionz . One of the maintainers of OrbitDB. Happy to answer any questions you might have. I'll also be in the thread answering folks as well.
What happen if someone posts illegal content?
Authors can always remove/delete their own posts from a thread, and threads also have a set of moderators. This needs to be set in the thread configuration.
More advanced moderation tools can be built on top, too.
Re: OrbitDB: Peer-to-peer databases for the decentralized web
#100Earlier quoted context omitted.
What happen if someone posts illegal content?
Also, what happens if someone posts content that is legal in one country, but illegal in another? Can end users filter the content they host to content within their own country? Examples: content about Tiananmen Square 1989.
OrbitDB are p2p database instances on top of IPFS, and front-ends or users can always filter the content they display.