- test entries for passwords at 100 entries. it's...pretty slow
at 300 passwords, about 8 seconds to scan/read-in the database.
once the database is read-in, sorting and viewing is fast. good
news is that heap usage is about 300k for that many entries,
no OOM crashes found. just slow.
- fix an unimplemented()! error
- strip out some debug
originally we stuck it in the CRED_DICT because it forces its
creation -- but there's no reason to *really* do that. We just
set the dictionary to be created if it's not existent in the later
API calls.
By moving this to FIDO_DICT instead of FIDO_CRED_DICT it makes
key access & sorting much cleaner in the UX, because you don't
have this odd key hanging out, and it also means that you can't
have an attack on the system where you try to name a key with
the name held in FIDO_CRED_DICT to try and read it out.
UX interaction via blocking modals are put into its own thread
so that the background UX can update while menus and modals are
popped up.
Still some bugs to work out to make this fully implemented,
but this is the major work fleshed out.
The prediction API now takes an API token. This is a 128-bit
number that gets passed to the prediction engine, and it's meant
to be unique for every context that requires a predictor.
It's up to the prediction engine to do anything with the token.
For the "null" engines (such as the icontray for `vault` and
`tts`) the token is just ignored. But for example, in `shellchat`,
the API token is used to store a history record in a HashMap on
a per-token basis. This means that every app that uses the
`shellchat` history function gets their own history that can only
be read out by that app.
The actual token itself is mostly passed through the API. The
token storage is in the Context layer (each Context has a record
for a token, that starts as `None`), and is passed down to
the predictor every time the context swaps, and the predictor
receives the token and passes it back if the token was `Some`,
or allocates a new random token if it was `None`.
Note that everything is a Context, including, for example, menus and
modal dialog boxes, but not all contexts have predictors. Only
Contexts that ask for a predictor have them. This mechanism
works smoothly in this model (as opposed to other hacks and work-arounds
previously tried getting to this solution).
