Reading view

There are new articles available, click to refresh the page.

“网络读书会” 的一些思路和方案

想弄一个长期的、朋友们一起读书的小组。大家对书中的文字,进行高亮或评论,并且围绕评论进一步讨论。

对于读书平台而言,这应该是很容易实现的功能。很多平台都有类似的功能:Amazon、微信……但并没有真正形成规模。原因很简单:首先,参加讨论的每个人,都先要在那个平台上买书。这就会涉及到金钱上的压力;大家也不想被平台渐渐捆绑住;以及,如果讨论的内容敏感,在某些平台,是很危险的事。

于是,有什么方法,可以不依托于大的平台,就能实现读书会的功能?以及,无须讳言,很多时候大家读的都是盗版电子书,读盗版是否也可以享受一起读书的乐趣?

虽然我们想要构建一个公开的、适合更多人的平台,但最终并没有特别完美的方案。考虑到的很多方案,其实更适合少数人的内部读书活动;所以,在这里把这些思路介绍一二,如果大家觉得合适,可以自行去拉小群,不用管我们 ^^


需要考虑的问题

  • 读书会的规模。人数的多少,彼此是否熟识。其相应的方案,会有很大不同,后面详细讲;
  • 私密性:是否需要匿名?是否能够匿名?
  • 小组的准入机制、成员管理、对评论的管理;
  • 是否会构成对盗版书的传播?如何把握其中程度?会不会因此导致使用的平台被举报?
  • 书评和讨论的内容,能否长期留存?能否导出?平台崩了能否迁移?
  • 如何应对恶意攻击?
  • 是否要依赖 vps 自建?或者其它技术门槛?
  • 能否跨平台:电脑、手机、平板……
  • 是否要翻墙?

不同的人数规模

  1. 小圈子,互相熟识
    • Google Doc 基本就够用了
  2. 中等规模,会通过邀请链接,加入陌生网友,内容不向小组外公开
    • 准入机制
    • 成员管理
    • 成员之间的身份如何保密?
  3. 大规模,不需要准入机制,任何人都能评论
    • 如何应对恶意攻击、垃圾评论?
    • 管理员的身份如何保密?
    • 书籍内容如何恰当地发布?

书如何生成?

首先,目前的各种方案,只适用于文本编码形式的书;对扫描版的书做评论要复杂很多,暂时不考虑。

大多数书以 .epub 的形式被获取,在不同方案中,被转换成 .pdf .docx .html 的形式。用 Calibre 可以很容易把 .epub 转换成 .docx 和 .pdf,后者需要事先考虑页面大小、字体、边距……以方便多数人的阅读习惯。

生成的 .docx 可以直接导入 Google Doc 之类的在线文档;导入 wordpress 的话,可以使用 Mammoth .docx converter 之类的插件。

使用 pandoc 可以从 .docx 生成很清爽的 .html 主体,比用各种 Word 软件转换好,也比用 pandoc 直接从 .epub 转 .html 好。


目前的三种方案

方案 1. Google Docs

演示页面

使用 Google Docs 的「建议编辑」模式(View – Mode – Suggesting),就可以把文章变成可以让协作者随意高亮评论的模式。可以只邀请指定的人编辑;也可以让任何人通过文章链接,成为 Commenter。

  • 适合小圈子,人多了存在误操作和恶意攻击的风险;
  • 允许匿名评论;
  • 可以把带评论的文档导出到本地。

有类似功能的协作编辑平台有很多,CryptPad 也很推荐。国内也有很多这种平台,但如果评论的内容比较敏感,还需要谨慎使用。

方案 2. hypothes.is

hypothes.is 是一个,小组内部一起阅读讨论学术文献的网站,用户需要注册账号,在 chrome 浏览器安装插件后,可以对任何网页或 PDF 进行评论和讨论。

  • PDF 的演示】,需要安装 chrome 插件 才能看到评论;
    • PDF 的亮点在于,是通过文件本身的 id,在 hypothes.is 系统中定位的。于是,即使 pdf 所在的网址改变,甚至把 pdf 存到本地再拖进浏览器,都可以进行评论同步;
  • 网页版的演示】,手动嵌入 js 文件,可以不用专门安装浏览器插件。

