Consume upload-client and access-client

[alanshaw]

This module will become a thin wrapper around access-client and upload-client, with the following proposed API:

export class Client {
  /* passthroughs to `upload-client` */
  uploadFile(file: Blob, options: UploadOptions): Promise<CID>
  uploadDirectory(dir: File[], options: UploadOptions): Promise<CID>

  /* passthroughs to `access-client` */
  agent(): Signer
  // space management
  currentSpace(): Space|undefined
  setCurrentSpace(did: DID): Promise<void>
  spaces(): Space[]
  createSpace(name?: string): Promise<DID>
  registerSpace(email: string): Promise<void>
  addSpace(proof: Delegation): Promise<void>
  // capability management
  proofs(): Delegation[]
  addProof(proof: Delegation): Promise<void>
  delegations(): Delegation[]
  createDelegation(audience: Principal, abilities: Abilities[], options: DelegationOptions): Delegation

  /* Advanced API - grouped by capability namespace: *************************/

  capability: {
    /* passthroughs to `upload-client` */
    store: {
      add(carBytes: Blob, options: RequestOptions): Promise<CID>
      remove(carCID: CID, options: RequestOptions): Promise<void>
      list(options: ListRequestOptions): Promise<ListResponse<StoreListResult>>
    }
  
    /* passthroughs to `upload-client` */
    upload: {
      add(root: CID, shards: CID[], options: RequestOptions): Promise<void>
      remove(root: CID, options: RequestOptions): Promise<void>
      list(options: ListRequestOptions): Promise<ListResponse<UploadListResult>>
    }
  
    /* passthroughs to `access-client` */
    space {
      info(space: DID): Promise<SpaceInfo>
      recover(space: DID, email: string): Promise<void>
    }
  }
}

export function create(options?: ClientFactoryOptions): Promise<Client>

[jchris]

Will uploadFile automatically fast-path when the file is small? Eg no chunking, inline CAR if possible, etc?

[ice-breaker-tg]

This looks good to me, the wrapping of stuff is similar to what we had hoped to do before so I think this is a great api.
The namespacing is also very nice IMO.

My only concern is the "overlap" of uploadFile, and upload.* namespaces (I think that internally uploadFile will call the other and handle it, but that is exposed as a lower level api? If so, I think that's fine but we should clarify in docs or etc).

[alanshaw]

Will uploadFile automatically fast-path when the file is small? Eg no chunking, inline CAR if possible, etc?

If the file is smaller then the minimum shard size then it won't be sharded. It can definitely auto inline but that's not something that we support yet!

My only concern is the "overlap" of uploadFile, and upload.* namespaces

Yes, root API uploadFile and uploadDirectory are both sugar for unixfs encode + store/add + upload/add. I'm open to suggestion for a better name?

[alanshaw]

My only concern is the "overlap" of uploadFile, and upload.* namespaces (I think that internally uploadFile will call the other and handle it, but that is exposed as a lower level api? If so, I think that's fine but we should clarify in docs or etc).

Totally valid, my current thinking is to put these under capability in the client, so you'd call something like client.capability.upload.add(root, shards), which is...verbose, but maybe a better separation.