#吐槽
In reply to nevent1q…gsw2
_________________________
主要还是看列表事件能不能被正常发现, 公共中继可能还是得留上一两个, 用来更新自己的中继列表元信息.
via Nostr@cxplay
In reply to nevent1q…gsw2
_________________________
主要还是看列表事件能不能被正常发现, 公共中继可能还是得留上一两个, 用来更新自己的中继列表元信息.
via Nostr@cxplay
#吐槽
In reply to nevent1q…mznu
_________________________
这不好说, Nostr 上新建密钥对(账户)和发消息的成本都比以往任何社交媒体都低. 上次的垃圾事件攻击停了我觉得并不是成本变高了, 而是 Damus 热度过了, 也让发垃圾消息的人失去了兴趣.
via Nostr@cxplay
In reply to nevent1q…mznu
_________________________
这不好说, Nostr 上新建密钥对(账户)和发消息的成本都比以往任何社交媒体都低. 上次的垃圾事件攻击停了我觉得并不是成本变高了, 而是 Damus 热度过了, 也让发垃圾消息的人失去了兴趣.
via Nostr@cxplay
#吐槽
In reply to nevent1q…jr53
_________________________
用了 Gossip 模型的客户端都应该能看到其他人的帖子, 不需要靠堆中继数量来提高覆盖率. 我现在在 Amethyst 就能看到你们的.
via Nostr@cxplay
In reply to nevent1q…jr53
_________________________
用了 Gossip 模型的客户端都应该能看到其他人的帖子, 不需要靠堆中继数量来提高覆盖率. 我现在在 Amethyst 就能看到你们的.
via Nostr@cxplay
#吐槽
In reply to nevent1q…apvc
_________________________
我基本把公共中继全删了, 现在也看不到这个玩意了. 但偶尔还是会有漏网之鱼从其他人的帖子线程里面冒出来.
via Nostr@cxplay
In reply to nevent1q…apvc
_________________________
我基本把公共中继全删了, 现在也看不到这个玩意了. 但偶尔还是会有漏网之鱼从其他人的帖子线程里面冒出来.
via Nostr@cxplay
#吐槽
In reply to nevent1q…ekss
_________________________
不过看样子 wsrv.nl 好像直接屏蔽了所有 .xyz 域名. 这, 就是 .xyz!
via Nostr@cxplay
In reply to nevent1q…ekss
_________________________
不过看样子 wsrv.nl 好像直接屏蔽了所有 .xyz 域名. 这, 就是 .xyz!
via Nostr@cxplay
#吐槽
In reply to nevent1q…vm33
_________________________
对于文件系统来说, 目录结构, 扩展名甚至文件名都是多余的, 寻址根本不需要这些用来给人类可读的东西. 这种设计概念也延续到了如今一些文件传输协议和网络文件系统之中, 给人类(User)读的或者事实上处理这些信息的人类的代理(User-Agent)已经全都变成了元信息, URI/URL 真正成为了用来在文件系统里辅助寻址的一个工具. 没有作为客户端的代理代为人类解析这些信息, 人类实际上就是赛博空间里真正的 "盲人".
via Nostr@cxplay
In reply to nevent1q…vm33
_________________________
对于文件系统来说, 目录结构, 扩展名甚至文件名都是多余的, 寻址根本不需要这些用来给人类可读的东西. 这种设计概念也延续到了如今一些文件传输协议和网络文件系统之中, 给人类(User)读的或者事实上处理这些信息的人类的代理(User-Agent)已经全都变成了元信息, URI/URL 真正成为了用来在文件系统里辅助寻址的一个工具. 没有作为客户端的代理代为人类解析这些信息, 人类实际上就是赛博空间里真正的 "盲人".
via Nostr@cxplay
#吐槽
原本 JPEG XL 还有希望在 Chrome 中得到支持的, 曾经都已经是一个实验性 flag了. 结果现在直接没了, 兼容性列表上只剩一个 Safari 独苗.
这下这个扩展又有用处了: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhdlfmkaenamnlbpdfplekldlnghchp
用 WASM 黑魔法给 Chrome 再次支持 .jxl 图片网页显示.
AVIF, HEIC, WebP 都是从视频编码来的(av1, h265, vp8). 只有 JPEG XL 才是正宗的图片家族的嫡系啊! 虽然没什么卵用, 还得看兼容性说话.
via Nostr@cxplay
原本 JPEG XL 还有希望在 Chrome 中得到支持的, 曾经都已经是一个实验性 flag了. 结果现在直接没了, 兼容性列表上只剩一个 Safari 独苗.
这下这个扩展又有用处了: https://chromewebstore.google.com/detail/jpeg-xl-viewer/bkhdlfmkaenamnlbpdfplekldlnghchp
用 WASM 黑魔法给 Chrome 再次支持 .jxl 图片网页显示.
AVIF, HEIC, WebP 都是从视频编码来的(av1, h265, vp8). 只有 JPEG XL 才是正宗的图片家族的嫡系啊! 虽然没什么卵用, 还得看兼容性说话.
via Nostr@cxplay
#吐槽
In reply to nevent1q…ekss
_________________________
由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特地站点的, 只能依赖于图片资源的显式扩展名来判断.
除非提前知道站点内的所有媒体服务器的主机名. 或者... 有一种能主动发出 HEAD 请求的东西. 但是在没有显式的标记的情况下(如扩展名, 主机名), 如何判断应用内的资源那些是媒体资源呢? 对着所有未知的外部资源发一通 HEAD 吗? 客户端就像一个盲人一样, 对着这些没有 "Alt" 的资源瞎猜类型.
对于 header 的利用, 可以直接通过 Content-Length 标头阻止某些体积过大的资源, 虽然有些媒体服务器根本就不带这个标头...
某些允许自由插入图片外链的社媒平台, 随随便便一张 1080P 的 PNG 截图就能超过 1MB. 托管图片是简单的, 和托管文件一样对待就好了, 但是压缩和处理图片又是计算密集的.
社交媒体昂贵的源头就是这些没有得到正确处理的媒体资源.
via Nostr@cxplay
In reply to nevent1q…ekss
_________________________
由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特地站点的, 只能依赖于图片资源的显式扩展名来判断.
除非提前知道站点内的所有媒体服务器的主机名. 或者... 有一种能主动发出 HEAD 请求的东西. 但是在没有显式的标记的情况下(如扩展名, 主机名), 如何判断应用内的资源那些是媒体资源呢? 对着所有未知的外部资源发一通 HEAD 吗? 客户端就像一个盲人一样, 对着这些没有 "Alt" 的资源瞎猜类型.
对于 header 的利用, 可以直接通过 Content-Length 标头阻止某些体积过大的资源, 虽然有些媒体服务器根本就不带这个标头...
某些允许自由插入图片外链的社媒平台, 随随便便一张 1080P 的 PNG 截图就能超过 1MB. 托管图片是简单的, 和托管文件一样对待就好了, 但是压缩和处理图片又是计算密集的.
社交媒体昂贵的源头就是这些没有得到正确处理的媒体资源.
via Nostr@cxplay
#吐槽
In reply to nevent1q…0sqa
_________________________
其实很早就用了, 体验很好, 很适合普通用户使用! 不过因为我有 NIP-50 的需要, 所以就直接用了常规的中继软件, 这方面能选的也很少.
via Nostr@cxplay
In reply to nevent1q…0sqa
_________________________
其实很早就用了, 体验很好, 很适合普通用户使用! 不过因为我有 NIP-50 的需要, 所以就直接用了常规的中继软件, 这方面能选的也很少.
via Nostr@cxplay
#吐槽
这次的 #ReplyGuy 还真可以算是继上次 Damus 之后的最大规模垃圾消息攻击了. 相比那个时候完全地被压制, 现在社区已经相对有成熟的办法过滤这些垃圾消息了, 还可以促进一下客户端和中继的 WoT 的应用. 相对来说好处大于坏处.
via Nostr@cxplay
这次的 #ReplyGuy 还真可以算是继上次 Damus 之后的最大规模垃圾消息攻击了. 相比那个时候完全地被压制, 现在社区已经相对有成熟的办法过滤这些垃圾消息了, 还可以促进一下客户端和中继的 WoT 的应用. 相对来说好处大于坏处.
via Nostr@cxplay
#吐槽
In reply to nevent1q…tlu4
_________________________
我直接在本地跑了一个完整的 rnostr 中继, 一边当缓存, 一边用来搜索历史记录. 占用也相对低一些.
via Nostr@cxplay
In reply to nevent1q…tlu4
_________________________
我直接在本地跑了一个完整的 rnostr 中继, 一边当缓存, 一边用来搜索历史记录. 占用也相对低一些.
via Nostr@cxplay