I originally wanted to build an email client fully in the browser, but realized I can't do TCP connections (for IMAP) directly inside the browser.<p>I came up with a few alternative:<p>"Hosted" version:<p>Hosted service that runs IMAP on a back-end, and roughly "proxies" IMAP over a WebSocket. This is the best for the user, because no download/setup, just a web page. This also enabled easy push notification (IDLE process on back-end -> push notifications). It would make it very easy adapt to mobile too.<p>Con: the service must store/see email credentials for the users, and all their data being ran through a service they don't control. Although it wouldn't actually store any email data or use it in anyway, I don't think everyone is comfortable with this idea.<p>"Desktop"/bridge version:<p>A program that you run on your computer, which acts as the bridge between your browser and the IMAP server. Like the hosted one, but directly on your computer. This would mean the users have full control over their data.<p>Con: must be downloaded/installed on desktop/server. This could also be prepackaged with the actual interface inside an Electron-type of application, basically a normal desktop email client.<p>Mobile version:<p>With Flutter, TCP connections are possible, making it so an app could be made.<p>My problem with mobile is that this client would be focused for "busy people", and mobile isn't the best way to manage emails. Push notifications are essential and could be unreliable since it wouldn't be using a third-party to use Google/Apple's push notifications, but would instead run as a background process.<p>The first version is the best for users, but the worse for privacy. It is the one I would like to do, plus offering users to self-host, so if they are very privacy-concerned, can still use the client with maximal privacy.<p>What does HN think is the best to make, from a user and company standpoint?