Nostr NIPs 现在好多内容啊, 短期想完全吃透好难...
要是有个 Nostr NIPs Lite 就好了QAQ, 协议核心只有基础功能, 无关内容全部放在 NUDs 上面
可惜, Nostr 这只弓箭已经射出去了...
Discussion
取决于你想做什么类型的应用，很难说哪些是核心功能，真要说的话可能只有 NIP01 是基础了，需要加什么功能再去搜看看有没有存在的方案就好
客户端开发者是这样的, 但是中继开发者要考虑的事情就很多了QAQ (
中继相关的 NIP 更少吧，只需要支持这三个 01、09、11、70 就已经足够完整了
四个* 😂
其实只实现 01 也足够了，难点还是在怎么应对各种奇怪的 filter，我用 pg 折腾了大半年放弃了，技术路线选错了，有些查询根本优化不了
PG Kind 和 Pubkey 直接 Btree Index 用 "kind = ANY([1, 2, 3])", Tags 单独拆分一列把 tags 的下标 0 和 1 按照 "${0}:${1}" 拼接为数组写入然后走 GIN 倒排就行, 不过 PG 这类关系型的劣势是并发上不去...
我试过 Clickhouse 在我的机器上面也只有几千的并发...
我的索引没什么问题，性能比 gin 倒排要好得多，只是 pg 某些情况下不走我的索引😂 比如客户端发送几百个 authors 的 filter
不过用 pg 这类数据库存储 nostr 事件我感觉过于奢侈了:bili_fantastic:
素，所以我停掉了。nostr 这种应用场景，还是选能自己规划索引的 db 比较好
你要是有兴趣可以尝试 Key-Value + 放大写 (索引) 方案, 我目前基于这个方案使用 Golang + Badger 得到了不错的成绩QAQ
不过目前我觉得 NIP-50 才是中继实现最难的一步, 特别是中文.
英文可以用空格分词 word, 很简单就搞定了, 但是中文不用 jieba 类的分词引擎把每个字都当作一个 token 一句话的 token 量就爆炸了, 但是用了分词引擎写入速度又会被大大削弱...
写入速度不是太大的问题，搜索结果并不需要那么实时。搜索的问题是成本太高了，很难用爱发电
如果你用 rust 写的话，推荐一个分词器：https://github.com/meilisearch/charabia 组合了不同语言的主流分词器，用起来省事。也可以尝试用大模型的分词器搭配向量数据库做搜索
我就是看了 strfry 这些 key value 解决方案后放弃了我的项目哈哈，确实更优雅 😌 打不过加入了