Indeed. And although I’m planning to have an unprivileged web build eventually for cases like discourse accounts where TCP is not needed, the current game-plan is to package it as both:
Packaging it as a browser extension/app is not just a way to get access to the TCP API. The delivery model also has improved security characteristics over running a messaging client off a server that I control and have to keep safe.
Note that glodastrophe is targeting desktop and possibly tablet form factors. I would like to resurrect the FxOS mail app UI as well for a phone-targeted UI, but until Firefox for Android (Fennec) runs WebExtensions or Chrome Apps work on Android, I’m don’t think there is direct runtime support for that since WebRT was removed from Fennec. And while using something like Apache Cordova or similar is an option to package it as an app for Android/iOS/etc, at least if it’s just me hacking on these things, I don’t think I’ll realistically be able to get to that anytime soon given how little hobby programming time I’ve had thus far.
Which is not to say that my game-plan needs to be the only way the email app lives on. I definitely welcome other contributors or other attempts to use the email backend in ways that are aligned with what I’m planning to do. (Which means using the conversations “convoy” branch of gaia-email-libs-and-more for a purely client side mail app. For example, I’m on-board for adding a JMAP account type to the backend since I believe JMAP is the future of email protocols, but I wouldn’t want to spend cycles on trying to adapt the Perl JMAP proxy to run as part of a mail app to workaround lack of access to the TCP API.)