Cypht Webmail Screen Shots – Mobile Version

I had a request on the “Cypht Webmail Screen Shots” post to share some mobile/responsive views of the program. Since I always aim to please, and since the percentage of people with even a shred of interest in this project is so very very small, here it is!

Overall, my design skills fall somewhere between terrible and total shit. My design premise for the Cypht UI has been: “Don’t pretend you know what colors go well together. Don’t fool yourself into thinking you can make something slick. JUST KEEP IT SIMPLE DUMMY“.

I’m pleasantly surprised with the result. It’s pretty standard webmail fare, super simple, and reasonably consistent across browsers.

cypht_mobile10

The main menu. Available by swiping right on any page, or with the awkward looking triangle in the upper left corner of a page.

cypht_mobile9

I pretty much never write E-mail on my phone. But I could!

cypht_mobile8

Yay, only 1 unread message! Also, if you have not checked out Humble Bundle, you should.

cypht_mobile6

The site settings page

cypht_mobile5

General site settings. Kind of squeezed in there, but not too bad!

cypht_mobile3

Search all the things again!

cypht_mobile4

Read a search result. The message view page is tricky on mobile. This one looks pretty good, but others not so much. It’s a work in progress.

cypht_mobile2

Just a teeny tiny calendar. Nothing to see here.

cypht_mobile1

RSS news feed for my favorite Linux news site.

cypht_mobile15

Server management page

cypht_mobile13

“Quick add” dialog on the server page. So cool.

cypht_mobile14

Keyboard shortcut management.

cypht_mobile16

IMAP folder management.

cypht_mobile11

Save settings page.

There are some noticeable omissions to this list, specifically the contacts management interface and the profiles page. I left profiles out because it looks like dog poop, and I left contacts out because I realized the screenshot was of my actual contacts and that would be dumb to post. It looked pretty good though! All in all, Cypht is pretty responsive. Writing this post helped me identify some areas we need to work on, so thanks to the person who requested it!

Cypht Webmail Screen Shots

This is YET ANOTHER post to shill for Cypht, my Open Source webmail project. But instead of droning on endlessly about technical mumbo-jumbo like I usually do, this one has pictures! They are pretty! Let’s look at them!

cypht14

Browsing IMAP folders like it’s the noughts yo!

cypht12

Fancy compose form with an HTML editor. Cypht also supports text only for outbound E-mail (and FTW).

cypht18

The Servers page is where you add data sources to your account. Without data sources there is not much to look at.

cypht8

Site settings page with expandable categories.

cypht13

Search all the things at once!

cypht4

Read one of the things you searched for!

cypht9

This webmail program has a calendar. It’s truly amazing.

cypht5

Home page on mobile (S5 emulation with Chromium)

cypht15

Main menu on mobile

cypht7

RSS feed list view on mobile

cypht16

I almost forgot we support themes. I suck at it, but it’s pretty easy. Maybe somebody who doesn’t suck at it will make some more

cypht17

This theme is called “VT100”. See what I mean about sucking at themes?

There is more, but I’m too lazy to set up decent looking test data and you get the idea. All this uploading of images has made me tired, so I think I will go take a nap.

5 Cool Cypht Webmail Features

Cypht is the Open Source webmail program I have been toiling away on for the last few years. It stands out from the competition because of a few unique options, not that it doesn’t have its own warts. But let’s focus on the positive, and not talk about things like the painful installation process, outstanding bugs, or unfinished features. I wouldn’t be doing a very good job converting this blog into a propaganda platform for the project with a title like “5 Shitty Cypht Webmail Features“. Also, I’m a dork. What I think qualifies as cool is known to be subjective.

1. Stand Alone Authentication
Pretty boring opener, but bear with me. Typically webmail programs are designed to point to an E-mail source, like an IMAP or POP3 server, for authentication. They pass the username and password you give them on to the E-mail server, which then tells the webmail program if you are legit or bogus. Cypht boldly (not really) breaks this paradigm by splitting authentication from your E-mail sources.

We support using LDAP or a database to authenticate users, as well as the old-school method of using a pre-configured IMAP or POP3 server. Adding new authentication mechanisms is designed to be easy (relatively), so any source that can verify your username and password can be coded up. We even support a dynamic login process that lets you pick from common E-mail service providers, and can auto-discover E-mail services for a domain (sometimes).

