ActivityPub-enabled forum.
https://github.com/commune-project/commune-server
https://github.com/commune-project/commune
// 待补充
用户可创建或加入社区，一个社区包含多个分类。
帖子属于用户（类似说说）或者分类。主题以“第一帖”的形式存储和展现。
无。
啊 是要放弃Discourse吗？
基于什么（
如果是nodejs咱也许可以提供十万分之一的帮助（倒
羡慕misaka大佬
好耶（感觉现在的经常查不到emm）
暂时 Golang。
但以御坂的习惯，大概随时放弃重写。
（才不会说今天早上在看 Rust 的 actix-web, tokio 和 diesel
好耶Golang！
Discourse太费资源了……
假装自己会写的样子……
我是大傻子
两个月快到了，连技术栈都确定不下来……
摸摸脑壳
所以，为什么一定要执着于自己造轮子呢？
核心问题还是 Discourse 并不支持 Content 和 Permission 的正交管理
其他诸如 审核机制 等都可以有 workaround
另: ActivityPub(Linked-JSON) 并不适合组织 forum 类内容
我不太了解这些，可不可以用…更简单易懂一点的表达方式？我对技术完全不懂。
(其实我也不明白 misaka 为什么对 AP 这么执着((
私以为 Discourse 没有适当的"权限"概念 所以只好自己造了(
我是觉得以现在（未来一两年、两三年内）的基础和需求来说，Limelight完全没有非常复杂的权限控制的需求，里区问题的拖延，更多是在社区管理人员在当前社区的管理结构并不能满足需求的情况下，并没有进行这方面的改善。
造新轮子，不管是造成贴吧还是造成另类SNS，我觉得且不谈这样的轮子造好之后现在社区面对的问题是否就都迎刃而解，Limelight显然是完全没有这样程度的开发能力的。
说的更那个一点，自己造轮子的，有哪个活下来的？
https://itsfoss.com/open-source-forum-software/
(果然还是我太挑剔了…
御坂不舍得放弃一些东西。
比如，要是非要 Mastodon 和 Discourse 整合，如果不要 AP 那就需要牺牲所有的 federated 内容。
可是整合有什么用呢？如果 Mastodon 实例没什么人用，那直接跑路不就好了。星站的活跃用户不知道比跑路站多到哪里去呢，说关就关……
其实就是赶鸭子上架的问题，跑路站根本就没有一个能胜任站长的人（曾经有，但头衔不是站长）——如果有，那也不会在管理团队里。
事实上 limelight 是非常畸形的管理模式，因为管理团队在任意方面的能力都弱于用户，又没有选拔机制。
那么为什么不考虑讨论、建立这样的选拔机制，以及考虑其他的，让用户可以不作为管理团队的一员，同样能给社区的管理提供帮助的方法呢？
之前半路搁浅的那个思路，即邀请一部分活跃用户作为类似于"议员、民意代表"的方式是可行的。虽然众所周知民主基本就别提什么效率，但是这可以作为一个类似于预备版主、管理员池来使用。毕竟，得处囊中，乃颖脱而出。
那个方案里，对于社区本身的各种比较重要的决定，还都是依赖于社区管理者的。用户组织也好，顾问也好，在需要决策的问题上也就只是给管理者一个参考和支撑，还称不上民主。在事实上，这样体量的社区也并不需要形式上的民主，只是需要沟通、讨论的渠道和空间。
至于吸纳管理者的渠道以及储备，这是考虑的一部分，同时还要考虑的是，让没有时间没有精力去像管理员、版主一样完全投入到社区中的人，一样有方式能够参与到对这个社区的维护中来。而不是像现在这样，或者是干看着，或者是不堪重负。
如果用户能够充分的以自己的能力限度参与到社区的管理中来，我想这样的话社区的管理问题，给管理员的压力也就没有现在这么重了。这样，对管理者的能力需要也可以相应的放松，各方面就都没有现在这么紧张了。