@
cifermail 感谢你的回复，下面我说说我的想法，如有不明白的，欢迎加群或 slack，然后进入我们的 trello 讨论组讨论。
1. 做这个的目的很简单，就是满足需求，这个项目本身不指望也不在乎盈利的，它是对现状不满的产物，即使我现在不做，只要需求还在，以后也会有其它人做。
要完成一切的功能，我一个人鼓捣几年绝无可能，而且现在的设想也只是头脑风暴而已，理论和实际上都不可能全部实现，仔细看看就会发现，光是需求之间就有矛盾。我的打算是先出一个精要的版本，作为内测版本，此版本首先解决的核心需求就是：a. 创造的同时博客间社交的需求 b. 多客户端的优质书写体验的需求 c. 数据安全、数据同步的需求 。这些需求实际上各有现成的实现，甚至可以和已有的服务对接，因此在这一阶段，工作量并不算大，也就是几个月的事情。
2. 后端如果让用户自己写的话，是不是对用户会有一点要求？
这个项目的纽带其实在于 API，它更像是一个规范。我们打算用门槛最低的 php + sqlite 作为官方示例后端。而有能力的开发者，也可以用 go，nodejs，python 等等实现。（不过说实话，这里存在大量有待进一步考虑的问题）。用户的行为是这样的：域名和主机的绑定->上传程序->打开安装页面->设置管理员账号密码->安装完毕。对于官方后端，可以保证安装的便捷性。而对其它语言的后端，我们无法左右开发者的选择。至于 restful 的问题，其实现在还没有拿定主意，选择 Restful，Graphql 或者传统的 service.Action （ rpc ），各有优劣都有可能。GraphQL 的话后端用 nodejs 写会更好，但目前决定用 php，个人更偏好 rest 是因为 rest 比较成熟，工具也多（指 php 上）
3. 这些属于前端插件，是否实现，如何实现取决于前端工程师。统一用现成的 js 库是最快的方法。我们的能力做不到连这个都造轮子。官方前端的话，自然会选现有库。
4. 代码高亮这种自然也是丢给前端和用户去选择。官方前端的话，自然会选现有库。
5. 仍然是前端的事情。到时候应该会有各种编辑器的插件可供选择。由于前后分离，切换起来非常方便。
6. 博客互联并不是强制的。站长同意接入之后，先注册一个账号，验证所有权，互相分配密钥，就可以接进来了。
7. SEO 本质上就是输出 HTML 的问题，正文部分用后置解析器解析为 HTML，然后统一一个输出格式就行。比如 discuz archiver，收录效果就比较好。当然，服务端渲染也是一个选择，但不是一个好的选择。
8. 有插件机制。模块是可拆解的，你可以做出庞然大物，也可以做得小巧。这取决于用户，我们会提供灵活度。
9. 这个问题我已经详细回答过了，不重复了。