2. Combined Views
Cypht provides combined lists of E-mail messages from all your accounts. One of the reasons I started working on yet another webmail program, was because I wanted this feature. I spend 95% of my time using these views for my E-mail needs, and very little time browsing folders and pages like it’s 1999 (though Cypht supports this as well)

Show me the latest 20 unread messages from each of my accounts over the last 2 weeks in one list? Done. Search for the boarding pass I misplaced even though I forgot which E-mail account I used to make the reservation, and the plane takes off in 5 minutes? Done (this actually happened to me). If you have more than one E-mail account, combined views quickly become the bee’s knees. If you only have one E-mail address, you probably should have skipped this section.

3. Module Sets
Plugins are cool. Module sets are cooler. First of all, they sound cooler. Secondly, module sets are not just a way to bolt on features. Cypht is entirely built of module sets, and a framework to run them. Only one is required, the “core” set. It does things like basic page layout and login/logout. Everything else (IMAP, SMTP, POP3, RSS, contacts, profiles, the list goes on) is its own module set, and can be enabled or disabled independently.

As if that wasn’t the ultimate in coolness, there’s more! Module sets can override each other. Don’t like the default behavior of a core module? You can change it without hacking a single line of Cypht code by creating your own module set that overrides it. I need a sweater it’s getting so cool in here! There is even some poorly written documentation about module sets for aspiring developers.

4. Focus on Security
Security is serious business for a webmail program. So many attack vectors! From filtering out nasties, to TLS everywhere, to encrypting data at rest – Cypht goes the extra mile to try to cover all the bases. Cypht was built with security and privacy as core design principles.

Securing a complex web application is a process, and we welcome feedback and suggestions to continue to improve. For the gory details, check out our security page with a list of impressive sounding technical stuff.

5. Production and Debug Mode
Cypht has two modes of operation. “Debug” mode is what you use when troubleshooting issues or doing development. “Production” mode is what you use when … in production. Debug mode fire-hoses your PHP log with information about each request, enables all errors and warnings, and activates new modules as you create them for a quick write-then-test cycle. Production mode uses combined and minfied assets, silences warnings, and pre-calculates module dependencies.

If you are looking for a different kind of webmail, one that is lightweight, secure, and has a complicated install process -check out Cypht. Or don’t. It’s cool.

The Future of E-mail

I think about E-mail a lot. I’m weird that way. I think of E-mail as an annoying neighbor who wanders over to your yard on a regular basis to chit-chat when you are obviously busy – It just won’t go away. It’s like a realization had in the shower in your early 40’s about your hairstyle choice – It hasn’t really changed in 20 years. And (last simile, I promise), like an untreated rash – It’s not going to just fade away. Trust me on that last one.

Every so often somebody declares that “X software” will kill E-mail, usually referring to some sort of instant message program like Slack. I will admit that while I worked at Automattic we used Slack to a much greater degree than E-mail, but they served different purposes. If E-mail is the electronic version of mail, glorified IRC Services like Slack are the electronic version of a phone call. I don’t recall the US Post Office going out of business when the telephone was invented.

After the “E-mail killers” comes the revolutionaries, changing the way you use E-mail forever. It’s new! It’s shiny! Never mind the fact it’s built on the same old plumbing, don’t worry about that! It has smart-<feature>! It solves all the problems with E-mail you didn’t even know you had until we told you! The world is saved! I like exclamation points!

As a webmail developer, I’m not trying to revolutionize anything. I’m certainly not interested in killing off E-mail. Channeling my inner curmudgeon, I actually like E-mail. But I also think there is room for improvement. With my latest Open Source webmail project, called Cypht (which this blog is designed to shill for), I’m trying to address those areas of concern. Unfortunately for you, I’m going to elaborate.

I have lots of E-mail addresses, mostly because I’m a dork, but I bet that if you have any E-mail account at all, you probably have more than one. Work account. Gmail. Maybe your ISP crams one down your throat like mine does. A throw-away account. Some other free E-mail service you signed up for that one time for some secretive reason you don’t want to talk about.

I want a webmail solution that I can host, that gives me direct access to all my accounts. I don’t want to forward everything to the Google content-mining advertisement delivery interface. I don’t want to POP messages from one account to another in a chain of complicated hops that somehow results in two copies of everything. I want an E-mail delivered to account X to stay in account X, I just want to check it at the same time I check Y and Z.

