Orbit community call

date: Tue 21st of August, 2018
notetaker: @RichardLitt
moderator: @shamb0t

Participants

• Richard (@RichardLitt)
• Shams (@shamb0t)
• Huy (@huyhoangCSUH)
• Tim (@coyotespike)

Agenda

• Haad and Thiago are feeling under the weather, we think, so just us today.

• @RichardLitt: Update on acl work (@thiago, @shamb0t)?

  • orbitdb-archive/ipfs-log#145
  • @haadcode and @shamb0t will be working on this this week. Closed one PR, opened up a new one.
  • Still working on it. The actual ACL may just be a wrapper, instead of having the fxs implemented in a module.
  • A concrete implementation without allowing a random function to be passed in.
  • Also some little superficial changes.

• @RichardLitt: Update on indexing request orbitdb/orbitdb#220

• @rjharmon: doc fixes for onboarding errors orbitdb-archive/orbit-db-docstore#10

  • Shamb0t will be working on this starting on Monday

• Questions (Huy@colony: https://github.com/huyhoangCSUH):

  • What is the Index in the store?
    • Either you have to know them in advance (the only way currently.) There's an issue on general indexing, which may refer to the same thing.
    • The docstore references the same kind of issues. If I open a DB, and I want ot index on title or location, then I need to open an array.
    • You have to know the fields a priori; the manifest might be a good place to put this.
    • What if we indexed it not by the names of the fields, but a field in the manifest on the app level that might help? @shamb0t
      • Imagine we have some info we need, shared among those db notes, such as indexing (on various fields; title, id, etc.)
      • Currently, there is no way to know from the db itself which field has been indexed. If you have implemented the db yourself, this is not a problem. How could we know which field has been indexed before opening the Db?
      • A self-describing index. Tim thinks it is a great idea.
      • @shamb0t: should we keep it as index or indices, or a field like meta, which should be known before at the app level?
      • Anything other than indices that you would need?
      • Tim: I can't think of anything, but I think of the meta field as insurance, or future proofing - it lets us add extra properties besides the index type in the future.
  • Is the index of docstore stored in the _index field of the store object? It looks like the manifest doesn't store indexed field.
    • The store index and the search index are different. The store index is built as each store fast-forwards over the CRDT log. Shams may store this index as a key-value store and put the address in the manifest of each store, so that each node does not have to build the index from scratch.
  • How does the current index in docstore work? Is it stored in memory when the database is loaded?
    • Yes, basically everything is built in memory.
  • More explanation on mapper in query() of docstore. Does it help retrieving only certain fields? As of now, it seems the query() function returns all fields in the objects. Should we use mongoDB style?
    • Huy will open an issue proposing higher-level queries to implement.
  • Discussion on generalizing indexing: orbitdb/orbitdb#437

• @RichardLitt: Logo update

• @RichardLitt: PR about process for making these community notes, feedback would be good #18

• Gitter channel! https://gitter.im/orbitdb/welcome

• Privacy?

  • Right now, it's all public. We're looking at Read only access, but that's far off. For now, encrypt before throwing stuff in.
  • We are looking into proxy-read encryption, and write access is the ACL stuff. But still big, not auditing, and more work to do.

from welcome.