mt logoMyToken
Market cap:
0%
FGI:
0%
Cryptocurrencies:--
Exchanges --
ETH Gas:--
EN
USD
APP
Ap Store QR Code

Scan Download

黑客松常客?一文速览默默发展的Web3邮箱赛道

Collect
Share

原文来源:WhoKnows DAO

最近两年,我们看到了许多打着去中心化的名号做邮箱服务的项目,甚至可以说,Web3 邮箱已经快要成为 Web3 黑客松的常客。作为一个每天都在批判的喷子,面对这种情况,很难不去思考这类产品究竟有什么用,为什么这么多人都在抢着做,到底能做出来个什么。于是就有了这篇文章。

作为 Web3 邮箱设计原型的传统电子邮箱,可以算是当今互联网上存活时间最久的通信手段之一:目前仍在使用的主要协议标准最早出现在 1980 年代,而电子邮件的原型甚至可以追溯到 1972 年。据 Statista 统计数据显示,截至 2020 年,世界范围内共有超过 40 亿的邮箱用户,超过世界总人口的 50%,并依旧保持着 3% 的年增率。

黑客松常客?一文速览默默发展的Web3邮箱赛道

数据来源:Statista

由此可见,Web3 邮箱项目的频频出现并非偶然。我们尝试把饼画大一点:如果能够成功整合 Web2+3 场景下的需求,该产品将有可能成为打通 web2 与 3 次元壁的一把钥匙,吞噬传统邮箱行业巨头的份额,带来互联网的新时代,并成为这个新时代的引领者之一。

我们不会在这里讨论所谓的饼究竟会不会实现,而是要讨论究竟有没有「如果」。其关键在于,Web2 与 Web3 两个场景下的用户是否真的会为了所谓的 Web3 邮箱买单。在本文中,我们将从链下需求与链上需求两方面入手,分析 Web3 邮箱的必要性,以及现有产品的是与非。

链下需求:便利低成本,互通验身份

如文章开头所说,电子邮件作为商业服务面向大众的传播始于 1980 年代,距今已有四十余年。针对链下需求,我们不妨将其拆解成四十年不变的固有底层需求,以及伴随着时代的进步、文明的发展出现的未被满足的新生需求两部分进行分析。满足前者的性能需要保持,而针对后者,我们可以尝试思考这些痛点是否能够通过邮件上链的方式解决。

在电子邮箱被发明之前,无法 / 不愿见面的人们通常使用电话、信件与传真进行沟通。我们在以下的两个表格中分别从用户和服务提供商的角度对于这几类信息传递方式进行了对比。

黑客松常客?一文速览默默发展的Web3邮箱赛道

可以看出,电子邮件风靡全球,主要原因在于:

  • 零成本:电话和传真需要支付通讯费,信件需要支付邮费,而标准化的电子邮件可以白嫖;

  • 速度与灵活性兼备:信件运输耗时长,电话需要占用双方的大量时间,而电子邮件随寄随到,查看时间自由;

  • 便于保管与复用:电话、传真和信件的内容分别需要以录音和纸质文件的形式留存,其对于保管的条件要求更高,并且难以复用,而电子邮件的内容是作为数据存在的,因此其不但不需要物理上的保管条件,还可以简单检索内容、复用内容;

  • 支持群发:电子邮件可以在一次操作之下就将内容同时发给多人,其他几项服务均不具备此功能;

  • 身份隐私:电子邮件可以作为连接到不同服务的端口,用户不再需要记住每个平台的 ID 和密码是什么,只需要「使用电子邮箱登录」。同时,其相较于同样可以作为接口的电话而言,由于可以在不暴露个人信息的情况下注册多个账号,隐私性更强,与互联网服务的适配程度更高。

而在服务提供商看来,电子邮件的几个好处是相辅相成的,各个优势统统指向了对于用户数据的再利用,而这恰好也是运营商愿意免费提供标准化邮箱服务的最大原因:

  • 高连续性:使用电子邮件的沟通通常是你来我往的。当一位用户使用自己的 Gmail 地址向其他用户发送了一封邮件后,对方在尝试回信时多半会选择发送至该 Gmail 邮箱地址。相较于电话与传真,电子邮件服务的提供商爬取用户行为与社交数据的难度更低;

  • 高同质性:发明当初,用户只能与和自己使用同一服务运营商的其他用户进行通信。随着跨运营商通信需求的不断扩大,邮箱服务逐渐从无法跨运营商通信,迭代到了支持非标准化的跨运营商通信,而后又开发出了一直沿用至今的标准化的通信协议:基于 Unix 的计算机间互通的 UUCP、可以在 TCP/IP 上运行的 SMTP,以及用于阅读电子邮件的协议 POP 和 IMAP. 虽然电子邮箱服务的提供商数不胜数,但是标准电子邮件本身是同质化严重的。一个同质化严重并且免费的服务,其用户很难因为对于服务本身的追求而选择更换服务提供商;

  • 高依赖性:对于电子邮件服务的依赖性源于极高的替换成本,而所谓的替换成本则源于电子邮箱作为身份认证的功能。一旦用户在个人信息中填入了某个邮箱,又或者是使用某个邮箱注册了某些平台的服务,其若是想要更换邮箱,则意味着需要找到自己在未来依旧想要保持的全部服务,挨个进行邮箱地址的替换。在电子邮件同质化严重的前提下,用户这样做通常是弊大于利的;

  • 获取用户数据:通过邮件的收发记录以及其作为登录接口时获得的行为数据,分析用户的行为习惯;

  • 聚客效应:以邮箱为入口,向用户推广整个生态。如 Google 生态、Yahoo 生态、腾讯生态等;