In my not so humble opinion, this is the most useful feature of Cypht – aggregated views from multiple accounts. You can still go old school and browse folder hierarchies like it’s 1999, but you can also see all your unread messages from all your accounts in a single view. Or search them all at once. Even though this software is not even alpha quality yet, the search feature has already saved my butt more than once.

Well shoot, I got so focused on pimping my project that I forgot to say anything meaningful about the future of E-mail. So here are some half-assed predictions. I predict that E-mail will persist for at least another 20 years as one of the main underpinnings of the internet, and that for the most part it will go unchanged. IMAP servers will still be IMAPing, and SMTP servers will keep SMTPing. Or maybe we will all be using Slack to E-mail and back to Slack gateways, so we never have to login to an E-mail client again. Heck if I know, I’m terrible at predicting things. Either way I need to go pick up my rash ointment.

Plugins all the way down

When I set out to build a new Open Source webmail program last year, one of the main things I wanted to accomplish was a robust plugin system. In the past, I designed functionality not unlike the way WordPress plugins work (which is not unlike the way Squirrelmail plugins work, my first exposure to the concept). I think the strength of a plugin system really helps grow an Open Source project. Would WordPress be such a dominant CMS if the plugin ecosystem was not so vast? During its heyday, Squirrelmail had a vibrant add-on community, and a lot of new users were drawn to the project because of it. Many core developers of that project started out writing plugins, including me.

I decided to take a different approach this time around. What if instead of having a core flow of execution that plugins can add to or alter, everything was a plugin? If all the work needed to process a request was modular, it would provide a way for sites to customize almost anything about the application without having to hack a core file or implement a crazy workaround. It would also make it possible to customize the app simply by including the plugins you want. I decided to build the application this way, and while it turned out a teeny-tiny bit complicated, the results are pretty cool if I do say so myself. And I do.

The system is composed of three distinct components. The “framework” which processes a page request and provides high level constructs for things like session management and page routing. “modules sets” that provide specific types of functionality, such as an IMAP module set that let’s you access IMAP E-mail accounts, and individual “modules” inside of sets, that do a small piece of work. The framework provides an execution environment for module sets. Module sets assign modules to request identifiers and define allowed input and output types. Finally, individual modules do the work of processing page input and building page output. Let’s pretend that was not complicated, because there’s more!

Module sets contain two types of modules, “handler” modules, and “output” modules. Handler modules have access to the session, site configuration, user configuration, and white-listed/sanitized input values. Output modules only have access to the data produced by handler modules (and other output modules). A module set combines handler modules that process and take action on user input, with output modules that format the response to be sent to the browser. The result is a one way data flow through module execution, with default (though configurable) immutability. It’s kind of like the principles of React, without the icky JavaScript part.

Module sets can override each other and replace module assignments done by other sets, or insert a module before or after a module assigned by another set. There is only one required set, the “core” modules. Sites can override core functionality in this set, but it must be included for the others to work. Of course, some or all of it could be replaced with something completely site specific, which means you could change the program into virtually any type of web application you want, and still get the benefit of the lightweight framework.

One of the best things about this system is it requires module sets to white-list and type-cast user input. Modules cannot access standard PHP super globals – they must use the provided data framework, because those super globals are mercilessly unset before modules execute. Modules also have easy output escaping and string translating functionality built-in, so there are no complicated procedures to safely output untrusted data. Modules are designed to have a single purpose, so they end up being concise, which makes auditing and testing easier. Modules use inheritance to access data they need, there is no need to resort to global scope (the application framework and all the included module sets don’t use any PHP globals).

Developing modules can be tricky, so there is a built-in “debug mode” that makes it a lot easier to catch common mistakes and see immediate results. In debug mode, module assignments are dynamically determined – you don’t have to rebuild the configuration file for a newly created module to fire. Assets like CSS and JavaScript includes are un-minified and separately requested – so troubleshooting problems from a browser developer console is a lot easier. Debug mode also enables a constant stream of information to the PHP error log about each page request. Of course there is also a “hello world” module set included in the source, with loads of comments and examples.

To date, I have built more than 15 module sets using this system. So far, I think it’s pretty neat. It’s complicated, but it provides a structured way to modify the program with a safer-than-most API while maintaining a concise separation of concerns. It’s definitely more complex than a lot of plugin systems out there, but also more powerful with an eye on overall performance. At the very least, I think we can all agree that “module set” sounds way cooler than “plugin”, so that’s a plus.