new WAPI+WUI proposal

[meejah]

Lukas Pirl <tahoe-dev at lukas-pirl.de> 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
version).

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
capability).

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).

-- 
meejah