卧槽，赞！

@jamesliu96
要是想做Worker调用DOM的话，可以考虑参考CommentCoreLibrary代码弹幕支持的部分。代码在Worker沙箱里面跑，伪造一个底层API发送绘图命令到DOM前端绘制。
http://jabbany.github.io/CommentCoreLibrary/demo/scripting/ccl.htm

目前大部分代码弹幕还都是在用性能不是很好的SVG绘图，不知道canvas会如何。

CommentCoreLibrary开发者路过，说一下个人看法：

首先这个想法很好，毕竟现在版权视频多了，像以前B站那样一站式的简单弹幕服务越来越难找到了。要么投身下载党放弃弹幕，要么就忍受服务商的纠结（以及海外IP限制）。总之*高度整合*的平台越来越少了。

不过现阶段设计让这个系统绑在分布式协议上，我觉得对其前景有所限制。很多地方（公司学校海外）对BT等分布式协议限制的比较严，绑定到哈希值上感觉不是很好的方案。另外若干不同的视频可能都希望挂同一个/一些弹幕流，把弹幕这样分散至和文件绑定的话，势必会不天然的增加弹幕转流成本。

回过头来，我觉得现在最缺乏的是高度整合的一套弹幕解决方案来解决这些问题：

- 给一个视频怎么判定这个视频所拥有的弹幕和弹幕池，怎么获得它们并显示出来
- 如何有效的实现视频源，视频源Meta信息的非依赖性（可简单的换视频源）
- 如何有效的实现弹幕源，弹幕Meta信息的非依赖性（可简单的换弹幕源）
- 把界面和跨平台做好

比起一个分布式的弹幕机制，我觉得应该着手与一种抗打击的元数据目录和可拆卸的格式上的兼容性插件。至于弹幕，我觉得比起分散化，拆分为小型“频道”，用户通过目录订阅的方式可能会更有效的控制弹幕质量。比起零散的小弹幕服务器或者巨大的弹幕Hash（类似Bitcoin中每个节点都保存几乎所有的交易记录），一些小的，低能但是专业的服务器会好很多（考虑Hentai@Home）。

这个模式和E-Hentai的运营类似。

-----
作为另一个思路的参考，CCL的一个弹幕“Tracker”实现：
https://github.com/OpenDanmakuConsortium/akagi

设计思想就是服务器纯粹负责Meta信息，用户可以自由建立“弹幕池”，池内可以保存弹幕。（类比E-Hentai的Gallery）

这些“弹幕池”有任意自带的Meta信息，同时弹幕池之间的联系通过Tag建立。Tag是由建立弹幕池的用户（类似UP主）自选的，但是也可以被其他的用户添加和 vote tag。这样可以在一定程度上通过社区控制弹幕池本身的质量，某个池的某个 tag 被vote高，搜索那个tag的时候就会出现的靠前。tag 被 vote的低这个tag搜索里面出现这个池就会靠后。（类比E-Hentai的Tag）

使用的时候用户通过tag搜索到被标这个tag的弹幕池，tag可能范tag（“新番”，“自制”，“自Host”，“舰娘系列”等等广义不能定位视频的tag）或者准tag（“[XXX字幕组][XXX]YYYYY”，”sha1=xxxxxxxxx...“，“magnet:?xxx”，“http://xxxxxxx”）。这样用户既可以通过TAG搜资源和弹幕，也可以通过资源搜弹幕。甚至可以通过资源搜资源。

播放视频的时候，客户端可以在用户的指导或自主搜索下选择一些弹幕池来订阅。用户可以屏蔽单弹幕或者一个弹幕池或者一个弹幕池作者。用户也可以屏蔽Tag，比如某些tag出现了/评分达到某个值了，就不选取弹幕池（或者只有某些Tag达到数值才选弹幕池）。

用户还可以选择一个或多个弹幕池发送弹幕，客户端在合并弹幕池的时候自然会处理冗余弹幕。不过实操中只要选一个池就OK了。由于只存储meta信息，不但信息流小，总数据量也不大，加之协议兼容性的话，可以放置若干这种目录服务器（Tracker），客户端订阅几个就可以访问绝大多数资源的绝大多数弹幕。

全实现只要K-V数据库就可。

至于服务器成本，应该可以在免费的云服务上搭建。同时可以继续学E-Hentai，比如限制用户的搜索频率，搜索结果数量，让日常绝大多数使用都免费，但是爬资源肯定会撞墙，高频搜索的话超过Quota要花积分。可以对用户的Tag能力做一些优化，类似Stackoverflow的Reputation/Karma策略，甚至是V2EX积分策略。万一服务器运营不下去倒台，导出数据也灰常简单。
------

以上。供参考。

当然最重要的还是作好一个客户端。参考 DanDanPlay

太机智了.......

先 stash 一下？

OpenVZ的话。。。这个价格。。。也算正常吧
（但是为啥站点不说虚拟化技术或者内核版本呢 >___> 明明很关键的）

可以参考一下：https://github.com/silentmatt/js-expression-eval
安全的代替EVAL，可以自己定义运算符号和函数

简单网站的话，WordPress基本足够了。模板在WP官网能找到，国内也有不少模板站（虽然需要翻一阵子才能找到比较好的模板）。模板之类的看需求，比如展示的话，WP-Creativix个人感觉还行。绝对是属于超简单操作的。

还可以考虑用Drupal，不过这个比WP难配置一些，功能上更丰富。装好相应的插件的话，管理也还算简单。。。

@TheC 因为感觉这两个合起来才是一个比较有前途的发展方向。
Bangumi作为社区本身对资源的依赖度不强（自己不提供视频，必须转到外站观看，主攻社交和数据情报的整合[当然Bangumi现在比之前在资源上做的好多了]）
反过来B站没有社区功能，更多的是一个视频和弹幕的“数据库”，而这不能满足很多观看需求（特别是B站的很多视频之间有连续性或内在关系）。

Bili这次改版就在往功能上趋同的方向在移动，增设的专辑和对关键词的重视（虽然还很BUG）已经开始对繁多的数据进行*关联*与*整理*，定位已经不是单纯的视频站点了。从某种意义上说，B站的改版对于本身就是面向数据关系（观看进度、评价、社交）的整理的Bangumi来说，是一种挑战。

至于为什么很多人把B站和Bangumi比，大概是因为这次改版让很多人看到B站的发展轨迹可能会在未来和Bangumi现在的目标有交点而已。

@Ariagle 各种专题条目的类似Wiki的东西，和各种社区动态。就差进度管理了......

还有，感觉主页右上的“热门视频”栏目左上角图标非常微妙。。。