一个分布式、免费、免备案、易用、可订阅的消息分享方案

2021-07-28 11:41:39 +08:00
 SuperMild

大概两个月前,在 V 站看到这样一篇文章

RSS3:我们仍未知道那天所看见的花的名字 https://www.v2ex.com/t/781981

其中提出了回归互联网精神的愿景。确实,现在我们可以看到互联网有被割裂、变得封闭的迹象。我从前几年开始也断断续续思考如何为开放的互联网贡献一点微薄的力量。

我认为,RSS 、独立博客、长毛象等等,可以让普通人游离在各大平台之外发布消息的方案就属于“开放互联网”的一部分。而我需要做的,就是思考如何提供类似(并且在某些方面有优势)的方案,给大家提供多一个选择。

最终,做出了一个叫做 iPelago 群岛 的东西,完全没有中心(不像长毛象那样多中心),搭建难度比搭独立博客更容易,原理及标准比 RSS 简单得多,消耗资源极少,适应性很强(只要支持公开访问 json 文件或 js 文件就行)。

具体请看 https://github.com/ahui2016/ipelagohttps://ipelago.org

暂时虽然把这个东西做出来了,但目前没有用户、没有内容,也不知道该如何宣传,对于普通用户来说这套东西用起来也有点麻烦,因此可以预见发展非常困难、非常缓慢。

但我最最想做的只是给普通人提供多一个类似于独立博客那样不受中心平台管控的个人消息发布方案,如果真的没有人使用,我也理解,虽然无奈但没有遗憾(如果不做这个事情才会遗憾,做了就不遗憾了)。

3665 次点击
所在节点    分享创造
32 条回复
SuperMild
2021-07-28 15:11:12 +08:00
@lumotian 你提醒了我,可以做一个 RSS to iPelago 转换器,这个要是做出来,也许可以直接订阅 RSS 源。
madlifer
2021-07-28 15:58:20 +08:00
来个核心问题:文章评论互动怎么实现?
SuperMild
2021-07-28 16:27:02 +08:00
@madlifer 我考虑过互动功能,比如,假设我的岛名字为 abc,别人发言时直接 @abc 即可。然后在客户端对包含 @abc 的消息特殊处理一下就可以了(比如专门做一个包含字符串 "@abc" 的消息的列表)。

但目前我没有实现这个功能,主要是想到频繁互动并不适合 iPelago,而且现在网上讨论的氛围并不好,我在想也许可以削弱互动功能,因此暂时保留这个功能,没做想好具体怎么实现,等待更好的想法。
AX5N
2021-07-29 06:16:08 +08:00
说白了,楼主搞的玩意儿就是个 json 解析器(不是 parse 那个意思),你把想说的话写在 json 里,然后随便选个地盘把这个 json 发布过来,他这个 app 就帮你把这个 json 解析渲染出来,并且还能按时更新。其实就是 rss ( rss 就是个 xml 解析器)。

这种去中心化的东西根本就做不了社交,订阅者得一个一个作者去找,而社交平台不仅是一大片一大片推送给你,而且还有热度、推荐算法。禁言、封号都是社交才有的东西,这种没法社交的东西从根本上就和禁言、封号无缘,更别提解决禁言、封号的问题了。
SuperMild
2021-07-29 08:27:09 +08:00
@AX5N 是否社交倒不是重点,比如独立博客,也不是社交平台,很多人写博客,也知道大概率不会有很多读者。而 ipelago 在这方面已经比独立博客有所增强,可以批量订阅。另外,其实我还不希望社交属性太强,至少在早期希望若化社交特性。我主要是想提供多一个发布消息的渠道的选择。
wdssmq
2021-07-29 18:02:49 +08:00
简单说就是个「微博」形式的 RSS ??客户端我儿完全跑不起来。
然后「 Secure Scuttlebutt 」了解一下。。
SuperMild
2021-07-29 22:23:46 +08:00
@wdssmq 谢谢反馈!已修复。

你这个形容很好,简单来说就是个极度简化版的 RSS 。我去看了 Secure Scuttlebutt,那个对用户的要求更高,需要服务器,我选择 json 文件的原因是目前有很多免费服务商可以利用起来,用户不需要服务器。

