OrbitDB Community Call: September 18th

[RichardLitt]

• Click here for the agenda and notes

This will be the next Orbit community call, at 1300UTC on September 4th. Drop your agenda items here or in the notes.

Join from PC, Mac, Linux, iOS or Android: https://zoom.us/j/784309963

Or iPhone one-tap : US: +19294362866,,784309963# or +16699006833,,784309963# Or Telephone: Dial(for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 669 900 6833 Meeting ID: 784 309 963 International numbers available: https://zoom.us/u/evzwWgnAi

[RichardLitt]

OrbitDB Community Call September 18

• Moderator: @shamb0t
• Notetaker: @RichardLitt
• Attendees:
  • @RichardLItt
  • @shamb0t
  • @haadcode
  • @claus
  • Randall
  • Joel @oed

Agenda

• orbitdb org access hygiene: clean up access rights (@haadcode)
  • @RichardLitt: I've contacted them. I'll just remove them now and follow up. (Done.)
• new project announcements: origin, uport (@haadcode)
  • https://medium.com/originprotocol/introducing-origin-messaging-decentralized-secure-and-auditable-13c16fe0f13e
    • 1-to-1 Chat encryption, which is pretty cool.
  • https://medium.com/uport/announcing-3box-and-ethereum-profiles-dba9841e0952
    • @haadcode and @RichardLitt knows these guys, pretty cool. Would love to support them.
    • @joel is here from uPort
    • uPort: One of the problems we're trying to solve is identity on-chain, part. in the Ethereum community. uPort's approach is that this is taking too long.
    • We want to have rich user profiles. We've made a way to associate an orbitDB database with an eth key, to store a public profile and private data.
    • That's the basic introduction to what that is.
    • @haadcode: I took a look at 3box, and I have some ideas. Maybe we can do that on Gitter. I'm not sure where you are, at the moment - demo? Prod? I'd like to give some ideas for the datastore itself for how it can be improved and simplified even further. It sounds to me like there are more questions around identity than db usage.
    • @joel: Yah, from our last chat - our approach of replicating data in the database is probably backwards, so we'll switch to how you described it yesterday most likely. A bit of a rearch, but not too bad. The identity stuff - that shouldn't be too hard. That can be changed in the future.
    • @haad: Yeah, I see it the same way. Referring to the discussion yesterday - the data database and how it connects to orbitdb. That's something we can work on later on. The general arch may be more of a priority for you to figure out first.
    • @joel: The idea that we have now is to have one main kv database, with the names of new databases and their addresses. So you can create private keyvalue stories - multiple stores, one main tracker db.
    • @haad: Yeah. Instead of the server being a dedicated service, it's more about keeping a db and pinning it. Wish someone from colony was here to today - they're working on something that solves this particular problem. Hopefully they'll open source this!
    • Is this a problem in orbitdb? Haad: No. It's a general peer problem. Writing something locally doesn't mean it will get to the network, so there needs to be a way that someone in the network has data at any time. In the IPFS community, this was solved by pinning, which was a server that just replicated the content of a hash. This same idea needs to happen for Orbitdb.
• discuss approach for linting (eslint) (@haadcode)
  • the initial solution has some drawbacks, discuss possible alternatives to balance between modules and dependencies
  • Haad: Wish Thiago was here for this! This is mainly about the linting. How do we include the linting rules files, so no one needs to do anything extra?
  • @haad: I wanted to discuss a different way of doing that.
  • @haad: basically, you use another module to require everything. I've been working on it.
  • See https://github.com/orbitdb/ipfs-log/pull/130, and https://github.com/orbitdb/orbit-db-identity-provider/pull/9, https://github.com/orbitdb/eslint-config-orbitdb/pull/6
• status of go-ipfs support (@haadcode)
  • Something is coming in the next release of IPFS. We know what the problem is, and they need to get the fix in and verifying it, and once we have that, we can finally say "Supporting go-ipfs again" officially.
• Timezones; This is brutal for the west coast.
  • Let's keep in mind that Randall is awesome for waking up at 6.
  • One thing we can do is switch this up every other thing.
