Maybe our tooling already has this, but config option and/or env var to setting logging level and turn off req logging for running tests for example.

Log origin, maybe path for each request, with will then be used to produce metrics in cloudwatch

Needs some basic format

Create readme of stand form. Intro, usage, API Docs, build/run/dev, contributions.

Continue to hit cache for 3box profile (and write to cache once resolve).

When we resolve a ceramic profile dont write it to cache following the request, and delete 3box profile from cache. Currently the cache is keyed by orbit db address.

Actually believe this is not needed now. Caching at different level than i remembered (orbitdbaddress). But keeping story to just double check and make sure that current logic will still make sense. Should still be part of test ideally.

Currently readDB has differing configs to load/read if db is a thread db. But it just checks if db address includes threads. This breaks if someone included threads in space name.

Generally we need to be more careful with user inputs and better define name constraints and assumptions.

Will need #30 to support new orbitcaches, probably will just consume orbitcaches which also support many level down stores.

Probably not worth implementing for req cache, but worth considering

Depending on path forward this work maybe more in the pinning node. Right now cache is invalidated when there is any write to the orbitcache (heads for db), orbit writes this every time on db open, even if they are the same. We should only invalidate cache if they change.

If implemented similar to now, a set if not equal function in orbitcache wrapper may work. But since not an atomic operation (not available from redis) may cause other concurrency issues. Can ask/ref mike and his recent story for more info on possible issues with multi read/write to orbitcache, may help here.

Improve param arg validation and throw args based on missing params (or validation) to provide more descriptive errors to api users.

orbit-db-cache-redis interface changed with orbit upgrade, using old version now in api node, can continue to use this version but should update at some point

Current implement is nice that is doesn't require any cache invalidation on the pinning node, just a redis event stream. But right now caches values are being invalidated more frequently than necessary, caches values are invalidated on remoteHeads writes. But orbitdb will write to remoteHeads on every open, not just when they change. An improved strategy would only invalidate cache when a log changes (as intended). One implementation is to only write when value changes, but this is not an op in redis, only can be a client implementation. This is the simplest, but could cause some race conditions as this isnt an atomic op. (but maybe no additional than the unlikely cases that can exist now). Similarly may work to not write heads on log load but on receiving an update instead (maybe improve other race conditions as well)

could be also more general to ask for cids, but will probably keep limited to resolve docs for dids

env var CERAMIC_API for ceramic client, on develop branch will be set to https://ceramic-dev.3boxlabs.com

For getProfile and getProfiles, for given eth address or did determine if exist in ceramic

By eth address:

1. Load the caip10-link doc for the given eth address

  async linkExistInNetwork(accountId: AccountID):Promise<LinkProof | undefined> {
    const doc = await this.ceramic.createDocument(
      'caip10-link',
      { metadata: { controllers: [accountId] } },
      { anchor: false, publish: false }
    )
    const linkDoc = await this.ceramic.loadDocument(doc.id)
    return linkDoc.content as LinkProof | undefined
  }

• Pin it if not already pinned (will speed things up on subsequent loads)

2. If does not exist

• continue for 3box profile

3. if does exist
   • Get the DID from the content/LinkProof
   • Load the BasicProfile doc (should be possible knowing only: definition, schema, DID in ceramic or can just use IDX)

By DID:
skip to step 3, try to resolve BasicProfile if exist

Add Tests:
Reference existing tests and ideally just mock ceramic functions, returning LinkProof and a BasicProfile

Optimizations
this is going to slow up all requests, but hopefully within reasonable bounds
ideally will still fetch/load 3box profile in parallel while making ceramic requests, so that can instantly be returned if not links in ceramic

probably JSDOC again, and/or what ever is best practice for documenting api

From gateway
get link doc
get did, call by did function lookup

From gateway
get did doc
get idx
get profile

If none exist at any point, return 3box, otherwise return ceramic profile

Probably should have standardize earlier, most requests consume both encoded and non encoded params. But threads for example doesnt for all args.

Edit oed, 2020-02-20

It seems like this error comes from the profileList endopint in 3box-api not working properly. Even calling this endpoint with only one address that has a proper profile this call stalls and eventually causes an error.

Single missing profile when fetching multiple profiles through graphql causes the whole query to fail

@msterle commented on Mon Feb 10 2020

If one or more addresses aren't registered with the address server, the graphql endpoint correctly returns only those with existing profiles. However, if the address is registered with the server, but the profile doesn't exist, the graphql endpoint returns a 500 error.

Test query:

{"operationName":"Profiles","variables":{"accounts":["<address 1>", "<address 2>"]},"query":"query Profiles($accounts: [String]!) {\n  profiles(ids: $accounts) {\n eth_address\n    image\n   }\n}\n"}

Is it possible this issue is linked to profiles that have been corrupted, and the error on those isn't being handled gracefully?

For example addresses, ping @msterle directly

I'm pretty sure this was working when it was implemented into the Hub app.
Now, hitting this end point with const opts = {metadata: true }; returns an object with timestamp value as null (value of key is correctly returned, however).

Expect:

{
    value: <value>,
    timestamp: <time key was last updated>
}

Reference spec