Live data from Hacker News

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

github.com

41–50 of 119 posts

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

#41

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 nice 4-5x boost there.

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

#42
post #27

Earlier 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.…

> without the need to obfuscate under the excuse of performance

> load two hundred build dependencies and then write twenty word long variables [...] a very bad position as you would have to 'minify' (i.e. obfuscate) to not have a 70mb production file

You defeated your own argument here. You're saying it's nice that the code is obfuscated already (short variables) so you can get better performance, it's really the same thing - except doing it by hand has a lot of downsides.

Minifiers and source maps have been around for a long time to get you the best of both worlds, understandable code in development, minified code in production (even though gzip alone gives you 80-90% of the gains). There is absolutely no reason to write obfucasted code like this [1] where you need to guess the meaning of thirty different one-letter variables. Grep'ing the code becomes impossible. This has nothing to do with 'old school' JS, but universal code standards.

[1] https://github.com/amark/gun/blob/master/src/type.js

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

#43
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/

I'm one of the maintainers of 3Box! Let me know if you have any questions. You can learn more at: Web: http://3box.io Github: https://github.com/3box Discord chat: https://discord.gg/669BQHv

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

#44
post #31

Did any of the demos work for anyone? HN hug of death?

Yeah, sorry about that :( There's this though: https://github.com/haadcode/orbit-db-control-center

(which also seems to be putting https://ipfs.io under strain. Sorry, ipfs.io!

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

#45

Hey 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.

Hello! Thanks for maintaining an open source project. I am excited to see IPFS take off.

Some basic questions, as I am still struggling to see the use case of this project.

* How did this project get started? What problem is it trying to solve?

* Are there any real world examples of where this project is used?

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

#46
post #45

Hey 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.

Hello! Thanks for maintaining an open source project. I am excited to see IPFS take off. Some basic questions, as I am still struggling to see the use case of this project. * How did this project get started? What problem is it trying to solve? * Are there any real world examples of where this project is used?

tl;dr: You use this any time you want to have mutable data shared across a peer-to-peer network.

I wasn't there at the beginning but I believe the project came out of trying to achieve said mutable state within IPFS (which, for other readers is content-addressed and therefore append-only)

http://orbitdb.org lists all of our current users, the biggest one is Metamask by way of https://3box.io. https://tallylab.com is building with it for remote encrypted backup and shared tallies. https://github.com/dappkit/aviondb is a MongoDB-like interface for it.

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

#48

javascript? No thanks.

Could you please stop posting unsubstantive comments to Hacker News? You've been doing it repeatedly, and we ban that sort of account because we're trying for something a bit better than that here.

https://news.ycombinator.com/newsguidelines.html

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

#49

Hey 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.

I want to build a reddit like community using orbitdb. But orbitdb can't freely add and remove user permissions. When will this feature be implemented?

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

#50
post #3

eventually consistent database Is an oxymoron

When you get down to it, between cache coherency across CPUs and memory, disk flush delays and disk caches, every database is eventually consistent. And if you want to operate over a distributed network, which means you WILL have network partitions, then you are subject to CAP and will need eventual consistency mechanisms.

> When you get down to it, between cache coherency across CPUs and memory, disk flush delays and disk caches, every database is eventually consistent.

This is a false. None of the things you listed preclude consistency.

> And if you want to operate over a distributed network, which means you WILL have network partitions, then you are subject to CAP and will need eventual consistency mechanisms.

That's not how CAP works. Plenty of distributed CP databases exist.

Post reply on HN