#吐槽

In reply to nevent1q…0sc9
_________________________

开开日志, 定期统计一下 IP 频率.

via Nostr@cxplay

cody2 (npub1y3…yyq9d)

Short Text Note by cody2

貌似有机器人开始进行 REQ 攻击了😂 中继器的请求量比平时多了一倍

#吐槽

In reply to nevent1q…3cwp
_________________________

这些事情其实只要「有趣」就够了

via Nostr@cxplay

Maoyi (npub1rw…fpemg)

Short Text Note by Maoyi (reply)

除了成本还有收益，除非replyguy有心理变态需求，一直维持着没有收益的事情

#吐槽

In reply to nevent1q…gsw2
_________________________

主要还是看列表事件能不能被正常发现, 公共中继可能还是得留上一两个, 用来更新自己的中继列表元信息.

via Nostr@cxplay

DASHU (npub19y…azqwk)

Short Text Note by DASHU (reply)

其实不是的，还是要靠公共中继。

这种模式还是会漏一部分消息。

#吐槽

#ReplyGuy has become impersonate guy.

via Nostr@cxplay

#吐槽

In reply to nevent1q…mznu
_________________________

这不好说, Nostr 上新建密钥对(账户)和发消息的成本都比以往任何社交媒体都低. 上次的垃圾事件攻击停了我觉得并不是成本变高了, 而是 Damus 热度过了, 也让发垃圾消息的人失去了兴趣.

via Nostr@cxplay

Maoyi (npub1rw…fpemg)

Short Text Note by Maoyi (reply)

论持久战，它还能一辈子不计成本的发下去么

#吐槽

In reply to nevent1q…jr53
_________________________

用了 Gossip 模型的客户端都应该能看到其他人的帖子, 不需要靠堆中继数量来提高覆盖率. 我现在在 Amethyst 就能看到你们的.

via Nostr@cxplay

1024党总干事 (npub1d5…ap6lz)

Short Text Note by 1024党总干事 (reply)

没有公共中继怎么看到别人的帖子呢？

#吐槽

In reply to nevent1q…apvc
_________________________

我基本把公共中继全删了, 现在也看不到这个玩意了. 但偶尔还是会有漏网之鱼从其他人的帖子线程里面冒出来.

via Nostr@cxplay

cody2 (npub1y3…yyq9d)

Short Text Note by cody2 (reply)

我这周都没见过 replyguy 了，是不是连着一些 nostream 中继器没有限制策略

#吐槽

难道就没有人放个蜜罐中继引诱 #ReplyGuy 进来发 spam, 至少能看看 IP 是什么吧?

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

Short Text Note by CXPLAY

难道就没有人放个蜜罐中继引诱 #ReplyGuy 进来发 spam, 至少能看看 IP 是什么吧?

#吐槽

In reply to nevent1q…ekss
_________________________

不过看样子 wsrv.nl 好像直接屏蔽了所有 .xyz 域名. 这, 就是 .xyz!

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

Short Text Note by CXPLAY

#AdGuard urltransform 修饰符的邪门用法 :bili_doge:

#吐槽

In reply to nevent1q…vm33
_________________________

对于文件系统来说, 目录结构, 扩展名甚至文件名都是多余的, 寻址根本不需要这些用来给人类可读的东西. 这种设计概念也延续到了如今一些文件传输协议和网络文件系统之中, 给人类(User)读的或者事实上处理这些信息的人类的代理(User-Agent)已经全都变成了元信息, URI/URL 真正成为了用来在文件系统里辅助寻址的一个工具. 没有作为客户端的代理代为人类解析这些信息, 人类实际上就是赛博空间里真正的 "盲人".

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

CXPLAY on Nostr (reply):

由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特

#吐槽

原本 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

Google

JPEG XL Viewer - Chrome Web Store

Displays JPEG XL images.

#吐槽

In reply to nevent1q…ekss
_________________________

由于 urltransform 的特性, 必须在响应标头出来之前(请求到达源服务器之前)就完成修饰. 于是就根本不可能使用 header 修饰符组合通过 mimetype 来精准地判断是否是图片资源. 只能针对特地站点的, 只能依赖于图片资源的显式扩展名来判断.
除非提前知道站点内的所有媒体服务器的主机名. 或者... 有一种能主动发出 HEAD 请求的东西. 但是在没有显式的标记的情况下(如扩展名, 主机名), 如何判断应用内的资源那些是媒体资源呢? 对着所有未知的外部资源发一通 HEAD 吗? 客户端就像一个盲人一样, 对着这些没有 "Alt" 的资源瞎猜类型.

对于 header 的利用, 可以直接通过 Content-Length 标头阻止某些体积过大的资源, 虽然有些媒体服务器根本就不带这个标头...
某些允许自由插入图片外链的社媒平台, 随随便便一张 1080P 的 PNG 截图就能超过 1MB. 托管图片是简单的, 和托管文件一样对待就好了, 但是压缩和处理图片又是计算密集的.

社交媒体昂贵的源头就是这些没有得到正确处理的媒体资源.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

Short Text Note by CXPLAY

#AdGuard urltransform 修饰符的邪门用法 :bili_doge:

#吐槽

#AdGuard urltransform 修饰符的邪门用法 :bili_doge:

via Nostr@cxplay

#吐槽

In reply to nevent1q…n2vr
_________________________

强🤣算是一种促进 Nostr 网络发展的「不可抗力」吧.

via Nostr@cxplay

cody2 (npub1y3…yyq9d)

Short Text Note by cody2 (reply)

被逼着一个周末给我的中继补上 WoT 😂

#吐槽

In reply to nevent1q…0sqa
_________________________

其实很早就用了, 体验很好, 很适合普通用户使用! 不过因为我有 NIP-50 的需要, 所以就直接用了常规的中继软件, 这方面能选的也很少.

via Nostr@cxplay

cody2 (npub1y3…yyq9d)

Short Text Note by cody2 (reply)

使用 noStrudel 的话可以试试 nostr-relay-tray 🌝

#吐槽

这次的 #ReplyGuy 还真可以算是继上次 Damus 之后的最大规模垃圾消息攻击了. 相比那个时候完全地被压制, 现在社区已经相对有成熟的办法过滤这些垃圾消息了, 还可以促进一下客户端和中继的 WoT 的应用. 相对来说好处大于坏处.

via Nostr@cxplay

CXPLAY (npub1gd…ch58h)

Short Text Note by CXPLAY

seen on relay.momostr.pink