而对于原本已经有服务器或网站的人来说,只要把 json 文件往 public 文件夹一丢就可以了,比 Secure Scuttlebutt 简单很多。
Yohann97
2021-07-30 09:38:21 +08:00
网页版的还要弄个服务器,做个浏览器插件用户体验可能更好一些
SuperMild
2021-07-30 09:41:44 +08:00
@Yohann97 确实,我正在想怎么弄,打算还是要改进一下。
wdssmq
2021-07-30 12:11:14 +08:00
@SuperMild #27 对于普通用户,并不需要服务器,,只是 Secure Scuttlebutt 专门出了服务器版作为 p2p 的补充。。也有专门的手机客户端:Manyverse

这东西的真正缺陷是「同一身份只能单一设备登录」+「同步慢」+「内容分叉」。

\--------

实际体验后修改下我 26 楼的回复:相当于用录音机录下自己的发言,然后通过土电话给别人听,还是单向的,要实现「交流」得拉两条;

以下简称楼主的设计为「 i 」设计;

\-----

- 依托一个「 http(s) 地址」对外发布信息;
- 且不说制作和维护这样一个地址本身就有一定难度了;
- 客户端的发布功能就是个「 JSON 生成器」,虽然可以走 API 接入各种 git 或 oss,然而 [不接受代码贡献] ;
- 「自己能用就行」和「让别人也能用上」概念是不一样的,为了去中心而去中心只会变成前者;
- 各种意义只能由程序员来成为核心用户的产品,然而已经成为程序员的人并没有特别的理由用它,并且其宣传路线还是不需要成为程序员就能简单上手;
- 当地址突发性发生改变时,你没办法通知别人,或仍然要借助其他渠道,另外这种方式还有一个不利的「固有性质」;

不管是不是程序员,对于更广泛的用户来说,这种设计相对微博类型的产品都缺少吸引力:

- 微博类社区的重点在于,它一般都有一个「广场」,大家各自都在碎碎念。如果对别人的发言感兴趣你也可回复或者关注,,当然也可以完全当作树洞自言自语。
- 对于「 i 」设计,用户并没有这个选择,只能以「自言自语」为前提;

- 然而即使作为树洞,它也是公开的,你天然的知道虽然可能没什么人回复,概率上总会有人能看到自己某条言论,然后内心吐槽两句,或者有点儿其他波动然后划到下一条,因为你看到别人的发言时也是这么做的,这种「对等」感是很重要的,虽然表现上是大家都各自对其他人「无感」。
- 另外这里的逻辑是「我看到了一条言论」进而才有「这是另一个人,另一个独立的存在」所作出的表达;
- 对于「 i 」设计,其「固有性质」是,用户需要先「知道有一个人的存在」然后通过「 TA 提供的发布地址」进而「看到 TA 的言论」;
- 所以,你不确定是根本没人看还是别人看到了只是不想回应,何况根本没有直接回应的设计;

- 「社区」的「社」字,其前提就是「聚群而居」,我曾经向某个心理咨询师介绍过长毛象,然后她联想到的是带孩子出去时,某个年龄段的孩子们会「聚集在一起」,然后「各自一个人玩」。
- 可能作为成年人的我们也有这种需要,而长毛象正好提供了;
- 「 i 」设计感觉像是,每个孩子在自己家玩,打听到谁家也有孩子,就通过窗口拉一条土电话,这个土电话还是单向的,要实现「交流」得拉两条;

- 「独立博客」虽然也同样需要先让别人知道自己存在,但是其优点足以弥补;
- 可以依靠搜索引擎收录;
- 「浏览器」就是「客户端」;
- 形式上相当于让人来看作品展览,觉得好看可以再来,或者 RSS 订阅;
- 类似的流程,我为什么要换到一个专门的客户端上,每条信息还限制 1 KB,也就是看你的短信息碎碎念;

\------

你想单纯看我的碎碎念又不想注册嘟特的话可以用 RSS 订阅下边地址:

https://wxw.moe/@wdssmq.rss

