Allow easy capturing of bbapi calls in bb.js

[ludamad]

Context

Context delta from previous discussion with doing this with aztec.js profile command:

This was previously described as a potential aztec.js feature, but we wanted something more convenient than calling a separate command from the code that caused the error. Environment variable, query parameter, local storage to trigger this or other such things virtually any user could easily handle. Cue traumatized response from Grego from dealing with bundler hell with having mutually exclusive browser and native (node) logic (as this can't be done the same way in both environments).

This issue departs from that thinking because

• Just documenting this command like Grego suggests might serve devs who have issues in testing, but it does not serve devs well who have issues live from end users. We need something dead simple for that
• The concerns about bundler hell don't exist with bb.js. Bb.js is set up for different code for browser and native nodejs.
• Charlie is actively merging native civc codepaths to also use bb.js, adding more value in having this logic in bb.js
• BBAPI is a much more sensible target than our current ivc inputs format longer term. It can replay failure in anything exposed from BB. This also helps the noir ecosystem, e.g. zkpassport.

So in summary it's best done in bb.js, it can be done in a very easy way even for relatively inexperienced end users, and we already set up a node/browser split very nicely for this use-case.

Details

in bb.js package.json we have

  "exports": {
    ".": {
      "require": "./dest/node-cjs/index.js",
      "browser": "./dest/browser/index.js",
      "default": "./dest/node/index.js"
    }

Which in general causes different versions of each module to be exposed to the library user. This avoids bundler hell.

Action items: [ ] Rename cbind to bbapi (in a separate PR, if doing this after just mentally rename the bbapi folder below to 'cbind') [ ] Inside bbapi introduce the browser/node split that other modules have [ ] Inside bbapi/browser:

• Introduce utility shouldLogBbapi that checks local storage for the string BBAPI_DEBUG_LOG, or if this exists as a query param
• Introduce utility saveBbapiLogs that takes the bbapi objects and saves them as size-prefixed (4 byte little endian size prefix) msgpack objects. This should be saved to a temporary file that the browser then prompts the user to save somewhere.

Note: This is saved in the format that bbapi msgpack run accepts.

[ ] Inside bbapi/node:

• Introduce utility shouldLogBbapi that checks the environment variable BBAPI_DEBUG_LOG
• Introduce utility saveBbapiLogs that takes the bbapi objects and saves them as size-prefixed (4 byte little endian size prefix) msgpack objects. This should be saved to the folder inside BBAPI_DEBUG_LOG with a timestamp.

Note: This is saved in the format that bbapi msgpack run accepts. [ ] Inside non-browser-specific code:

• Initialize a global variable const BBAPI_LOGGING by calling shouldLogBbapi in the correct environment
• in bbapi generated code we should add functionality to add to a global list of bbapi calls if BBAPI_LOGGING is true
• Whenever an operation in the Backend classes executes, or in finally block after try finally, we should call saveBbapiLogs.

[johnathan79717]

This is currently on hold due to security considerations.

[ludamad]

I would say we should continue on with the node implementation, personally, and drop current plans for the browser version. The browser version is a security can of worms, but the node one should be right for the target audience