#吐槽
In reply to nevent1q…sql6
_________________________
为什么主动添加空格? 因为各种各样的排版引擎处理中英混排时候的表现不一致, 主动添加空格可以提前控制排版.
via Nostr@cxplay
In reply to nevent1q…sql6
_________________________
为什么主动添加空格? 因为各种各样的排版引擎处理中英混排时候的表现不一致, 主动添加空格可以提前控制排版.
via Nostr@cxplay
#吐槽
以后到底是用 "10 万 3 千 5 百" 还是 "十万三千五百"呢? 或者 "壹拾万叁仟伍佰"?
"2024 年 6 月 23 日" 还是 "二零二四年六月二十三日"? "贰零贰肆年陆月贰拾叁日"?
Safari现已支持中英文混排添加空格 中日韩混排英文/数字时自动追加空格 – 蓝点网
https://www.landiannews.com/archives/108618.html
via Nostr@cxplay
以后到底是用 "10 万 3 千 5 百" 还是 "十万三千五百"呢? 或者 "壹拾万叁仟伍佰"?
"2024 年 6 月 23 日" 还是 "二零二四年六月二十三日"? "贰零贰肆年陆月贰拾叁日"?
Safari现已支持中英文混排添加空格 中日韩混排英文/数字时自动追加空格 – 蓝点网
https://www.landiannews.com/archives/108618.html
via Nostr@cxplay
#吐槽
宣布《梅根2》成为今年我最期待的超英电影. 超英和其他英雄主义电影能变成今天这个低期望值的样子, 全靠同行衬托啊.
【初代AI大战终极AI!温子仁监制科幻片《梅根2.0》正式预告,梅根全面升级!-哔哩哔哩】
https://www.bilibili.com/video/BV1qYZ9YAEve?p=1
#电影
via Nostr@cxplay
宣布《梅根2》成为今年我最期待的超英电影. 超英和其他英雄主义电影能变成今天这个低期望值的样子, 全靠同行衬托啊.
【初代AI大战终极AI!温子仁监制科幻片《梅根2.0》正式预告,梅根全面升级!-哔哩哔哩】
https://www.bilibili.com/video/BV1qYZ9YAEve?p=1
#电影
via Nostr@cxplay
#吐槽
In reply to nevent1q…3awj
_________________________
🫡受保护笔记倒是不太有高需求, 主要还是个性化方面能方便一点就会有更多独立站了, 就像 Ditto 一样可以给小型社区自己托管自己的客户端的中继.
via Nostr@cxplay
In reply to nevent1q…3awj
_________________________
🫡受保护笔记倒是不太有高需求, 主要还是个性化方面能方便一点就会有更多独立站了, 就像 Ditto 一样可以给小型社区自己托管自己的客户端的中继.
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
#吐槽
In reply to nevent1q…a43p
_________________________
noStrudel was probably the first client to use this NIP
via Nostr@cxplay
In reply to nevent1q…a43p
_________________________
noStrudel was probably the first client to use this NIP
via Nostr@cxplay
#吐槽
#Telegram 正在以每天平均三千个的速度清理成人内容频道和群组, CSAM 方面另算, 也是平均每天三千个.
> https://t.me/stopCA
不过按照公开的统计数据, 俄语区域和独联体国家用户依然是 Telegram 的主要用户群, 是中文用户群的四十多倍.
via Nostr@cxplay
#Telegram 正在以每天平均三千个的速度清理成人内容频道和群组, CSAM 方面另算, 也是平均每天三千个.
> https://t.me/stopCA
不过按照公开的统计数据, 俄语区域和独联体国家用户依然是 Telegram 的主要用户群, 是中文用户群的四十多倍.
via Nostr@cxplay
#吐槽
In reply to nevent1q…4tvq
_________________________
只会小修小补, 还得靠主要贡献人带飞.🤪
Jumble 简单又好用, 非常适合初次加入 Nostr 的和已经完全熟悉 Nostr 的.
via Nostr@cxplay
In reply to nevent1q…4tvq
_________________________
只会小修小补, 还得靠主要贡献人带飞.🤪
Jumble 简单又好用, 非常适合初次加入 Nostr 的和已经完全熟悉 Nostr 的.
via Nostr@cxplay
#吐槽
In reply to nevent1q…9m3n
_________________________
我怕最后写出 AI 都改不了的 bug, 还是让专业的来算了.
via Nostr@cxplay
In reply to nevent1q…9m3n
_________________________
我怕最后写出 AI 都改不了的 bug, 还是让专业的来算了.
via Nostr@cxplay
#吐槽
In reply to nevent1q…3prn
_________________________
cody2 (npub1y3r…yq9d) 加油啊, 写前端的大哥哥. 什么时候支持一下自定义 Emoji, 帖子分享和重新广播事件呢?🤣
via Nostr@cxplay
In reply to nevent1q…3prn
_________________________
cody2 (npub1y3r…yq9d) 加油啊, 写前端的大哥哥. 什么时候支持一下自定义 Emoji, 帖子分享和重新广播事件呢?🤣
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