JavaScript 是最受欢迎的语言。

这个 “最受欢迎” 大概应该是 “最流行” 的意思，判断基准貌似是 “过去 12 个月使用过”。但必须考虑的是，前端很可能是不得不用 js，而不是在许多选择中凭喜好选择了 js 。

看了 balthild 的文章，问题是比较多，逻辑非常混乱。

睡原始的木板床时，仰卧后背紧贴床板睡觉，有时可以感到床都在动。

@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 的不足之后，有兴趣去做出更优秀的产品出来。

@Yohann97 确实，我正在想怎么弄，打算还是要改进一下。

如果文件不多，定期备份到 OSS 就蛮好的，OSS 有多副本。我自己不信任云服务商，所以自己做本地备份，备份到另一个硬盘，定期校验 hash 。

@wdssmq 谢谢反馈！已修复。

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

而对于原本已经有服务器或网站的人来说，只要把 json 文件往 public 文件夹一丢就可以了，比 Secure Scuttlebutt 简单很多。

@AX5N 是否社交倒不是重点，比如独立博客，也不是社交平台，很多人写博客，也知道大概率不会有很多读者。而 ipelago 在这方面已经比独立博客有所增强，可以批量订阅。另外，其实我还不希望社交属性太强，至少在早期希望若化社交特性。我主要是想提供多一个发布消息的渠道的选择。

@madlifer 我考虑过互动功能，比如，假设我的岛名字为 abc，别人发言时直接 @abc 即可。然后在客户端对包含 @abc 的消息特殊处理一下就可以了（比如专门做一个包含字符串 "@abc" 的消息的列表）。

但目前我没有实现这个功能，主要是想到频繁互动并不适合 iPelago，而且现在网上讨论的氛围并不好，我在想也许可以削弱互动功能，因此暂时保留这个功能，没做想好具体怎么实现，等待更好的想法。

@lumotian 你提醒了我，可以做一个 RSS to iPelago 转换器，这个要是做出来，也许可以直接订阅 RSS 源。

@madlifer 用户发布的是一个 json 文件，需要手动上传到 github 之类的地方（目前我提供了六个平台的上传教程），因此博主不需要自己拥有服务器。

订阅者从 ipelago.org 或其他渠道获取小岛地址列表（就是一堆网址），然后 ipelago 客户端可以从这些网址直接拉取最新消息（博文）。

简单来说，就是和 RSS 几乎一样的玩法。

@xgfan 考虑到读者范围包括完全不懂编程技术的人，所以我无法直接简单地使用 json 、cdn/github 、markdown 这些单词。

不能用 markdown 和 html，因为我希望做到四点：1.可订阅 2.最大限度地方便编程开发 3.尽可能利用各种免费服务 4.最大限度节省资源

而使用 markdown 和 html 是违背这四个优点的。

@woctordho 不冲突的，RSS 阅读器已经有很多人去做了，优秀的阅读器也有啊。

RSS 更注重订阅多一点，在发布消息方面还是比较复杂的。从发言者的角度看，iPelago 的适应性比 RSS 更强一点，只要可以输出 json 文件或 js 文件就可以发布消息。

@wms 非常期待。

不管哪个平台、哪个网站，我都看到不少人抱怨被禁言、被封号，因此才做了这个东西，告诉大家这里有不禁言、不封号的发布消息方法，至少多一个选择。

@roiding 不是取代，RSS 、独立博客、长毛象各有各的好处，iPelago 也只是提供多一个选择。在技术上可以非常轻松做到自动订阅，但我不希望形成任何形式的中心，所以才不得不让用户自行订阅。

@lumotian 对，与个人网站一样，独立的个人网站、独立博客本来就是最去中心的形式。但搭网站难度稍大一些，而且网站本身没有 “订阅” 的特性。而通过 iPelago 发布消息，去中心化的效果与独立网站一样，但难度低，可订阅，消耗资源极少。

@cicaday 把它看作一种 RSS 就很好理解了，发布者提供一个可公开访问的文件，订阅者通过向客户端添加网址来订阅。从订阅者的角度看，与订阅 RSS 几乎一样。

从发布者的角度看，比发布 RSS 更容易一些（如果不考虑 RSS 有很多现成插件的话）。

从开发者的角度看，开发一个 ipelago 客户端应该也比较简单，因为只需要处理一个结构极度简单的 json 文件。

@myqoo 这个我一时半会儿想不到解决办法，因为希望彻底没有任何中心，这就很难提供网页在线版。chrome 插件也许可以，我研究一下。

@madlifer 这个其实与 RSS 非常类似，需要用客户端订阅，可订阅的小岛地址列表在这里 https://www.ipelago.org/islands

@shpkng 多谢提醒，不知道为啥挂了… 已恢复