关于即刻 3.0、IFTTT、Gloria

在 Gloria 第一天发布的时候, 就有人问我, 这个东西跟 IFTTT 有什么区别. 我说有很大区别, IFTTT 需要网络服务接入 IFTTT, 提供的 Recipes 自由度也很有限.

现在回想当时的这个解释还是不细致的, 确切的说, Gloria 不是一款跟 IFTTT 对标的产品, IFTTT 的功能侧重点在于"如果(If)"发生了什么事情, "则(Then)"去做什么事, 是一个对事件流的处理, Gloria 的功能则侧重在发出通知和提醒这一方面, 倘若你编写过 Gloria 的任务代码, 你会发现即使从代码编写的角度, Gloria 都与这种"如果...则"的思维方式相去甚远. 虽然只要用户想这么做, 他们确实可以在 Gloria 里编写出"如果...则"的任务, 但这只是 Gloria 顺便实现的功能. 我也在考虑是否要把这个功能拆分到别的扩展程序里, 我想做一个自动装载脚本的程序(换句话说, 是一个自由度远大于 Greasemonkey 的扩展程序)已经很久了, 但考虑到我还有很多(非常多)的坑要去填, 这个事情也许还会继续一拖再拖.

参考最近即刻 APP 的表现, 我发现 Gloria 真正对标的产品其实是它(即使我在开发 Gloria 的时候根本看不起即刻的 APP), 虽然由于原理方面的限制, 即刻很有可能成为一个很像 IFTTT 的服务, 但在实现的功能角度上看, 其实二者还是非常相似的. 现在即刻 3.0 要出来了, 瞅一眼新功能, 会发现即刻将要支持用户自定义通知, 这个功能的本质和 Gloria 是一样的, 都是给用户很大的自由度去实现自己需要的功能, 但门槛肯定会有区别. Gloria 是一个面向有编程能力的用户的产品, 而即刻 APP 面向的是普通大众, 光这一点, 定制通知的细致程度就无法相提并论, 而且为了弥补这一点, 即刻势必要引入第三方开发者(顺便一提, 我觉得即刻这种程度的爬虫根本不需要招什么"爬虫工程师").

然后问题来了, 第三方开发者怎么开发出一个适配即刻 APP 推送的程序? 粗略的想了想, 有以下几种可能:

  1. 公开推送 API, 让第三方开发者通过这个 API 主动进行推送.
  2. 让第三方开发者在即刻的平台里自己定制爬虫.
  3. 通过 OAuth 验证打通第三方服务, 再让第三方开发者在即刻的平台里实现通知功能.
  4. 通过手机端的应用之间的通讯手段来进行推送.

讲道理, 4 是最不可能的, 因为没有必要, 各种平台实现起来也很混乱, 用处很小. 然后 1 也是不太可能的, 因为除非 API 设计得很合理, 否则带来的效果根本不如 2 和 3, 而且允许外部访问 API 还要带来很多新的问题, 如无必要, 勿增实体. 所以最大的可能性就是 2 和 3 的结合, 如果等 3.0 正式推出, 产品超出了我的预期, 那还真是要敬佩一番.

像即刻、IFTTT 这种服务一直就存在一个难题, 就是程序该怎么访问到用户的隐私数据, 该怎么平滑用户授权方面带来的不好的用户体验, 这个世界上公开透明的东西很多, 但未必是你真正想要的, 所以如果得不到用户的隐私数据, 那很多事情就做不了:

  • 比如你 bilibili 订阅的 UP 主传了新的视频, 程序不得到用户的隐私数据, 怎么知道你订阅了哪些 UP 主? 不知道你订阅了谁, 就没法给你发有关你关注的人的新视频通知.

  • 比如你的微博关注有人发了新的 PO, 程序不得到用户的隐私数据, 怎么知道你关注了谁? 不知道你关注了谁, 就没法给你发有关你关注的人的新 PO 通知.

  • 再比如, 你经常在一些社区和论坛讨论聊天, 总是有人给你发站内信, 程序不得到用户的隐私数据, 怎么知道你还有几条新的未读站内信? 没有以你的帐户登录, 就没法发有关你的未读站内信的通知.

IFTTT 和(将来的)即刻可以解决上面的前两种情况, 却很难解决第三种情况, 因为他们的服务是基于友好的互帮互助的 OAuth 身份授权为基础实现的, 如果目标网站对你不友好(确切的说, 是没必要给你实现), 不提供 OAuth 授权和 API 服务, 这两种服务就没辙.

所以当初思考该如何解决这种问题, 最后我得出的结果就是应该把程序直接做成浏览器扩展, 这是最好的解决方法了, 为什么? 因为浏览器扩展能直接读取你的网站 Cookie —— 迄今为止, 绝大多数网站还是在用 Cookie 作为身份验证标志, Gloria 上线后几个月的使用反馈, 也确实证明了这一点. 现在移动 APP 大行其道, 可 APP 再强, 也无法让移动互联网脱离 Web 存在, 其中的原因也很简单 —— 浏览器是真正的互联网的入口, 现在的移动互联网由于性能和操作体验方面的局限性, 在重演过去 PC 端 B/S 与 C/S 同时盛行的局面(这一局面在 PC 上最终以 C/S 的衰弱落下帷幕): 最后, 只有游戏和重客户端应用会继续存在, 其他的都会被 Web 技术血洗, 而游戏和重客户端应用是不存在什么通知程序需要的身份验证信息的 —— 这些应用自己就会实现通知功能了.

大概 2 个月前, 我也在想怎么把 Gloria 的任务代码移植到服务器上, 这样浏览器的负担就不会显得这么重(因为没有对任务进行分片处理, 所以会出现瞬间的 CPU 高峰, 影响用户体验), 对于那些公开于互联网, 不需要用户隐私数据的任务代码, 我还是想把它们交给服务器统一抓取处理的, 但最后还是以失败告终, 原因在于 Node.js 竟然没有一个可靠无痛的多线程 Worker 实现.

也许, 一切都还任重道远.