评论的可见性,有三种模式:

  • private,仅自己可见;
  • public,公开可见,——注意,这里不仅仅指评论本身公开,而且,任何人点进你的用户页面,可以看到你都在哪些网页留下了公开评论;
  • group,只有通过邀请链接加入小组的用户,才能看到并参与评论。但是,这个小组功能做的很简陋,作为社交网络的话,缺乏很多基本功能:
    • 组长没有任何权限,不能踢人,不能删评论,不能解散小组;
    • 邀请链接是唯一的,不能更改,——也就是说,任何知道这个链接的人,都可以进来胡乱留言,大家无法强制他离开;大概也没有举报封号机制;
    • 用户不能把自己的评论,批量挪到另一个小组,或改变公开状态。

这个小组功能,抵抗恶意骚扰的能力几乎为零。虽然项目组说未来会改进,但目前更适合,只在中小规模内部交流。不过,私下使用的话,这个小组功能不仅限于读书,同好们建个小组,日常对任何新闻网页都能一起吐槽 ^^

其它的优点:

  • 很多工具配合;
  • 评论可以导出,甚至可以自动同步到 Obsidian;
  • 目前不需要翻墙;
  • 有自建 hypothes.is 的可行性(还没认真研究);

缺点:

  • 小组邀请链接一旦泄露,后果可能很惨;
  • 无法匿名评论,必须注册 hypothes.is 账号;
  • 目前 pdf 的评论功能还有些问题,无法在各自的用户界面显示文件标题,文件多了会非常乱(这是新出现的 bug,也许很快就会好);
  • 如果原始 url 消失了,就无法再在原文中查看评论(甚至之前的评论,也无法删掉);
  • 可能还是需要自建 Web Server 来配合,或者免费 S3 文件服务器也可以?

方案 3. WordPress + CommentPress 插件

虽然 WordPress 和大部分网站一样,只能在文章下方集中评论;但仍然有人做了 CommentPress 插件,把评论和文章内容关联。插件分支出几个版本,目前最靠谱的是 Github 上的 CommentPress Core

演示网站】,——专门临时架了一个 wordpress,但以后可能会关掉,所以在这儿留一张截图吧。

感觉 wordpress 更适合大规模,完全公开的读书交流方式,但还有很多需要进一步思考完善的地方。当然,中小规模内部用 wordpress 也可以,但相对而言 hypothes.is 更好用一些?

优点:

  • 可以匿名评论,——评论者需要填写 id 和 email,假的也可以,虽然后台也可以设成不要 email,但这样会更难阻挡垃圾留言;
  • 可以使用文章密码,控制书籍内容是否对外可见,防止被不恰当传播;
  • 数据完全自主掌握;

缺点:

  • 页面效果难看……只能使用 CommentPress 自带的 wordpress 主题,虽然有三种,但都不好看。也许 css 高手修改一下会好些?
  • 只能把评论定位到所在的段落,并不能够高亮显示选中的文字,只好在评论区手动引用;
  • 如何防止恶意攻击?Wordpress 防垃圾留言很弱的;当然也可以小范围改成注册用户才能留言;
  • 需要自建服务器配合(官网免费 wordpress 不支持插件)。

苟日新

突然被人跑来问,是怎么做到写博客坚持这么久的,而且可以持续输出?

(荣幸地,拿起话筒:)啊,我不觉得我这个样子,叫做「持续输出」啦。早就连每月一更都不能保证了,而且那些技术相关的帖子,在我心里都不能算是「更新博客」的,用这些凑数也为我自己所不齿……

但我看到这个问题时,首先想到的,一个很重要的因素:大概是因为,这个站就一直在这儿吧~ 我的技术能力,不需要花什么额外的精力,就能让这个 blog 一直存活下去。于是,想写东西的时候,这里始终有个地方,可以让我写。

