#吐槽
Why are all the NIP-94 implementations server-side only, especially the NIP-96 server, and is it really only the server that can compute the metadata for a file? Why isn't this process done on the client side, and if I insert a random network memes does that mean I'll never be able to add the metadata that makes sense to the client (unless I consider writing event JSON manually)?
As far as I know, all the file metadata for the NIP-35 for Torrent indexing is client-supplied, and users can even fill it in themselves, but somehow it's become a server-only affair with the NIP-96.
#nostr #asknostr
via Nostr@cxplay
Why are all the NIP-94 implementations server-side only, especially the NIP-96 server, and is it really only the server that can compute the metadata for a file? Why isn't this process done on the client side, and if I insert a random network memes does that mean I'll never be able to add the metadata that makes sense to the client (unless I consider writing event JSON manually)?
As far as I know, all the file metadata for the NIP-35 for Torrent indexing is client-supplied, and users can even fill it in themselves, but somehow it's become a server-only affair with the NIP-96.
#nostr #asknostr
via Nostr@cxplay
#吐槽
第一篇写给新手的入门教程, 从密钥对创建到第一条帖子, 包含一些基础的密钥管理和 Nostr 协议常识.
欢迎加入 Nostr, 这是一份快速入门指南. | CXPLAY World
https://blog.cxplay.org/works/nostr-quick-start-guide/
#blog #Nostr
via Nostr@cxplay
第一篇写给新手的入门教程, 从密钥对创建到第一条帖子, 包含一些基础的密钥管理和 Nostr 协议常识.
欢迎加入 Nostr, 这是一份快速入门指南. | CXPLAY World
https://blog.cxplay.org/works/nostr-quick-start-guide/
#blog #Nostr
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
设置 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
#吐槽
In reply to nevent1q…utqt
_________________________
来用 nos.cx.ms, 其实就是我给 nostrudel.ninja 重新中文本地化后的版本.
via Nostr@cxplay
In reply to nevent1q…utqt
_________________________
来用 nos.cx.ms, 其实就是我给 nostrudel.ninja 重新中文本地化后的版本.
via Nostr@cxplay
#吐槽
In reply to nevent1q…73k0
_________________________
三大客户端的功能都已经接近完善了, 底层协议不变动也没什么要变动的, 保持维护就差不多行了, 没有问题为什么要更新呢.
Damus 那边在开发 Android 版本和桌面版本 Notedeck 版本.
via Nostr@cxplay
In reply to nevent1q…73k0
_________________________
三大客户端的功能都已经接近完善了, 底层协议不变动也没什么要变动的, 保持维护就差不多行了, 没有问题为什么要更新呢.
Damus 那边在开发 Android 版本和桌面版本 Notedeck 版本.
via Nostr@cxplay
#吐槽
Android 开源 #RSS 阅读器 Feeder 已经合并了 #Nostr Feed (NIP-23) 的代码.
https://github.com/spacecowboy/Feeder/commit/7fae5a36af86d24c93663173f10cb3ff57dee1a8
via Nostr@cxplay
Android 开源 #RSS 阅读器 Feeder 已经合并了 #Nostr Feed (NIP-23) 的代码.
https://github.com/spacecowboy/Feeder/commit/7fae5a36af86d24c93663173f10cb3ff57dee1a8
via Nostr@cxplay
#吐槽
刚刚在 #Bluesky 看到有人一口气关注了两万多个人, 叹为观止. 这种超大规模的订阅追随对目前的 #Nostr 来说几乎是不可能的, 因为每多一个追随就要多一个 filter 里面的标签, 刷新一次时间线就要有两万多个标签的 filter 发送到已经连接的中继器里面, 就算客户端做好了分割 filter 的功能, 两万个标签的 filter 请求也是随便就能让客户端和服务端超载的大小, 要么拒绝要么查询失败.
via Nostr@cxplay
刚刚在 #Bluesky 看到有人一口气关注了两万多个人, 叹为观止. 这种超大规模的订阅追随对目前的 #Nostr 来说几乎是不可能的, 因为每多一个追随就要多一个 filter 里面的标签, 刷新一次时间线就要有两万多个标签的 filter 发送到已经连接的中继器里面, 就算客户端做好了分割 filter 的功能, 两万个标签的 filter 请求也是随便就能让客户端和服务端超载的大小, 要么拒绝要么查询失败.
via Nostr@cxplay
#吐槽
In reply to nevent1q…z22s
_________________________
Nice. And maybe you need fix your NIP-05 addr's CORS issue:
https://cors-test.codehappy.dev/?url=https%3A%2F%2Flecturify.net%2F.well-known%2Fnostr.json%3Fname%3Dyonle&method=get
via Nostr@cxplay
In reply to nevent1q…z22s
_________________________
Nice. And maybe you need fix your NIP-05 addr's CORS issue:
https://cors-test.codehappy.dev/?url=https%3A%2F%2Flecturify.net%2F.well-known%2Fnostr.json%3Fname%3Dyonle&method=get
via Nostr@cxplay
#吐槽
Mostr.pub 和 Momostr.pink Bridge 继续被滥用:
Fediverse 和 Bluesky 之间的桥被用来向 Bluesky 发送支持特朗普的垃圾邮件, 这些垃圾邮件来自 Nostr. 垃圾邮件是在 Nostr 上创建的, 而 Nostr 通过 Mostr 桥接器与 fediverse 桥接, 后者又可以与 Bluesky 桥接. 虽然所有网络都有许多方便, 开放注册的地方, 但垃圾邮件往往发生在容易大量注册的地方, 而 Nostr 的协议设计使得创建新账户特别容易.
—— https://fediversereport.com/last-week-in-fediverse-ep-69/ (The Fediverse Report)
支持特朗普的垃圾帖子是如何从 Nostr 转移到 Bluesky 的? 首先, Nostr 内容通过 Mostr Bridge 传播到 Mastodon (基于 ActivityPub 协议). 然后, 使用名为 Bridgy Fed 的工具将内容从 Mastodon 推送到 Bluesky. 这一过程的痕迹出现在 Bluesky 版本的帖子中, 其中的账户柄格式为 npub************.momostr.pink.ap.brid.gy. 其中的第一部分(从 npub 到第一个点)是 Nostr 账户的公钥, 而其余部分(momostr.pink.ap.brid.gy)则包含了用于桥接帖子的工具(Mostr 和 Bridgy Fed)的一些说明.
—— https://conspirator0.substack.com/p/federation-and-political-spam (Conspirador Norteño)
#Nostr #Fediverse #Bluesky
via Nostr@cxplay
Mostr.pub 和 Momostr.pink Bridge 继续被滥用:
Fediverse 和 Bluesky 之间的桥被用来向 Bluesky 发送支持特朗普的垃圾邮件, 这些垃圾邮件来自 Nostr. 垃圾邮件是在 Nostr 上创建的, 而 Nostr 通过 Mostr 桥接器与 fediverse 桥接, 后者又可以与 Bluesky 桥接. 虽然所有网络都有许多方便, 开放注册的地方, 但垃圾邮件往往发生在容易大量注册的地方, 而 Nostr 的协议设计使得创建新账户特别容易.
—— https://fediversereport.com/last-week-in-fediverse-ep-69/ (The Fediverse Report)
支持特朗普的垃圾帖子是如何从 Nostr 转移到 Bluesky 的? 首先, Nostr 内容通过 Mostr Bridge 传播到 Mastodon (基于 ActivityPub 协议). 然后, 使用名为 Bridgy Fed 的工具将内容从 Mastodon 推送到 Bluesky. 这一过程的痕迹出现在 Bluesky 版本的帖子中, 其中的账户柄格式为 npub************.momostr.pink.ap.brid.gy. 其中的第一部分(从 npub 到第一个点)是 Nostr 账户的公钥, 而其余部分(momostr.pink.ap.brid.gy)则包含了用于桥接帖子的工具(Mostr 和 Bridgy Fed)的一些说明.
—— https://conspirator0.substack.com/p/federation-and-political-spam (Conspirador Norteño)
#Nostr #Fediverse #Bluesky
via Nostr@cxplay
#吐槽
用完大部分 #Nostr 密钥管理方案了... 浏览器扩展(NIP-07), 远程签名器(NIP-46) Amber 和 Bunker, 以及私钥加密(NIP-49). 唯独最早提出的委托秘钥签署(NIP-26)到现在都没有成熟的实现, 看起来真的要被弃用了. 目前仍然还没有解决的依旧是密钥轮换.
体验最好的当然是原生的签名器(浏览器扩展其实也是种签名器), 然后才是通用的远程 Bunker. 私钥加密本身并不解决签名, 只是提供了对私钥的一层对称加密保护, 应该要和浏览器扩展和远程签名器一起使用.
via Nostr@cxplay
用完大部分 #Nostr 密钥管理方案了... 浏览器扩展(NIP-07), 远程签名器(NIP-46) Amber 和 Bunker, 以及私钥加密(NIP-49). 唯独最早提出的委托秘钥签署(NIP-26)到现在都没有成熟的实现, 看起来真的要被弃用了. 目前仍然还没有解决的依旧是密钥轮换.
体验最好的当然是原生的签名器(浏览器扩展其实也是种签名器), 然后才是通用的远程 Bunker. 私钥加密本身并不解决签名, 只是提供了对私钥的一层对称加密保护, 应该要和浏览器扩展和远程签名器一起使用.
via Nostr@cxplay
CXPLAY (npub1gd8…h58h)
Short Text Note by CXPLAY
seen on wss://nostr.wine