• @oed: When you add something to your db, does it get pinned in your local node, or is there an option for doing that?
  • @haadcode: no. It doesn't automatically get pinned. We should find a way to do this. It would be fairly expensive to pin every entry.
  • @haad: The longer story is that pinning still isn't implemented in js-ipfs. This is not true on go-ipfs. Some disparity. Wouldn't be hard to add, though, let's definitely do that.
  • @randall: Would that be through an API call to the ipfs daemon?
  • @haad: Yeah. One would call ipfs.pin(hash) or something. From the javascript vs go-ipfs side, it doesn't make a difference, as they're mostly isomorphic.
  • @oed: In go-ipfs, when you add a file you can add a flag to pin it also: ipfs add --pin.
• @randall: Can you let us know where we're going in the next six weeks?
  • @haad: Effectively, orbitdb is a completely decentralized database, but it's not a blockchain. It's a building block. You can use it to build other thigns, you can use it as an application backend. The main uses cases seem to be crypto-native, or native p2p projects. Projects which are building software for the decentralized web. So uPort is not a centralized identities service, but they're doing it decentralized. What we don't see a lot is etablished companies (enterprise, bigger, web-force internet software tech companies) using it, for obvious reasons for now. Summing up, it's more the projects that really want to build a decentralized internet for an all-encompasing umbrella term for that. It seems to be working relatively well for those who are using it. We always try to find the generalized solutions for many projects and many ways of using it. Identity seems to be a general eample, where we try to find the solution for those using it. @randall: so multiple identity providers? @haad: Yeah, basically. We currently have a JS implementation in the browsers, and node.js (backend), which is kind of the main use case. You pull in the db locally instead of asking the servers for more. There have been a few requests for a native impl - go or rust or something. We haven't started that yet. Not sure when we would be working on that. At some point. Effectively, today, it's usable. It may not works for all use cases, but most of them seem to be catered by what features are there currently. As for the long term where it is going, we set up Haja Networks specifically to take it further from where it is today. What we're working on is generalizing the db protocol out of orbitdb, into something that can be considered a protocol in itself. This is what we're working on at Haja, which we haven't published yet, but we will be as soon as possible. The general protocol will be what is in orbitdb now, but with some changes. Given the needs of the community, we may do it as orbitdb, but it's not sure. @randall: does this also include efficiency so that the main conenctions don't need to be replayed by a client? @haad: yes. All sorts of snapshotting, quicker ways of bootstrapping when a fresh client joins, and so on. All of these things are part of that.
  • @randall: is it important to keep blockchain out?
    • @haad: Yeah, in short, it shouldn't be tied to the blockchain per se. The whole blockchain discussion is a different topic. At core, orbitdb is consistent. We see this as a better primitive to build stronger dbs on top of that. There needs to be a way to hook up into a better consensus alg, so that we can have better guarantees of consistency from the db perspective. We want to make sure that orbitdb doesn't need a specific blockchain, but a way that the users can hook into the consistency or consensus algorithms - for isntance, the eth blockchain, or a dApp-based blockchain. We need to enable both of those. This would be something cool to work on if anyone is interested! In short: No blockchain in the core of orbitdb, but blockchain hookin when needed. For instance, the access controller. You want to know the latest state. Instead of making consistency a priority, which is non-trivial, use a blockchain to store this (notetaker: I think?). You want to allow anchoring to different chains.
  • @randall: Curious what usecases may be coming out of filecoin that you might be responsible for.
  • @haad: That's hard to say, there's not much on filecoin. Filecoin would be a solution for pinning issues onchain, probably. Hard to say. It should be 1-to-1 mapping for ipfs, which means as long as this matches, then orbitdb should work out of the box. I was talking with @whyrusleeping this week, and according to him, the filecoin wallets should be usable soon like this. @randall: Would this be p2p consensus with raft? @haad: I don't know the consensus algortihm, but I don't think it's raft, but proof-of-spacetime.
  • @randall: Some of these things could change, based on how people think.
  • @haadcode: Yeah. We're not the best at telling this to people. If someone could write this up, that'd be great.
  • @Richardlitt: I tried.
  • @randall: I have more questions, but later is good.
• @shams: Thanks all!