feat: add schema definition for project keys table

[achou11]

Closes #165

Questions:

• should we rename the project table to something like project_info? Didn't think it was highly necessary so only updated the associated variable name for now
• what should the table name be? i.e. projectKeys (consistent with our naming conventions) vs project_keys (consistent with sqlite table naming conventions. also, singular or plural here?
• should it be projectKey column be named projectId instead? Should it be more specific i.e. projectPublicKey?
• would it be helpful to add a note in https://github.com/digidem/mapeo-core-next/blob/38ab9de01c83f99cd161c0a76317c395209b097c/src/core-manager/index.js#L13 about updating this file if more namespaces are created, if applicable?

[achou11]

Getting a test failure for https://github.com/digidem/mapeo-core-next/blob/38ab9de01c83f99cd161c0a76317c395209b097c/tests/schema.js#L87

Does there need to be a backlink table for this new table?

[gmaclennan]

Does there need to be a backlink table for this new table?

No, that test needs updated. There only need to be backlink tables for tables that index data types from Mapeo Schema. This test is a bit fragile and more of a reminder - open to ideas about a sensible way to exclude a table like this from needing a backlink table.

[gmaclennan]

• should we rename the project table to something like project_info? Didn't think it was highly necessary so only updated the associated variable name for now

Yes, I think name is projectSetting and also rename the schema name in @mapeo/schema to projectSetting to avoid confusion.

• what should the table name be? i.e. projectKeys (consistent with our naming conventions) vs project_keys (consistent with sqlite table naming conventions. also, singular or plural here?

We're naming all our other tables in camelcase. Don't think we need to stick with any conventions here, just what is easy and consistent. I think plural makes sense (e.g. projectKeys) because each row is multiple keys - I know our other table names are singular, but I think the plural here is actually projectKeyses 😆

• should it be projectKey column be named projectId instead? Should it be more specific i.e. projectPublicKey?

Yes, let's rename it projectId. We have been following a pattern where key = Buffer, id = string. We need to define what a projectId is - should it be a hex representation of the project public key, or a hex of the discovery key, or a base32 of the project key (this is what hypercore uses as coreId), or should it be a hash of the project key with something else, so that knowing the project ID does not give you the information for discovery?

• would it be helpful to add a note in https://github.com/digidem/mapeo-core-next/blob/38ab9de01c83f99cd161c0a76317c395209b097c/src/core-manager/index.js#L13
  about updating this file if more namespaces are created, if applicable?

Yes, good idea. Or dynamically generate the table schema based on that constant?

const columns = {
   projectKey: text('projectKey').notNull().primaryKey(),
   projectSecretKey: blob('projectSecretKey'),
}

for (const namespace of NAMESPACES) {
  const columnName = namespace + 'EncryptionKey'
  columns[columnName] = blob(columnName)
}

[achou11]

No, that test needs updated. There only need to be backlink tables for tables that index data types from Mapeo Schema. This test is a bit fragile and more of a reminder - open to ideas about a sensible way to exclude a table like this from needing a backlink table.

I don't have any elegant ideas here. Only ones I have are:

1. Hardcode the exclusion in the test
2. Create separate files for tables that require backlinks e.g.

- schema/
|--- client.js # projectKey table would still stay here, re-export project and project backlink tables from requiresBacklink/client.js
|--- project.js
|--- requiresBacklink/
     |--- client.js # project and project backlink tables are exported here
     |--- project.js

then update the test to only import from the requiresBacklink/ directory 🤷 note that requiresBacklink is arbitrary (please suggest a better name if possible)

EDIT: looks like (2) doesn't work well with Drizzle's CLI (i.e. when re-exporting like export * from './requiresBackLink/client.js'), so maybe that isn't the way to go...

EDIT 2: decided to update the tests to filter using @mapeo/schema as the source of truth for determining data type schemas

[achou11]

We need to define what a projectId is - should it be a hex representation of the project public key, or a hex of the discovery key, or a base32 of the project key (this is what hypercore uses as coreId), or should it be a hash of the project key with something else, so that knowing the project ID does not give you the information for discovery?

Might be better if I create a separate issue for this since nothing in this PR is actually going to affect that

EDIT: add any thoughts on this to #171

[gmaclennan]

Looks good to me

[achou11]

Yes, I think name is projectSetting and also rename the schema name in @mapeo/schema to projectSetting to avoid confusion.

Going to merge without addressing this here. There's an issue opened in the schema repo to track and eventually address: https://github.com/digidem/mapeo-schema/issues/114