概述
ActivityPub-enabled forum.
仓库
deprecated
功能描述
// 待补充
用户可创建或加入社区，一个社区包含多个分类。
帖子属于用户（类似说说）或者分类。主题以“第一帖”的形式存储和展现。
进度和计划
已完成
后端
- 程序框架
- 数据库 Migrations 化
前端
无。
进行中
后端
- 用户关注
- 发帖
TODO
- 2021年3月初提供可供用户在线测试的简易原型。（参考完成度：原 hitorino 初版审核系统）
- 咕咕了——2021-03-09
20 Likes
啊 是要放弃Discourse吗？
6 Likes
基于什么（
如果是nodejs咱也许可以提供十万分之一的帮助（倒
9 Likes
羡慕misaka大佬
8 Likes
资瓷（可是为什么要更换
8 Likes
好耶（感觉现在的经常查不到emm）
5 Likes
暂时 Golang。
但以御坂的习惯，大概随时放弃重写。
（才不会说今天早上在看 Rust 的 actix-web, tokio 和 diesel
10 Likes
好耶Golang！
Discourse太费资源了……
7 Likes
假装自己会写的样子……
5 Likes
我是大傻子
两个月快到了，连技术栈都确定不下来……
9 Likes
摸摸脑壳
6 Likes
之前觉得discourse体验很不错，还在想为什么要换掉。然而最近连着发现搜索、徽章、编辑匹配等地方有一车bug，转而支持赶快换成新社区引擎 
12 Likes
所以，为什么一定要执着于自己造轮子呢？
9 Likes
核心问题还是 Discourse 并不支持 Content 和 Permission 的正交管理
其他诸如 审核机制 等都可以有 workaround
另: ActivityPub(Linked-JSON) 并不适合组织 forum 类内容
1 Like
我不太了解这些，可不可以用…更简单易懂一点的表达方式？我对技术完全不懂。
1 Like
(其实我也不明白 misaka 为什么对 AP 这么执着((
私以为 Discourse 没有适当的"权限"概念 所以只好自己造了(
2 Likes
我是觉得以现在（未来一两年、两三年内）的基础和需求来说，Limelight完全没有非常复杂的权限控制的需求，里区问题的拖延，更多是在社区管理人员在当前社区的管理结构并不能满足需求的情况下，并没有进行这方面的改善。
造新轮子，不管是造成贴吧还是造成另类SNS，我觉得且不谈这样的轮子造好之后现在社区面对的问题是否就都迎刃而解，Limelight显然是完全没有这样程度的开发能力的。
说的更那个一点，自己造轮子的，有哪个活下来的？
2 Likes
(果然还是我太挑剔了…
御坂不舍得放弃一些东西。
比如，要是非要 Mastodon 和 Discourse 整合，如果不要 AP 那就需要牺牲所有的 federated 内容。
可是整合有什么用呢？如果 Mastodon 实例没什么人用，那直接跑路不就好了。星站的活跃用户不知道比跑路站多到哪里去呢，说关就关……
其实就是赶鸭子上架的问题，跑路站根本就没有一个能胜任站长的人（曾经有，但头衔不是站长）——如果有，那也不会在管理团队里。
事实上 limelight 是非常畸形的管理模式，因为管理团队在任意方面的能力都弱于用户，又没有选拔机制。
7 Likes
那么为什么不考虑讨论、建立这样的选拔机制，以及考虑其他的，让用户可以不作为管理团队的一员，同样能给社区的管理提供帮助的方法呢？
5 Likes