LIV: 我自己的网页邮箱

年初的时候我写过一篇我的电子邮件处理流程，详细描述了我是如何处理我自己的邮件的。简单的说，我主要是利用字符终端工具来浏览，回复邮件，从而达到高效，省时，安全的目的。但是，字符终端总有时候不尽如人意：很多邮件都是基于HTML的超文本邮件，在字符终端工具下展示总是欠缺。何况，有不少时候我还需要点击邮件中的链接，进入网页应用，在字符终端下基本上所有的网页应用都是打不开的。所以，我还是需要一个网页版邮箱。读过我你有电子邮件邮箱吗？一文的朋友知道我为什么不愿意用Gmail之类的应用，而要自己搭建邮件服务器。那么，在自己的邮件服务器上，能不能实现类似Gmail的功能呢？

现有的开源工具

我曾经使用过两种开源网页邮箱工具，都是可以安装到自己的服务器上的。一个叫Sogo, 一个叫roundcube. 这两个软件包都可以在自建的邮件服务器上实现网页邮箱功能，其功能接近常见基于IMAP的邮件软件例如Thunderbird. 但是，我用了一段时间后都闲置不用，而重新回到字符终端工具了，即使字符工具有上述种种不便。这是因为这两个应用都是在IMAP上再包装的一层，所以：

• IMAP做不到的事情，它们也做不到。例如有索引的全文检索
• IMAP做的到的事情，它们才有可能做得到，但只可能更慢
• 它们在设计上面向一个小型机构，服务于几十上百用户。而我只需要服务几个用户，主要是我自己，再加上我的家人，所以有不匹配的感觉

我逐渐意识到，类似Gmail之类的云端邮件应用相当不简单。邮件这个应用虽然很古老，但是和其他网页版应用相比，要求其实很高：

• 邮件是数据量相当大的应用。我邮箱里有7万封邮件，数据量超过几个G。这个应用必须和相当大的数据有紧密联系。
• 邮件是和用户交互比较复杂的应用。假如点个什么按钮都要等个半秒一秒，你的耐心很快会被消耗殆尽的。

在一个网页应用的范畴下，数据在服务器端，交互在客户端，这就形成了一个两难：假如主要逻辑在服务器端，客户端通过HTTP请求与服务器端则会造成不可忽视的交互延迟，导致用户体验不好。假如使用类似React之类的前端框架，把逻辑功能尽量往前端迁移，则和后端的数据有带宽和距离上的割裂，这样就是一个相当复杂的分布式系统，一些重型数据应用，例如全文检索就不容易实现。

那么还有什么办法？

Phoenix LiveView

Phoenix LiveView是近几年涌现出来的新型网页应用框架。它是一个后端框架，但绕过了相对比较慢的无状态HTTP协议，而使用长时，有状态的WebSocket协议，使得客户端和服务器端的专有进程深度绑定，从而大大削减了交互延时。对于上述的邮件应用非常适合：所有应用逻辑运行在服务器端，和数据零距离，访问无阻碍。后端通过一个有状态的WebSocket连接和轻量的网页前端进行频繁交互，即时反馈加超文本邮件展示没问题！

问题只有一个，就是没有现成应用。自由软件的世界里，没有枪没有炮，我自己造！我的应用栈分三层：

• 搜索引擎。这一层是现有的：mu: Maildir Utility. 我常用的字符终端工具 mu4e 即是基于此。
• 我在mu 的基础上封装一层，实现一个Erlang API，并补充一些mu没有的功能，把独享的mu界面改造成可共享界面。这一层我管它叫mc: Maildir Commander
• 最上层的网页应用基于Phoenix LiveView + Surface，用Elixir实现。这一层叫LIV: Live Inbox View

mc 和liv 是站在自由软件巨人们肩膀上开发的，它们自然也是自由软件。

LIV

LIV才刚刚发布，只实现了我最需要的基本功能，目前只能认为是一个MVP (Minimum Viable Product):

• 只有一种邮件列表方式，就是按线索，时间倒序排列
• 不能删除邮件。这是因为我是用脚本自动删除无用邮件的
• 不能打开附件，写邮件也不能加附件。我对附件不太感冒

但是，LIV有其独特的功能，你在其他任何地方都找不到：

• 每封邮件，每个查询，都可以添加到浏览器标准书签
• 用线索智能展示邮件，即使在一个很窄的手机屏幕都可以用
• 使用Markdown格式来写邮件，并做即时HTML渲染

在家庭宽带+WiFi环境下，LIV使用如丝般顺滑。如果使用LTE网络，则会略感延迟，但不会比Gmail差。我自己已经是95%以上的时间使用LIV阅读回复邮件了。当然，LIV的目的不是100%取代字符终端邮件工具，而是与之共存。毕竟在字符终端上，使用快捷键定制操作其效率是网页应用比不了的。

LIV现在没多少文档，也暂时不太适合终端用户使用。如果你像我一样，自己运行自己的邮件服务器，并且不怕自己编译安装软件的话，不妨一试。我期待收到你的反馈！