Running ceramicstudio/ceramic-eas

Devtools
1

Hi, I’m getting this error when running npm run dev on the ceramic-eas repo.

node:internal/errors:484
    ErrorCaptureStackTrace(err);
    ^

TypeError [ERR_INVALID_ARG_TYPE]: The "list[0]" argument must be an instance of Buffer or Uint8Array. Received an instance of Array
    at new NodeError (node:internal/errors:393:5)
    at Function.concat (node:buffer:565:13)
    at concat (file:///Users/kylehauskins-kaplan/ceramic-eas/node_modules/uint8arrays/dist/src/concat.js:8:47)
    at get bytes (file:///Users/kylehauskins-kaplan/ceramic-eas/node_modules/@ceramicnetwork/streamid/lib/stream-id.js:82:16)
    at descriptor.get (file:///Users/kylehauskins-kaplan/ceramic-eas/node_modules/mapmoize/dist/getter.js:13:49)
    at StreamID.toString (file:///Users/kylehauskins-kaplan/ceramic-eas/node_modules/@ceramicnetwork/streamid/lib/stream-id.js:96:35)
    at descriptor.value (file:///Users/kylehauskins-kaplan/ceramic-eas/node_modules/mapmoize/dist/method.js:30:57)
    at file:///Users/kylehauskins-kaplan/ceramic-eas/node_modules/@composedb/devtools/dist/composite.js:65:37
    at ModuleJob.run (node:internal/modules/esm/module_job:193:25)
    at async Promise.all (index 0) {
  code: 'ERR_INVALID_ARG_TYPE'
}

Anyone else run into this or have a possible solution?

2

@mzk Do you have any insight here?

3

This looks like the same error as was reported here for Ceramic: (from Discord user: elcharitas) Please help, I am running a local ceramic node and I keep getting this error: - #16 by christina

Which we fixed in a hotfix with Fix Uint8Array inputs for concatenation calls (#3048) · ceramicnetwork/js-ceramic@2b75468 · GitHub.

Maybe there needs to be a similar update to the ceramic-eas code if it uses Uint8Array directly, or maybe it just needs to be updated to use the newest version of the Ceramic libraries.

4

@spencer locally, I tried updating all the packages to Ceramic 3.0. This fixed the unit8Array issue, but I ran into additional issues down the line when trying to fetch my attestations. I’m not sure if it was because I updated Ceramic or if it was something else.

5

Okay, that sounds like a different issue then. Can you attach the new error you are seeing?

6

Yes, I get this error:

{
    "errors": [
        {
            "message": "Unknown argument \"filters\" on field \"Query.attestationIndex\".",
            "locations": [
                {
                    "line": 3,
                    "column": 32
                }
            ]
        }
    ]
}

when attempting to fetch all connections.

POST to http://localhost:3000/api/all with payload:
{“account”:“0x0d9032c4bf587ce875de7fa0cf51f07cec360341”}

7

@paul any ideas?

8

Hi @kylekaplan - can you please also share which composedb package versions you’re running?

FYI - I’m running this locally now as well and encountering the same issue with the filter on the /api/all call not being recognized.

I’ve also updated my packages to the following:

    "@ceramicnetwork/cli": "^3.0.5",
    "@ceramicnetwork/common": "^3.0.5",
    "@ceramicnetwork/http-client": "^3.0.5",
    "@composedb/cli": "^0.6.0",
    "@composedb/client": "^0.6.0",
    "@composedb/devtools": "^0.6.0",
    "@composedb/devtools-node": "^0.6.0",
9

@mzk Yes, I’m doing the same.

    "@ceramicnetwork/cli": "~3.0.0",
    "@ceramicnetwork/common": "~3.0.0",
    "@ceramicnetwork/http-client": "~3.0.0",
    "@composedb/cli": "0.6.0",
    "@composedb/client": "0.6.0",
    "@composedb/devtools": "0.6.0",
    "@composedb/devtools-node": "0.6.0",

and

"@composedb/types": "^0.6.0",
10

This is very strange.

@paul - one thing I just noticed in my definition.json file is that the indices do not look right.
For example, I just looked at the definition.json output of this repo (which uses different model definitions by the way, so not 1:1) but I noticed that the “indices” key looks like this:

Screenshot 2023-12-04 at 1.41.09 PM

whereas the indices key for Ceramic-EAS repo looks like:

Screenshot 2023-12-04 at 1.41.40 PM
Screenshot 2023-12-04 at 1.41.40 PM709×97 12 KB

However, the Attestation definition for Ceramic-EAS does define indices:

type Attestation @createModel(
    accountRelation: LIST
    description: "A simple attestation record model"
  )
  @createIndex(fields: [{ path: ["attester"] }])
  @createIndex(fields: [{ path: ["recipient"] }])
{
  publisher: DID! @documentAccount 
  uid: String! @string(minLength: 66, maxLength: 66)
  schema: String! @string(minLength: 66, maxLength: 66)
  attester: String! @string(minLength: 42, maxLength: 42)
  verifyingContract: String! @string(minLength: 42, maxLength: 42)
  easVersion: String! @string(maxLength: 5)
  version: Int!
  chainId: Int! 
  r: String! @string(minLength: 66, maxLength: 66)
  s: String! @string(minLength: 66, maxLength: 66)
  v: Int! 
  types: [Types] @list(maxLength: 100)
  recipient: String @string(minLength: 42, maxLength: 42)
  expirationTime: DateTime
  revocationTime: DateTime
  refUID: String @string(minLength: 66, maxLength: 66)
  time: Int! 
  data: String! @string(maxLength: 1000000)
}

type Types {
  name: String! @string(maxLength: 20)
  type: String! @string(maxLength: 20)
}

So it looks like there is an issue with how these are being compiled. Could this be related to the recent fix for Uint8Arrays?
cc @spencer

11

Thanks for the details.
Looks like the ceramic-eas repo uses v0.5 of ComposeDB, so the version of the packages and CLI should be matching, if you use v0.6 of the CLI for example that can explain the issue.
I think the best solution here would be to update the ceramic-eas dependencies to the latest version of Ceramic and ComposeDB.

Regarding the specifics of the issue, ComposeDB v0.5 incorrectly uses model names instead of IDs as keys in the indices record of the encoded definition.
This is fixed in v0.6, but if you try using an encoded definition generated by v0.5 with v0.6, you’ll need to manually edit the encoded composite to replace the model names by IDs, otherwise the indices won’t be handled.

12

Thanks, Paul.

The official repo has not been updated yet, but locally I am using these package configs:

"@ceramicnetwork/cli": "^3.0.5",
"@ceramicnetwork/common": "^3.0.5",
"@ceramicnetwork/http-client": "^3.0.5",
"@composedb/cli": "^0.6.0",
"@composedb/client": "^0.6.0",
"@composedb/devtools": "^0.6.0",
"@composedb/devtools-node": "^0.6.0",

The issue I described in my last message (the screenshots showing the issues I’m seeing with indices not being recognized) was encountered using the packages above.

13

@mzk did you create the encoded composite definition with ComposeDB v0.5 please?
If so, you’ll need to manually replace the keys of the indices object from model names to model IDs.

14

@kylekaplan - this should be fixed with the update to several packages. I also reflected those changes in the Ceramic-EAS repo. I’d therefore recommend pulling down the latest changes.

When you have a moment, could you please try again and let us know?

15

@mzk Works beautifully now. Thanks!

Just a couple more things:
The readme should probably be updated from “make sure you are using node version 16” to “make sure you are using node version 20”

Also, when I click on an attestation from the connections page, It brings me to a page like this: Ethereum Attestation Service - Explorer that just says “Waiting for attestation…” do you know what this is about, should it be showing my attestation details or is this correct behavior?

image
image2872×826 134 KB

Thanks so much again.

16

Hi @kylekaplan,

Great call on updating the README instructions - just changed to v20.

Another great call on the click behavior. The easscan site uses a trad DB to store off-chain attestations (at the moment). I ended up changing this to an endpoint on your local 7007 port that will pull the full document and show to the user in the browser (i.e. http://localhost:7007/api/v0/streams/ + streamID)

Thanks so much for all your help and attention to detail! It’s really appreciated

17

Thanks @mzk!

The localhost link is very helpful!

18

@kylekaplan awesome!