Hi guys, we've just run into a little error after connecting verida app. Seems to be related to crypto-pouch>garbados-crypt:

Uncaught (in promise) Error: A password is required for encryption or decryption.
    at new Crypt (index.js:64)
    at trySetup (index.js:34)
    at async PouchDB.crypto (index.js:53)

Reproduction

1. Install dependencies

npm install

2. Start development server

npm run dev

3. Open web browser and navigate to the development server at http://localhost:8080

4. Click on connect button to connect

5. Login with metamask

Expectation

Connect to app using metamask successfully

Actual

Receiving message in the browser console

index.js:64 Uncaught (in promise) Error: A password is required for encryption or decryption.

This error seems to be thrown from the crypto-pouch > garbados-crypt package

Code

I made a little repo here for debugging.

Thanks!

Description

I ran into this issue when I was working on pagination for my app using a custom schema. Unfortunately, when trying to fetch documents from datastore using getMany({},{ limit:10, raw: true}) instead of receiving a bookmark, I got a "no indexes found". Not sure if there is any step I missed 😅.

Reproduction

1. Create a verida app with "ethr" as the provider
2. Create datastore with a custom schema:

{
    "$id": "http://localhost:8080/schemata/schemata/matter/schema.json",
    "name": "http://localhost:8080/schemata/schemata/matter",
    "title": "Animal",
    "pluralTitle": "Animals",
    "database": {
        "name": "Animal",
        "indexes": {
            "name": [
                "name"
            ],
            "id": [
                "id"
            ]
        }
    },
    "allOf": [
        {
            "$ref": "http://localhost:8080/schemata/base/schema.json"
        },
        {
            "type": "object",
            "properties": {
                "id": {
                    "type": "string"
                },
                "name": {
                    "type": "string"
                }
            },
            "required": [
                "id",
                "name"
            ],
            "$schema": "http://json-schema.org/draft-07/schema#"
        }
    ]
}

3. Create a few documents using the datastore.save() method
4. Attempt to fetch documents using getMany({},{ limit:2, raw:true})

Expectation

Bookmark property is available in result for pagination

Actual

Instead of a bookmark, we receive a warning: "No matching index found, create an index to optimize query time"

Repository

You can find the code here.

Much appreciated!

The current link :- http://docs.datastore.verida.io/ for the documentation is not functioning

Summary

Following Verida messaging documentation, I was trying to send a message between two users in the same application using NEAR as the provider when I encountered this error.

Reproduction

1. Create a Verida app using NEAR protocol.
2. Sign in using two different NEAR account in different browsers
3. Attempt to send a message using app.outbox.send()

You can clone and run the prototype in this repository to replicate the issue.

Expected

Message sent

Actual

Message not sent. Received error message in console:

Uncaught (in promise) Error: Invalid private key format. Expecting 32 bytes, but got 64
    at W (index.js:1)
    at Object.exports.SimpleSigner (index.js:1)
    at Outbox._callee$ (outbox.js:148)
    at tryCatch (runtime.js:63)
    at Generator.invoke [as _invoke] (runtime.js:293)
    at Generator.next (runtime.js:118)
    at asyncGeneratorStep (outbox.js:24)
    at _next (outbox.js:26)

The link Verida Datastore Documentation on the page https://github.com/verida/datastore is an invalid link. Chrome reported the following error:

This site can’t be reachedCheck if there is a typo in docs.datastore.verida.io.
DNS_PROBE_FINISHED_NXDOMAIN

Verida currently has its own DID generation approach. This has served it well for a PoC, but it's better to migrate to an alternative DID solution. In this issue I will outline a migration plan to use Ceramic network's 3ID DID provider.

Current architecture

Verida currently generates a DID on a per application basis:

• A blockchain wallet (Ethereum, VeChain, NEAR) is used to sign a consent message (ie: Do you want to login to the Verida Vault application?)
• The signature from this consent message is used as entropy to generate a new hierarchical deterministic wallet
• This HD wallet is then used to generate an encryption keypair and signing keypair
• A new Verida DID document is created that lists the public keys of those keypairs, which is then stored in a centralized API
• This DID document also stores information such as the database address for the user's encrypted data (using DID service definition)
• The encryption key is used to encrypt all data within that application context
• The signing key is used to sign all generated data within that application context