至此,我们大致了解了电子邮件在发明当初相较于同类解决方案的优势所在:便利、认证身份、不要钱。接下来,我们再来看看在当今的社会中,电子邮件作为上个时代的产物是如何在即时通讯软件的迅速普及之下夹缝求生的。

黑客松常客?一文速览默默发展的Web3邮箱赛道

在即时通讯软件中,信息被按照聊天对象分类,分别显示在与各个好友的聊天室中,其试图突出的是「沟通的对象」;而电子邮箱则是会将每一条邮件单独拆出来,各自显示标题,其更注重的是「沟通的内容」。即时通讯软件更在意信息的量,而电子邮件更重视信息的质。至此,电子邮件与即时通讯软件的分工已经非常清晰明了,电子邮件适用于重要、严肃的事项;而即时通讯软件更适合日常化的交流。

至此,我们已经认识了电子邮件的生存之道。那么,用户的痛点在哪里呢?电子邮件的产品设计看起来非常完美,事实上也很接近于完美,因此才能几十年内经久不衰,不过,其依旧有 3 个主要的痛点:

  • 信息泄露:邮件内容可以被服务提供商监视 / 偷看。为解决此问题,许多学者与机构对于基于量子通信的邮件传输系统进行了大量的研究,目前已有明确的解决方案;

  • 信息丢失:服务提供商随时可能停止提供服务。如前文所述,运营商通过提供免费邮箱服务试图换取的是用户数据以及生态推广,由于用户并不需要有很多个电子邮箱,导致此类业务的先发优势明显,超过七成的邮箱服务商在运营的过程中选择关停。同时,在用户未违反任何规定的前提下突然被停用账号的例子也屡见不鲜。由于目前主流的电子邮件服务提供商通常会保留对于用户邮箱账号的控制权,用户无法通过迁移邮箱地址等方式恢复服务,只能被动接受;

  • 垃圾邮件:电子邮件的低传输门槛,导致了垃圾邮件的泛滥。用户需要花费大量时间接收并处理垃圾邮件,容易错过重要的信息,甚至可能成为钓鱼邮件的被害者。数据显示,2021 年的中国每天约产生 85 亿条垃圾邮件;

黑客松常客?一文速览默默发展的Web3邮箱赛道

数据来源:Statista

到这里,我们已经明白了传统电子邮件服务尚待解决的问题。这些问题对于 C 端用户而言也许并不是很重要,天天想着要是 Google 倒闭了电子邮箱怎么办的人应该不多。在电子邮件服务市场,C 端是大头,因此如果想着通过解决此类问题来抢占传统邮箱市场份额,在目前的阶段基本等同于痴人说梦。那么,有没有合适的链上需求需要使用邮箱解决呢?

链上需求:个人主权与加密通信

基于 Web3 的叙事,电子邮件类产品的作用主要包括以下几点:

  • 无成本沟通:无成本沟通包括了两方面,一是平台无门槛、不收费,二是可以在不支付 Gas Fee 的前提下,实现私钥间加密对话;

  • 沟通渠道整合:上文中有提到,电子邮箱最厉害的一点之一就是高度的标准化带来的不同平台间的互通性。因此 Web3 电子邮箱能否实现邮件的标准化,同时支持私钥 - 私钥、私钥 - 邮件地址、邮件地址 - 邮件地址之间的信息传输,非常重要;

  • 身份证明:类似于传统邮箱可以作为登录接口,Web3 邮箱也可以作为 DID 使用。为了使个人信息准确且不可篡改,需保证邮件地址的唯一性、不可转移性与高度的可组合性;

  • 资产输送:支持以邮件为介质的链上资产输送;

  • 定向散播:通过链上与链下数据筛选出具备某类特征(比如持有特定资产)的邮箱地址,并进行邮件群发。

在考虑这部分需求时,我们不得不思考两个点:

  1. 如何选择合适的加密传输技术解决方案

  2. 如何在隐私、效率、成本之间进行权衡

以此为参考,我们来对比一下当前市场上已经初试啼声的几个邮件类产品。

项目对比

Dmail

主要功能:

  • NFT 化邮箱地址 = 收费

  • NFT 化邮件

  • Web2+3 收发邮件

  • 群发

  • 链上资产传输

  • 邮箱地址(NFT)用于登录

黑客松常客?一文速览默默发展的Web3邮箱赛道

技术方案:

  • 网络:选择了 Dfinity ICP(Internet Computer),而不是主流公链 /L2. 其原因一是不需要支付 Gas,二是看好 ICP 自身的可扩张性和互操作性

  • 合约:使用 Rust 语言编写,基于 RFC8555 协议,制定了独自的标准协议

  • 虚拟机:采用 WASM 编码标准,支持多语言,在降低成本的同时,提升数据安全与性能

  • 发送:SMTP = 明文

  • 连接链上与链下:基于 MIME 的新标准研发中

