The browser extension

Weft tasks is where a person answers a program. When a node asks a question, the run parks and the question shows up here as a card.

Install it from Firefox Add-ons or the Chrome Web Store. To build it from your checkout instead, ./setup.sh --browser --no-sign writes an unpacked build per browser under extension-browser/build/, and Chrome loads it from chrome://extensions with Developer mode on.

Point it at your runtime

The extension ships with no access to anything. Not your runtime, not any website. You give it one address at a time.

Mint a token from your project folder:

weft token mint --name "my laptop"

Then open the extension’s settings, add your runtime’s address and paste the token. The browser will ask whether to allow access to that host, because until you say yes the extension cannot reach it. Remove the last token for a host and it hands that permission back.

The token’s full value is printed once, at mint, and never again. weft token ls shows you which tokens exist by a short prefix, and weft token revoke <id> ends one.

Scoping a token

A token with no restrictions sees every waiting node in the tenant, but none of your nodes’ displays.

The display scope is the one that grants nothing by default, because a display can be a credential: a bridge showing a QR code to scan, a database showing the password it just minted.

What you see

The popup is the list. It shows whether each runtime is reachable, and splits what is waiting into triggers, which start a new run, and questions from runs already going.

It distinguishes two kinds of failure, and says which: a host you have not granted, and a host it could not reach. A popup that said “Connected” while a runtime was down would be hiding tasks from you.

The task page is one card at a time, with the count, and Previous and Next to move. The card shows whatever the node declared: values to read, text boxes, option buttons, approve and reject pairs, images and files.

Approve and reject are labelled by whoever wrote the program (the field’s approveLabel and rejectLabel), so they can read Send it and Hold it rather than the defaults.

If a program’s author gave you an instance token, Your connections (the link icon in the popup) is where you connect your own accounts. With the instance token added, it lists the nodes that run on the instance’s own account, and what you connect and pick there belongs to that instance alone. If the page says you have no instance token, add the one the program’s author gave you; other tokens you have added are ignored there. For instance tokens and what they reach, go and read programs with instances.

After you submit, the card says Submitted for a moment and moves to the next. Back in the editor, the cyan ring on that box goes green and the rest of the program runs. On a trigger, Fire shows Fired instead: a run started, and the trigger stays so you can fire it again.

What it can see

It holds three permissions: storage for your tokens, notifications, and alarms for the poller behind them. No access to any site until you add a runtime, and the Firefox build declares that it collects nothing.

It talks to two addresses on your runtime: one that lists what is waiting, and one that answers. With an instance token it also talks to the instance’s connect page on the runtime. The token rides in the Authorization header rather than in the URL, so it does not land in anybody’s logs.

Writing your own instead

The extension is one consumer, not the only possible one. It reads the same two addresses any client can, and it renders a form from what the node declared rather than knowing anything about particular nodes. A Slack bot or an internal page would work the same way against the same addresses.

If you want to build one, the token is the whole authentication story, and weft token mint --display <node> is how it gets to read what a node is showing.