——也有很多时期,是完全写不下去的,长时期没法去面对、去反刍自己的生活;然而也没必要因此而关站,就让 blog 存活在那里,终归是个表述的出口。大概是因为,我也是希望,自己能够从那些「无法整理自己」的状态中,渐渐走出来,回复到可以写东西的状态吧。所以站点的持续存在,满重要的,因为确实能感觉到,想写点什么的时候,如果没有这么个站,又或者需要自己重新架一个,可能也就不写了……


这种「随时可以在站点写东西」的状态,也影响着对 blog 平台的选择(怎么又拐到技术贴去了?好吧,之前也一直想吐槽这方面,就顺带提一下)。这些年一直有 〖wordpress vs 各种静态博客〗哪个更好的争论。双方确实各有利弊。总体来说,静态博客最大的优点就是……省钱,可以薅 github、vercel 之类托管网站的羊毛。但另一方面,静态博客每次发布、或者修改一篇文章的过程,其实满折腾的。通常情况下,它需要

  • 一台固定的电脑,安装静态博客编译程序,并且从这台电脑发布到 github 的专门权限。而不是随便打开一台电脑或手机,从浏览器就能编辑发文;
  • 每次发文时的一系列专门操作。

我不乏看到有人,好久没有更新,突然想写一篇文章时,忘了怎么操作,翻出攻略来重温一遍;甚至忘了连接 github 的 ssh-key……可能别人觉得这样的折腾无所谓,或者自我管理优秀的话,不会出现这种情况。但我个人觉得,这是会在主观上,影响发文章的状态的。所以,随便在任何地方任何电脑上都能直观地发文,感觉还是蛮重要的。

好像也是可以通过一系列操作,实现用浏览器某个网站上编辑文章,然后自动编译发布到托管网站的。我没有仔细去关注。但是,如果把 blog 的生命周期,放到 5~10 年这个尺度上,那么这些网站之间的复杂依赖关系,很大程度上是不靠谱的。譬如我已经看到好几个静态 blog 的外挂评论系统,不知为什么不工作了……总之,相比之下,我可能更宁愿去使用那些免费带广告的 blog 平台。

我对写 blog 的新人的推荐,一直是——

  • 如果有技术能力、也有服务器的话,自建 wordpress;
  • 或者找人蹭一个。如果我们比较熟,你可以去买个域名,把 blog 挂在我的服务器上。这并不是很大的负担。(ps,个人 wordpress 小站,是可以不必安装开销很大的 mysql 数据库的);
  • 如果上面两条都不行,那么,我优先推荐去注册现成的 wordpress.com 或者 blogspot.com,目前看起来,长期靠谱的只有这两家了。虽然免费版界面不好看、还有广告,但长期写着应该没问题的;
  • 当然,我不会给乐于尝试静态博客的人泼冷水。但我会根据你的技术能力和气质,暗戳戳地担心:
    • 你能坚持写多久;
    • 你写出来的,会不会很多都是关于你怎么建站的经历和心得……

转一张,对于熟悉这十几年来 blog 平台变迁的人,应该会很搞笑:用不同工具写 blog 的人,(写 blog 文章)vs(写关于怎么配置 blog 的文章)的对比。右下角那些术语,都是在各个年代,需要各种不同程度的折腾的,静态 blog 方案:gatsby、org mode、jekyll、hugo、git workflow……


ps,两个月前,用这段代码方案,把我在 twitter 的所有 po 文,都导入到了自建的 mastodon 里。Twitter 那边,应该会随着 Elon Musk 的各种不靠谱折腾,渐渐放弃掉了吧。而每条推文的字数限制,从 twitter 的 140 字,变成 mastodon 的 500 字后,很多几百字的感受,要不要专门写到 blog 这边来,就比从前,更让人犹豫。具体怎么处理,我还没想好。

❌