黑客松常客?一文速览默默发展的Web3邮箱赛道

需求权衡:

  • 引入 DAO 治理模式,实现去中心化管理(并确保了服务的持续性)

  • ICP 的核心技术,VRF 和 BLS,本就可以确保速度与数据安全;在此之上 Dmail 对于用户的信息进行了分割管理,加强了可扩张性,如图所示:

    标题以哈希的形式储存于链上

    内容与附件被拆分成几份,分别储存于在获取邮箱账号时分配给每位用户的专属存储罐里

  • 隐私=效率>成本

黑客松常客?一文速览默默发展的Web3邮箱赛道

主要痛点:

  • 与 web3 邮箱竞品相比,由于需要购买邮箱地址 NFT,准入成本较高

  • 为每个用户分配存储罐的机制,会导致存储成本随着用户数量的提升而线性提升

  • NFT 可转移,代表邮箱地址可转移

Mail3

主要功能:

  • ENS 作为邮箱地址 = 免费

  • 多链互通

  • 垃圾邮件过滤

  • Web2+3 收发邮件

  • 群发

  • 邮箱地址作为底层社交协议

技术方案:

  • 网络:DCN(Data Communication Network),为 IPFS 的进化版,提供分布式的数据存储与访问服务,确保数据可用性

  • 发送:SMTP = 明文

  • 连接链上与链下:通过 LMPS 连接到传统的电子邮件系统,链上链下用户共享基于 OpenPGP 和 S/MIME 的加密结构

黑客松常客?一文速览默默发展的Web3邮箱赛道

需求权衡:

  • 引入 DAO 治理模式,实现去中心化管理(并确保了服务的持续性)

  • 基于 IPFS 的半永久存储

  • 效率=成本>隐私

主要痛点:

  • ENS 作为邮箱地址,会导致邮箱地址实质上变成半永久的财产,ENS 到期后,将无法继续收到邮件

Skiff Mail

主要功能:

  • 支持邮箱地址 / 钱包注册 = 免费

  • 端对端加密

  • Web2+3 收发邮件

  • 群发

  • 与 Skiff 生态互通

  • 2FA

  • 共享文档协作

技术方案:

  • 引入长期签名用公钥与中长期加密公钥,两个公钥均对应着使用 Curve25519 协议生成的私钥

  • 使用 tweetnacl-js 作为加密库对于公钥加密

  • A 发送邮件 / 共享文件给 B 时,自动生成随机的对称密钥,并使用 AB 二人的加密公钥对此密钥进行加密

  • IPFS 半永久存储

  • 需求权衡:

  • 安全>效率=成本

黑客松常客?一文速览默默发展的Web3邮箱赛道

主要痛点:

  • 提升存储、编辑历史保存时间需付费

MetaMail

主要功能:

  • 无门槛使用 = 免费

  • ENS 可作为邮箱地址

  • 邮件内容加密传输

  • Web2+3 收发邮件

  • 群发

技术方案:

  • 发送:SMTP + 私钥加密 / 公钥端到端加密(接收者为 MetaMail 地址时)

需求权衡:

  • 管理员保有用户用于邮件加密的私钥

  • 成本>效率>安全

主要痛点:

  • 不支持附件加密,安全性问题

  • 平台方可以查看邮件,安全性问题

  • 高签名频率,不便

EtherMail

主要功能:

  • 使用钱包登录 = 免费

  • ToB 功能较为丰富,自带定时更新的基于链上数据的邮箱列表与分组发送系统

  • 自定义垃圾邮件过滤 = 看广告 2Earn、订阅 2Earn

技术方案:

  • 采用 Thor 协议,用户可以选择授权给平台方访问私钥的权限,也可以不这样做;

  • 将密钥储存于区块链上,以保证其安全性;

需求权衡:

  • 引入 DAO 治理模式,实现去中心化管理(并确保了服务的持续性)

  • 安全=效率=成本

主要痛点:

  • 网页响应非常慢,每个动作都要花费几分钟的时间处理

项目对比小结

黑客松常客?一文速览默默发展的Web3邮箱赛道

几个项目各有所长,也各有不足。目前进度最快、构思最符合 Web3 叙事的是 Dmail 和 Mail3。不难发现,作为强互动的社交协议,Web3 邮箱与 DID 概念的适配性极高,非常适合在之后作为链接不同协议的桥梁,就像在传统互联网中电子邮箱作为登录接口一样。而作为 DID,其首先需要具备的就是不可转移性以及高度的功能多样性。期待未来的项目方可以在当前项目的基础之上引入 SBT 系统,以确保邮箱地址不可转移;同时,将资产输送系统与钱包进行融合,打造出基于传统邮箱的基本功能、但完全适配于 Web3 语境的社交协议。

Disclaimer: The copyright of this article belongs to the original author and does not represent MyToken(www.mytokencap.com)Opinions and positions; please contact us if you have questions about content