↑ 反正差不多意思。。RSS 更通用,客户端选择更多,甚至浏览器插件也有。好像 Chrome 现在又原生支持了;

作为接受方,你也不需要考虑我是不是通过一个中心化平台发布的;这个地址什么时候挂随缘;
SuperMild
2021-07-30 14:57:11 +08:00
@wdssmq 非常感谢如此详细的评论!

0. 关于交流: 土电话的比喻不太恰当, 因为 "i 设计" 不强调交流. 说是土电台发射站更贴切一点, 每个岛主对外广播, 而订阅者可以通过批量订阅来收听各个电台的广播.

1. 维护小岛地址:不需要维护。因为 "i 设计" 不强调固定身份, 每个岛都是临时岛, 一般情况下不需要知道岛主是谁. 只有当岛主提供了真实 email 和博客地址等联系方式, 并且订阅者对该岛主特别感兴趣时, 身份才重要, 而这种情况下就可以通过 email 和博客等渠道来提供新地址了.

2. 虽然不接受代码贡献, 但并不妨碍贡献, 想做改进的 fork 过去直接改就可以了, 与其等待我合并代码 (有时因为理念不一样还需要花时间讨论), 不如直接发布新版更方便.

2a. 对于没有服务器的人来说, 客户端的发布功能也只能是个 JSON 生成器了 (我想不到还可以怎样改进). 另外对于有服务器的用户, 我打算再做一个服务器版的客户端.

3. 单中心、多中心、彻底去中心,这几种选择各有利弊,Mastodon 选择了多中心, 是一个比较折中的选择, 兼顾了分散性和易用性. 而如果选择彻底去中心, 很多事情我想为用户做都做不到, 确实存在难用、操作流程复杂的问题。

但我不能选择多中心(多节点)啊,你想想,首先已经有多中心的产品了,我自问也没能力在这方面做出更优秀的产品。其次,多中心的路也不好走,我选择了无中心,你看到了无中心的各种缺点,但如果我选择多中心,你又会看到多中心的大难题:比如每个节点都必然需要高成本( CPU 资源、带宽流量等),每个节点还需要承担政策风险,被黑客攻击的风险,甚至可能还需要日常管理员(比如 Mastodon 的每个单例都需要管理员)。

4. 非程序员用户:iPelago 最大的目的、最大的愿望是给非程序员提供一个可以独立发声的方法。

对于非程序员来说,"一个可以独立发声的方法",最简单的应该就是静态博客了吧。而在 iPelago 建岛比搭一个静态博客更容易啊。并且,iPelago 还提供了批量订阅功能,不仅搭建容易,而且可以加入小岛列表方便别人订阅。

因此,理论上与静态博客相比,iPelago 还是有优点的(当然,静态博客也有别的优点)。

5. 对于非程序员来说,博客与 RSS 有阅读方面的优势,比如你提到的不需要客户端,可以通过搜索引擎发现博客,有现成的 RSS 阅读器等等。

但是发言难度呢?

从阅读体验的角度, iPelago 确实比博客与 RSS 差,但我最想做的是让非程序员可以更容易独立发言.

现在, iPelago 提供了一个独立发言的方法, 而这个方法的整个操作流程确实不需要任何技术知识, 并且难度比搭建静态博客更低, 后续还可以转化成静态博客.

我也希望有更好的 "发言" 方案, 但我想不出来.

我无法做一个完美的工具, 只能有所取舍, 我自己认为最重要的特性是: ①发言容易 ②可订阅 ③编程开发难度低这三点。

另外就是希望抛砖引玉,希望有程序员在看到 iPelago 的不足之后,有兴趣去做出更优秀的产品出来。
wdssmq
2021-07-30 17:12:25 +08:00
1 、完备的自主可控的站点,独立博客(含静态博客)之类的;

2 、别人提供的平台,注册就能用。。会发朋友圈就会用; ← 论容易你真打不过,而不是跟上边的比易用性,然而又没有其他真香的要点。。

一个五公斤的哑铃和一个一公斤的哑铃,然后折中出个 3.7 的。。

如果一个人觉得五公斤太重就放弃了,那么说明这样的人根本不需要更重的,一公斤的就足够了。。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/792232

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX