new WAPI+WUI proposal

meejah meejah at
Fri Dec 2 15:29:16 UTC 2016

Lukas Pirl <tahoe-dev at> writes:

> To be frank, it is annoying that apparently HTML has to be parsed to
> get [..]

Yes, I would like all information that's visible in the WebUI to be
available as some kind of "actual" data (e.g. like the existing JSON
option, except complete).

For example, there's a new "tahoe magic-folder" CLI command that uses a
JSON endpoint to get information. Similarly, "tahoe status" does
something similar (and expanded some things that weren't in the JSON

We're planning to make use of similar tactics for tahoe-gui ...

Personally, I like the simplicity of the "token" approach to access the
"raw data" API (which is that you have to be able to read a random token
from the node-dir and give it to the API).

Thus, it's easy to write local applications that the same user runs --
some attacker who can read all your files and make network connections
can just directly read all your Tahoe node-dir data anyway (and that's
probably more valuable than any in-memory ephemeral data?)

That said, though, it's basically the same as Tor's control-protocol and
using that often makes one wish that it had more fine-grained
permissions. So, it *would* be nice to be able to have "capabilities" of
some kind that grant (limited) permission to interact with the data-API
-- think of granting a new application a capability to "read statistics
and metadata", but granting a different application the ability to read
and write "secret" information (e.g. a magic-folder directory

So long as we make the token scheme take any-sized token, it would
probably be easy to upgrade the API in the future -- i.e. apps will
already be built to pass along a token of some kind and so in the future
if we get "config-caps", etc these can just be passed as the token.

Thus, version 0 of the API can be: anything that's already being
revealed in the HTML API can be revealed via the JSON API in exchange
for the "I can read local files" token.

Version 1 can grow the first time a "can't be public" thing (or a
"writes stuff/makes changes" thing) is added to the API -- and then the
capability (or whatever) required to do this is still just passed along
as the token (but apps will know they need a "special" one).


More information about the tahoe-dev mailing list