Why Nostr? What is Njump?
2025-04-03 11:33:43

CXPLAY on Nostr: 设置 nostr.moe 的一整套, #Nostr 服务端是 0.5c0.5g 的 PaaS 即用即付, ...

设置 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 开放了, 在说明里最好还是多讲点丑话好了, 最终用户离底层协议太近了好像也不是什么好事.
Author Public Key
npub1gd8e0xfkylc7v8c5a6hkpj4gelwwcy99jt90lqjseqjj2t253s2s6ch58h