最坏的结果……就是你能用这个账号做的事情（查看私信、清空账号…），你授权的网站理论上可能也都能做到。

我当然不是在质疑 NeoDB 啦，可能我过一会儿也弄个小号来玩了。只是说 fedi 的这个账号授权机制太吓人，不知用 dev token 能够细分权限，会不会好一些。或者，如果用户没有从 NeoDB 自动发消息到 fedi 的需求，是不是就不用 write 权限了？

确实是CloudFlare，但都是默认设置没有特意封任何地区。

@zyn 你这人到底什么情况啊？到处追着我造谣，我怎么说你也不会信。昨天你自己搞不清楚Github里已经完整的代码跑不起来非指控我没开源，跟你详细解释了你夹缠不清；今天又空穴来风说我封大陆IP。怎么就没完没了了？

> 今天又空穴来风说我封大陆IP

以下是我判断封了大陆ip的依据，任何人都可以很方便地复现。

检测前的预期：全新域名+cf cdn不太可能被墙，因为域名和ip都没有被针对。
检测的前提知识：cf的节点在墙外，墙只能干扰浏览器到cdn节点的这一段网络，不能干扰cdn节点到真实服务器的这段网络。如果墙内能正常连接到cf的cdn节点却无法访问网络，说明不是墙的原因而是服务器的原因。

具体检测：

先ping neodb.social ,发现可以ping通，而且是一个正确的cloudflare的ip。已经可以大致判断没有被墙了。
为了严谨起见，再用nmap扫描一下端口（万一墙只干扰tcp链接但是故意放过ICMP呢，虽然我想不通墙有什么动机这么干）。图一和图二分别是墙内ip和墙外ip的结果，可以看出tcp连接本身也是available的，说明不是墙的原因，墙内ip不可访问443和80端口不是因为墙而是因为服务器的本身的设置。
为了更直观地验证，访问https://neodb.social:8443（图三）。这是一个错误的端口，并不期望能正常使用，但是可以通过这个方法看到cloudflare的报错页面，再次验证浏览器到cloudflare的CDN节点这一段是畅通的，墙内ip不可访问和墙无关。

综上判断，墙内ip不可访问与墙无关，是服务器的主动封禁。

> 昨天你自己搞不清楚Github里已经完整的代码跑不起来非指控我没开源

希望停止这种真正的"造谣"和"混淆视听"。我从来没有说过没跑起来，不清楚为什么要三番两次立这种靶子。恰恰是因为当天就跑起来了（而且还修了bug完成了本地的授权登录），所以我才确认页脚提供的github链接和neodb.social实际运行的代码并不是同一份。

回顾我们的对话，我一开始是尽量友善地从用户视角提出使用中发现的问题希望完善（过度索权的问题、一边说没义务开源一边提供虚假github链接的问题），是谁在否认问题、阴阳怪气、被反驳以后又开始打滚呢。

一个新项目有各种不完善之处是很正常的，尤其NeoDB还是用本身就还算alpha的NiceDB修改的。但是维护者对问题的态度和修正速度，实在是令人更加担忧了。