Good Timing 
For a while it has looked to me like the shift from “launcher” to “authenticator” was de facto, at least for now, and last week I was thinking that unless this was going to change we should stop calling it “launcher”, I’m pleased were getting into both the what and the how of this because I’ve been wondering about it for ages.
I held back my renaming suggestion, because I wanted a better name than “authenticator” and have not yet come up with one. So, while we ponder the what and how, I suggest we also think about that, although, if it turns out that “authenticator” becomes a largely hidden component it may not matter - so I won’t lose any sleep over it until this becomes clearer.
Don’t Be Evil
One immediate question that may seem superficial (as well, sorry ) is that by using electron, which I acknowledge comes with lots of pros, means using Chrome I think?
Maybe not a big issue, I’m not sure, especially as this is also used to build Signal desktop. Which is why I heard the reservations: some people simply won’t trust Google’s codebase (at least I think that’s the reason for objections).
So I’d like someone to confirm electron implies Chrome, implies Google code, and then for us to consider what potential impact this has on:
a) security risks and ways to ameliorate them, and
b) perception of security, considering that I know of one high profile privacy advocate who won’t use Signal desktop for this reason, and who obviously would have problems with SAFEnetwork if Chrome was a key component. (I know, I know, same issue with SAFE Beaker, so really I should have raised this earlier! 
)
I don’t know how serious the security implications are, or how widespread any negative perception might be, but it does seem to me a big decision to lock ourselves into before considering this angle.
I think the above is a discussion in itself so I’ve started a topic for replies related to: Security of Electron Based Apps: Launcher, SAFE Beaker & third party
The Pros Have It
The pros seem weighty, and of the two cons only the first seems significant, but I don’t have the understanding to judge that one - I look forward to following the RFC discussion on this!
Elaboration Please
I’d like further explanation of the scheme, perhaps from different perspectives because I don’t understand this in enough detail to think properly about it yet.
So more detail on the granularity of permissions being considering here (because my underfunding is we’d like a lot more than we have so far), and how these would work from (particularly) user experience perspective, application process, and developer implementation would be helpful.
I could try and make a guess, and then ask questions to fill in blanks, but if someone has a vision of these perspectives and is willing to try writing any of them out, it might speed things up.
It does sound like s good way to go and I’m excited we’re getting to this, and taking the time to work out a good solution from various perspectives. Thank you MaidSafe and Francis.
I’m also wondering if I missed something:
We are currently comparing two approaches and we haven’t agreed on one of them yet.
What are the two approaches? I’m reading the OP as one thing rather than two, but perhaps I understand even less than I thought
Whoops, Licensing
EDIT: I almost forgot, does this mean apps would be linking to the core libraries, and if so how do we preserve the none GPL option for developers who wish it?