it should already does to index files for search.

Yes, but it doesn't read the file's content to classify their type...at
least any client I'll be writing in the near future won't have a built-in
type detector for all possible types out there...

> Google? It's the most common encoding for hashes for instance...

I apologize... but base32 sucks. I am reading a description explaining why it exists. The main reason of this is because I can be confused with 1, L with 1, O with 0 and U for "accidental obscenity" (seen in the documentation). We speak about a program, a program does not confuse I and 1.

Well, then you tell me the reason why it's in wide use and not something
else?

I partially agree. Most of the time, a client does not use more than 1 context but context is a lot easier to handle in a hub because it is basically a C structure (or a class for C++ dev.) If all conditions are required in a class, it can evolve to its next "state". The best example is IMHO the initial authentification. (I describe using current DC command) We need the $MyINFO and the $MyNick, the order has no meaning. If both conditions are met, it evolves either to the "password" state or to the "connected" state. In a group of commands, there is no need to have an order.

Well, you're saying it yourself...change all occurances of "state" to
"context" in the adc description and you'll see a striking similarity...
I don't know how you plan to write your context driven machine, but the
client will be striving to reach a certain target context set, and to reach
it it has to pass through a number of other context sets (which both you and
adc calls states), and in a particular order at that (or did you want to
send the password before you know whether it's needed?)...although while you
will be evolving, adc will make a transition...

/J