#吐槽
设置 nostr.moe 的一整套, #Nostr 服务端是 0.5c0.5g 的 PaaS 即用即付, 客户端是纯前端的静态托管, 虽然那还在测试阶段, 但目前开销为 0, 不过未来估计也接近于 0. 媒体服务器是最大头, 但并不打算给人选择, nostr.build 已经是最好的了, 如果还要自定义的域名, 那还是请用户自己托管媒体服务器吧, 我自己设置个 OSS 才 5GB 对所有人用来说是太少了, 但如果每个人都自己设置一个, 那就是全都吃饱了.
快让我忘记了上次设置 Mastodon 前查看管理员经验贴后的惊恐, 发现 ActivityPub 就是一个巨型的 PCDN 社交网络, 不仅要存自己的还要存别人的, 还得收发, 数据库带着硬盘和 CPU 没日没夜地满载. 最近听一个朋友说, 单人实例都能快速吃掉了 5GB 的数据库, 最后还是放弃了. 这去中心化的社交何必如此昂贵?
Nostr 的中继确实没有要求互相通讯, 但实际上 strfry 这个最早的的 C++ 中继实现一开始就支持多个中继之间实时同步, 还能仅靠软件本身就组成小型中继集群. 即使如此, 只是用 WebSocket 传 JSON 的协议最终实现设计地再怎么烂也不会消耗掉如此多的资源.
最后还是用的 rnostr, 毕竟有使用经验, 也不需要额外的中继同步功能, 构建一个静态的二进制到处放一行命令就起来了, 导出数据也全是 JSON, 何必如此用 SQL 这种牛刀来杀鸡?
还因为 rnostr 自带全文搜索的 NIP, 虽然索引开销是有点太大了, 但是真方便. 离线了也能往电脑里面的本地中继发, 连上网再 REQ 出来广播出去.
如果真把 Nostr.moe 开放了, 在说明里最好还是多讲点丑话好了, 最终用户离底层协议太近了好像也不是什么好事.
via Nostr@cxplay
设置 nostr.moe 的一整套, #Nostr 服务端是 0.5c0.5g 的 PaaS 即用即付, 客户端是纯前端的静态托管, 虽然那还在测试阶段, 但目前开销为 0, 不过未来估计也接近于 0. 媒体服务器是最大头, 但并不打算给人选择, nostr.build 已经是最好的了, 如果还要自定义的域名, 那还是请用户自己托管媒体服务器吧, 我自己设置个 OSS 才 5GB 对所有人用来说是太少了, 但如果每个人都自己设置一个, 那就是全都吃饱了.
快让我忘记了上次设置 Mastodon 前查看管理员经验贴后的惊恐, 发现 ActivityPub 就是一个巨型的 PCDN 社交网络, 不仅要存自己的还要存别人的, 还得收发, 数据库带着硬盘和 CPU 没日没夜地满载. 最近听一个朋友说, 单人实例都能快速吃掉了 5GB 的数据库, 最后还是放弃了. 这去中心化的社交何必如此昂贵?
Nostr 的中继确实没有要求互相通讯, 但实际上 strfry 这个最早的的 C++ 中继实现一开始就支持多个中继之间实时同步, 还能仅靠软件本身就组成小型中继集群. 即使如此, 只是用 WebSocket 传 JSON 的协议最终实现设计地再怎么烂也不会消耗掉如此多的资源.
最后还是用的 rnostr, 毕竟有使用经验, 也不需要额外的中继同步功能, 构建一个静态的二进制到处放一行命令就起来了, 导出数据也全是 JSON, 何必如此用 SQL 这种牛刀来杀鸡?
还因为 rnostr 自带全文搜索的 NIP, 虽然索引开销是有点太大了, 但是真方便. 离线了也能往电脑里面的本地中继发, 连上网再 REQ 出来广播出去.
如果真把 Nostr.moe 开放了, 在说明里最好还是多讲点丑话好了, 最终用户离底层协议太近了好像也不是什么好事.
via Nostr@cxplay
