# 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)?
- https://github.com/orbitdb/ipfs-log/pull/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 https://github.com/orbitdb/orbit-db/issues/220
- @rjharmon: doc fixes for onboarding errors https://github.com/orbitdb/orbit-db-docstore/issues/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: https://github.com/orbitdb/orbit-db/issues/437
- @RichardLitt: Logo update
- @RichardLitt: PR about process for making these community notes, feedback would be good https://github.com/orbitdb/welcome/pull/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.