"Anonymous Proxy" is a bit of a confusing name. There's not really anything anonymous about it. We should rename it to something a bit more descriptive, such as "Pure Proxy", "Shell Proxy", "Dynamic Proxy", or "Keyless Proxy"
The wiki article on this likely should be updated to reflect more of _what you can do_ with one. Once this is very well established, the name may become more clear.
IMHO the aspect that is critical and novel is that a _keyed_ account (shown in the diagram as the "anon proxy") creates and controls a _full account_ that has _no key_. To others this "user primary account" looks to be just like any regular single owner account, but no one could ever construct a key to sign on it's behalf . The _only_ way this account can do anything is by the "anon proxy/proxies" sign on behalf of the "user primary account".

So I would propose we have a graphic that replaces:
Then give examples of use cases and analogies like:
Open to thoughts/comments. I am still trying to grasp the concept and have not looked at how this is implemented at all ๐ ... Who does have insight into the code behind this? We should ping them ๐๐ผ
Tagging @laboon for wiki changes
@NukeManDan I think the code you're referring to is located in the frame/proxy/src/lib.rs file.
that you technically could find and use to make a MS
I wouldn't agree with the word _technically_ here; there's no _technical_ way to do that other than bruteforcing 2 to power two-hundred-something keys. I would call this probability _theoretical_ at best.
I think I also misled everyone during today's call mentioning that multisig accounts differ from anonymous proxies in the way they addresses are generated (here is the multisig generation, and here is the anonymous proxy one).|
They both rely on BLAKE2 encoding of some deterministic seed values, and the only difference in there is that the proxy-related code also uses block height and extrinsic index as its inputs (thus requiring attacker to also have control over block authoring to have any predicting power over what the account address is going to be like โ in multisig theoretically a malicious party can theoretically get at least some sort of a "vanity address" by submitting a carefully-chosen member account address).
"Keyless Proxy" ๐
I'm not a fan of "Keyless Proxy" and prefer "Pure Proxy" because other accounts could be "keyless" proxies. For example, multisig and derivative* accounts are keyless, but they could be proxies. Those are, in a sense, keyless proxies, but does not fully convey the meaning of anon proxy.
The most difficult hurdle for me was that the anon proxy is actually the _proxied_ account (which is why I explicitly centered the Polkadot Wiki section around this fact). I think I would call the dispatchable generate_proxied to generate the new account ID, and then you just call it a "pure proxied account" to express the fact that proxy is the only means of accessing it.
* Talking about utility.as_derivative, not key derivation, here.
"Pure proxy" convey as much information as anonymous proxy to the user. Probably even less and again require the user to read through a lot of docs to understand them... IMHO this does not help in understanding the proxy in any way.