Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OrbitDB: Peer-to-peer databases for the decentralized web

github.com

Post reply on HN
Print view View original

81–90 of 119 posts

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#81

Post by haadcode »

jayd16 wrote: post #80

Pretty neat if you think about the technology as a smarter cache. One could easily see certain applications, such as blog networks or Twitter alternatives. Security is easy in some cases. Sign your log appends. Security around transactions without a central authority is pretty complex. Whats the solution there? Block-chain type things? It would have to be application specific I suppose. I never gave FirebaseDB a shot…

Great comments! Indeed, "sign your log appends" gives everything needed for authority. Re. transactions, from OrbitDB's perspective this would be application specific, so you could hook into traditional, centralized consensus or use a blockchain or other types of decentralized consensus mechanisms. Or, given the core data structure is a log, build a "custom database" on OrbitDB that models and provides an interface for a consensus algorithm, eg. "append 1: head is X" <- "append 2: ack head is X" <- "append 3: ack from me too that head is X" etc.

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#82

Post by haadcode »

haadcode wrote: post #71
olah_1 wrote: post #25

Earlier quoted context omitted.

Gun is a graph database. I don't think Orbit uses a graph system, but instead uses feeds or KV stores. So that's a another difference. But Gun can use IPFS as a storage adapter if you wanted.

To clarify here, OrbitDB's core is an append-only, immutable log CRDT. While a mouthful, what is gives, is a distributed (decentralized) database operations log. Almost any type of database, or data structure, can be then built on top of that log. The log in OrbitDB is a Merkle-DAG [1], so, a graph. Key-Value databases, feeds, and other data model types that OrbitDB supports by default, are all built on that log. You…

The log described above is this https://github.com/orbitdb/ipfs-log

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#84

Post by pw6hv »

xsdklfsdfklj wrote: post #32
vuldin wrote: post #19

OrbitDB is one of the key dependencies in 3box, an awesome tool for building decentralized apps where the user controls their own data. https://3box.io/

that link doesn't load if I block google ad requests.

How do you block these requests? Just asking as I have pihole blocking google ads but I have no issue accessing the website.

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#86

Post by doublerabbit »

pw6hv wrote: post #84
xsdklfsdfklj wrote: post #32

Earlier quoted context omitted.

that link doesn't load if I block google ad requests.

How do you block these requests? Just asking as I have pihole blocking google ads but I have no issue accessing the website.

I use uMatrix, however the whole site fails to load in Palemoon.

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#87

Post by aboodman »

markhenderson wrote: post #41
LoSboccacc wrote: post #21

last time I tested it needed to fetch the whole db to do even the most basic reads, so even simple but long running applications had a very long, network intensive initialization time. is that still the case?

OrbitDB works with a CRDT stored in IPFS. In order to calculate the state of the database, it does need to reduce the CRDT oplog which requires fetching all the entries. This was indeed very time consuming, particularly for remote requests, since we used a "nexts" list of addresses to load. HOWEVER! Our latest release, 0.23.0, mitigated this by using a power-of-2 skiplist to load things in parallel, which gave us a n…

Does this mean that in order to initialize the database, the entire version history must be synced and reduced, to get the current values?

(Is there a design doc for OrbitDB anywhere?)

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#88

Post by sagichmal »

haadcode wrote: post #76
markhenderson wrote: post #70

Earlier quoted context omitted.

Can you elaborate?

> 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 those root nodes. Do I have it right so far?

Assuming yes, let's say you have causality chain like so:

    1 --> 2 --> 3 --> 4 
           `--> 5 --> 6
Two root nodes, 4 and 6. Two concurrent histories, 3-4 and 5-6. 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. Last Writer Wins, right? So either 4 or 6 dominates the other. Whoever was in the other causal history just... lost their writes?

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#89

Post by amelius »

ekseda wrote: post #27
evv wrote: post #17

Earlier quoted context omitted.

Can you elaborate? Source code to GUN is right here: https://github.com/amark/gun/tree/master/src

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.

Indeed, the source looks like the output of a transpiler.

Re: OrbitDB: Peer-to-peer databases for the decentralized web

#90

Post by brabel »

haadcode wrote: post #67
budabudimir wrote: post #59

A database implemented in JS; very encouraging. I guess performance and robustness were not a priority.

> I guess performance and robustness were not a priority. You'd be surprised how well JS does on both fronts, in addition to being able to run across platforms :)

Performance-wise, JS is not too bad when you have lots of IO going on, as in this case... but robustness? You gotta be kidding! JS is the poster child of a language does NOT have robustness as one of its attributes. Just about every single one of its design decisions makes robustness difficult.
Post reply on HN