I find this is totally wrong reading. If A=B, it also means that B=A. So, is dom0 AdminVM? For sure yes!. But is AdminVM dom0? Not necessarily! So we cannot say that equation dom0=AdminVM is valid, which actually it isn’t. Dom0 is so much more! Is template a qube? Well yes, but qube isn’t necessarily Template! See? So, for the sake of others who won’t click on the link you posted, i.e. doesn’t stand for dom0 = Admin VM, but it means " as GUI currently resides in dom0" which is totally different, because tomorrow GUI could reside in any other AdminVM (it already does, but not in AdminVM? Anyway, it doesn’t matter).
So obviously other users are confused too about the dom0 in QubesAir
But even if this is true, it is good for the question: will we actually have as much as we need dom0s? Well, I admit even current single dom0 is too much for most of users. How would they handle as many of them? And my fear now: will they be offered someone else to handle those for them? In both cases, how much control then users would have over Qubes?
Or, there will be still one and only “control center”.
For these assumptions, let me quote Sven from another subject
How much control over it user would have then? The same as over Kernel and Xen? This insinuates AdminVMs again. But they’re not dom0.
Yet. But does introducing AdminVMs everywhere prejudge it’s “destiny” regarding users interacting with dom0?
It’s not about the term, it’s about the function of the core part of Qubes would have in the Air.
Goals
The goals of the Admin API system is to provide a way for the user to manage the domains without direct access to dom0.
Threat model
TBD
Can’t wait to see it
I must admit that I have a strong feeling of unrest that I will be enjoying and be fully responsible for my actions in dom0 for not too long in the future.