This offers the following benefits:

1. An existing blockchain wallet can be used to unlock the data for any application
2. This unlocking is deterministic. No private key needs to be stored, it can be generated on demand from the master blockchain wallet private key
3. Each application has it's own secure enclave of data, allowing a web application to only gain access to data relevant for its use case

Ceramic architecture

Ceramic provides an alternative approach, whereby multiple blockchain wallets can be used to control a 3ID DID via their 3ID DID Provider. Utilizing the Ceramic network and IDX protocol, it's possible to store public or encrypted data for each 3ID.

Under this model a user will need a 3ID in order to use the Verida network. A user will authenticate (or sign up) as follows:

• A user of a web application will login via 3ID connect (a web based interface for authenticating with a blockchain wallet to unlock an existing 3ID)
• Alternatively, a user of a web application will login via the Verida QR code login system connected to the Verida Vault

In the future, it may be possible for the Verida Vault QR code auth to be integrated into 3ID Connect.

Behind the scenes, the following needs to occur:

• Unlock or create the user's 3ID
• Once authenticated, the user can write data into their stream
• The 3ID provider instance private key can be used to deterministically sign a consent message to authenticate an application
• The 3ID provider instance can be used to generate encryption and signing keys (as per current process)
• The 3ID provider instance can be used to store the public key on a per application basis within the 3ID's IDX profile (instead of storing a Verida DID in a central database)

Why Ceramic?

• It's built to provide this core DID infrastructure
• Utilizes the latest decentralized standards and plays nice with DIF projects
• It has many features (key rotation, multiple blockchains supported, well supported project)
• It unlocks an ecosystem of existing apps that can tap into the power of the Verida network

Risks to eliminate

• Create a web based PoC that validates the above approach to using 3ID to store and unlock per application databases will work as expected
• Ceramic + IDX won't work within React Native environment
• Ceramic + IDX introduces latency issues in web or mobile environments
• Ceramic + IDX adds a significant file size overhead to the Verida Datastore library

Datastore is not working on the server due to window object being undefined.

Reproduction

1. Create a node app
2. Install @verida/datastore 0.7.3
3. Initialise verida in index.js using server method

const chain = 'ethr'
const address = '{some address}'
const privateKey = '{some private key}`

const app = new Verida({
  chain: chain,
  address: address,
  privateKey: privateKey
})

4. Run node app with node index.js

Expectation

Initialise successfully

Actual

Encounter error:

if (!window.nearAPI) window.nearAPI = nearAPI;
^
ReferenceError: window is not defined
 at Object.<anonymous> (.\node_modules\@verida\datastore\lib\helpers\near.js:18:1)

Please see the example github repository for more details.

Tasks:

• Support new datastore server changes
  • GNaP https://github.com/interop-alliance/gnap-client-js
  • ZCaP
  • JWT auth
• Update encrypted databases to store data as JWE's (inline with EDV spec)
• Support multiple, injectable authentication strategies (server side, qr code, metamask, key in a cookie)
• Support authenticating multiple application contexts within the same app (for connecting to remote third party app inboxes)
• #11
• Support swappable storage engines
• Merge changes into react-native branch

Summary

I have been writing a little prototype to test Verida database permission settings, I noticed that I couldn't set the permission of the new database to be anything but { read: "owner", write: "owner"}.

Reproduction

1. Connect to Verida app using either Ethereum or NEAR
2. Open a database with a brand new name with the permission { read: "public", write: "owner"}

Expect

A new database is created with the specified permission

Actual

New database is returned with permissions props set to { read:"owner", write: "owner"}

Preliminary investigation

I tracked it down to database.js where the permission is currently being overridden:

this.permissions = _.merge({
            read: "owner",
            write: "owner",
            readList: [],
            writeList: []
        }, this.config.permissions ? this.config.permissions : {});

Since lodash merge would not override props that already exists, this means the read and write permission of a database would always be the owner.

Side note

I was thinking about getting around this by setting the permission again. I noticed there's a way to update the set of users for read-list and write-list with Database.updateUsers, but I couldn't find the one that does it at the "owner"/"public"/"users" level