TRACKING: ODD Devtools browser extension

[bgins]

The ODD Devtools extension provides developers a devtools panel with information for debugging their ODD applications.

It should display the following information:

• ODD SDK version
• App namespace
• Username
• Account DID
• Agent DID
• Event log (shows filesystem events for v1, more events in a future version)
• Data root CID
• Capabilities (what parts of WNFS does the app have access to)

The information should only be exposed when the developer has set debug to true when initializing an ODD program.

Milestone 0.1

Tasks

• Add issue and PR templates
• Set up Vite build
• Upgrade to Manifest V3
• Set up communication loop with page
• Add background message reception
• Reconnect on page load
• Implement text-based filtering
• Implement devtools panel UI
• Set not connected status on pages that do not support the ODD SDK
• Fix Messages are not displayed when multiple tabs are open
• Add not connected and connection error views
• Add project description and privacy policy
• Add Firefox extension ID
• Publish to Chrome Web Store and Firefox Add-ons

Dependencies

• Add browser extension support ts-odd#460

Milestone 0.2

• Firefox displays not connected view incorrectly
• Detect if the user has enabled the optional permissions
• Improve state information in event payloads

No milestone

• Improve time direction indication
• Store messages in extension storage

[jeffgca]

Once we get through Milestone 0.1 we should run the design past nicoth and other relatively engaged devs to get feedback.

[depatchedmode]

Overall

Needs an instructional state "Webnative wasn't detected on this page. You have to set DEBUG to true."

Filesystem view

We'll start with an event log. Highest value starting point, and simpler to implement.

Concerns:

• may not have whole tree
• performance could be slow loading the whole tree

Extra credit metadata:

• CID
• Creation time
• Arbitrary metadata input by dev

Questions Filesystem tree helps answer:

• Was the file written or not?
• Builds a mental model for the FS heirarchy
• Event log would be helpful — maybe this is where we start
• Replay the state of the tree across time — probably for a later release

Capabilities:

Show which resources this app has been granted access to via UCANs.

• Which authentication strategy was used?
• More importantly: is this an origin resource or a resource projected into this local file space via a capability
• From whom was this resource requested? To prep for a future when more than just the auth lobby exists as an authorization provider

[depatchedmode]

Okay, here's my pencil sketch:

And the disconnected state:

Right now the settings pane would probably not contain much, but I'm following the tab pattern that Vue Devtools uses because we'll expand beyond just the event log in the near future. Was considering tossing some of the more stable session / app data in that pane, but it feels like it would be more ergonomic to have it available in the payload pane next to the event data for ease of access.