@Rocketer #11 这个很确定是能的，UU 加速器 P2P 联机流量走的那个线路到日本来回延迟就是三十多毫秒

坏了，4/12

我的钛合金狗眼不管用了 (悲)

游戏体验的话，做得非常简洁非常棒！
要提建议的话，也许可以顺便部分场景下适配一下键盘操作？（以及游戏手柄输入？貌似有些多余），交互逻辑看上去应该是没问题的。

(等明天我要换大屏再测一遍，一开始明明很自信的😭)

嗯？
哦，我草。(请务必别在公共场合点进去草)

英文环境的可以用来做角色扮演 (RP) 的聊天机器人是已经有不少了而且玩的用户挺多（比如做了 NSFW 过滤的 Character.ai ，和没有额外过滤但是接口可以配合 SillyTavern 之类的 UI 来实现允许 NSFW 内容聊天的 NovelAI ） ，那么中文版的这东西那就交给你们来扩大市场了（真诚的祝福）

顺带一提，有 SillyTavern 这一类的开源软件就是类似于专门针对聊天（或者类似念爱养成游戏的那种模式）做的一套用户界面，可以选择接入本地的模型或者云端的一些 API 服务。（相比之下，原版的 oobabooga 这种虽然有对话模式，但本身也更多只是用来本地跑模型做实验为主的）

按照查到的内容来看，接入 OpenAI 服务的话生成 NSFW 内容是并不安全的，可能会收到警告邮件甚至封号。OpenRouter 这种 API 中间商也是有相应的过滤的。不过，OpenAI 的 GPT 可以说是目前能够配合角色扮演场景的最优秀的语言模型。

参考 OpenRouter 里面给的其他模型，对话效果还不错的 Claude 也有自己的一套过滤。然后，Llama 这个模型测试下来是并不适合直接在角色扮演的对话场合使用 (Llama2 70B 也是)。

前面提到的 Novel AI 是个特例，它本来是辅助写小说的，但是在角色扮演对话的这种用途下，因为它的模型的创造力很强（不清楚怎么描述，差不多是这个意思，注意不是逻辑性，更像是思维发散性），在喂了角色卡之后的聊天对话场景表现是非常合格的（而且允许瑟瑟）。如果不使用 OpenAI 的那套，很多拿 SillyTavern 玩的用户就用 NovelAI 的 API 去了。不过，NovelAI 的模型不支持中文。

以上，那么祝这个平台做大做强（咳）。

得益于这样的公司/这样的小程序广告风格的存在，现在提到小程序，我的印象始终就是，横幅广告、悬浮按钮广告、诱导点击的按钮图片广告、会移动的“关闭广告”按钮等等。

……微信根本就没有在监管吧，就算有也日常是对个人开发者重拳出击（用户选择本地敏感图片然后本地预览，被截图提交举报然后开发者遭罪这种）。

整一个带供电的 USB-C 扩展坞试试？估计就是硬盘盒供电问题。硬盘盒指示灯有的可能是随便插个电都能亮的。

（题外话，所谓更开放的安卓在一些外设兼容性上面更厉害，有的安卓机插移动存储设备走 USB 3.x 必定读取失败，得走 USB 2.0 才认。查出来是这种情况之后感觉是真坑爹）

@MossFox #65 至于注册，接码平台依然有注册 OpenAI 账号可用的一次性手机号，比如印度尼西亚的。就不放链接了，反正就是那套。注册个自己的账号之后不需要 API 服务、只需要 GPT Plus 的话，就像楼上说的在应用商店里面订阅就可以了。安卓就 Google Play （支持国内外币卡），iOS 就美区礼品卡。

Google Play 美区应该能绑定国内外币卡直接订阅 GPT Plus ，20 美元一个月。买断制应用程序我确定是能这样买的，订阅应该也一样。地址写个免税州就可以了。

可以讨厌的东西很多，但是绝大多数时候，对方不存在恶意的情况下就别太苛刻了，只要能正常友好交流就可以。

那么我来胡乱列几个，看看下面这些聊天行为能不能引发“不适”：

1. 即使不是专用缩写或者领域特有的 terminology ，用语也习惯中英混杂；
2. 中英文和全半角之间没有添加增加透气性的空格；
3 不使用任何标点符号 全部用空格替代 或者使用奇怪的 Emoji 代替文末句号😁
4.列表项的点号后面不放空格；
5. 喜欢很唐突地使用 py 缩写；
6. 组织语言得时候，的、地、得 不分；
7. 错别字，比如：代号"霸王行动"的诺曼底战役是世界战争史上规模最大的海上**登录**战役；
8. 一条消息要
9. 分两三条发；
10. [动画表情]

以上只要有任何一个能够引发不适感……也请尝试克服一下这种感觉。毕竟绝大多数场合的消息是用来交流的，不需要太纠结于形式。必要的时候如果追求沟通效率，让对方组织一下大段内容再发也是可以的。

长语音消息除外。

反代理创建的是一个和直接访问官网不同的域，Cookie 和其他存储不通用。
意味着你需要额外让用户在你的反代页面完成用户登录才可以拿到用户凭据，而且这个过程中反代理规则里面会需要好多必要的关键字替换才行，不然现在的网页应用大概率会跑不起来。
高校的那种 Web VPN 就算是做得成功的典型，很多现代框架构建的网页应用也能保证正常运行和正常代理，很好奇是怎么做到的。

@cssk #3 色情。不是屏蔽词也自我屏蔽了，有些多余。

光看描述，感觉可以是很好功能机用的操作系统。之所以感觉是功能机，因为这种平台估计不可能有什么丰富的应用生态，能满足手机该有的功能就差不多了。你说有政策鼓励？套补贴的企业疯狂给你发布垃圾应用哦。

这样的机器对于本论坛的人来说，肯定是忍不了的。

不过，智能手机只用来 通讯、购物、使用客户端形式的线上多媒体服务等 的用户是绝大多数。而且考虑到像是现在很多政务服务甚至银行服务的入口也在搬进支付宝或者微信这种地方，要用单独客户端的场景逐渐有限。这时候应用生态对于日用需求的影响就并不大了，这类设备不见得没有使用场景。
家中有长辈的反而还真能整一个这样系统的设备，满足日用需求的同时专门防治流氓应用。

顺便…… 网页浏览器？但凡是个操作系统或者想让微信这种能运行起来，都得有个能用的浏览器。这个得怎么自研……

总之我不买。

设备：Surface Duo (Android 12)
Chrome 中出现色彩断层 (更像是色彩位数不对)，本地 Google 照片预览完全正常。
Edge 不支持直接预览。

设备：Redmi 某型号 (MIUI 13, Android 12)
Chrome 中没遇到前面提到的色彩断层，但是本地图片查看器不支持预览，显示文件损坏。

Apple 设备还可以来这边看 HDR 实现的比白色更白的白底效果：
https://notes.dt.in.th/HDRQRCode

Flashpoint 那个项目让我想到了个事情，看了下它是有存储 showgood 早期的作品的，但是貌似不全。

不记得是哪一段时间了，showgood 官网是变成了在线观看的模式，然后那一段时间的节目因为套了一个播放器所以不能用浏览器直接下载。那时我从浏览器缓存里面存过一个十五集（且看上去应该是没有完结）的《小兵的故事》，不是现在网上正常能找到的那个十集的系列，内容完全不同（人物一样）。原始文件名格式例如 xiaobg15.swf ，完整 URL 没有记录了。

然后现在感觉那个时候官网在线播放的那一系列剧集，全网都不见踪影了？但我很确定 2015 年那时把官网拿到的 swf 文件传到百度网盘时是触发了秒传的，所以一定在哪里还能找到完整的剧集，有人有那一系列的 swf 原文件。

那一系列的作品文件大小是有点重量级的，比如第 13 集（ xiaobg13.swf ）的文件大小达到了 32.95 MB 。有不少地方把矢量场景转为了位图来降低低端机器的播放难度。

（看了眼网盘，偏偏第一集被存漏了。）

@blueboyggh iOS 版本也带的，所以考虑到多平台同步，可以直接拿 Edge 当主力浏览器用。

iOS 如果剪切板内容来源不是当前应用程序，只要当前程序请求读取了都会有提示。即使在设置里面给了当前应用默认允许，也会有提示。

原生安卓（好像）是没有提示的。安卓那边也就浏览器网页应用能通过浏览器来限制权限。

@iamtsm #6
有，WebRTC 既然走的是 P2P ，可以来一个测试端对端通讯延迟和稳定性的功能。

举个例子，有的联机游戏会走 P2P ，但是因为例如其中一方的无线网非常辣鸡或者中间网络线路很烂，即使两边玩家各自测速是正常的，实际的玩家之间的 UDP 通讯 [稳定性] 会很难直接测试。

我之前花了一天半给自己整了一个走 WebRTC 的浏览器里面能跑的测试 UDP 通讯稳定性的东西，
https://udp-ping.dev.mxowl.com/
对于这个测试页面里面的稳定性测试，有公网 IP 的服务端直接作为了一个 WebRTC Client （ createOffer ），所以即使 NAT 类型不佳、没法打洞的客户端环境也能成功建立连接。然后，为了测试连接稳定性，会以每秒 60 次的速度发带序号的 ping pong 文本信息。
延迟图像越接近一条直线，说明稳定性越好。

因为写得太匆忙太丑陋了所以就没开源，但核心原理很直接，写类似功能的话应该不会有太多坑。可以试试看，因为类似的功能似乎很少见，现在大部分都是网络测速服务，能测试稳定性的网络测试工具 Cloudflare 的那个在国内又没有节点。

（这个页面的 NAT 类型测试仅供参考，原理是批量请求几个 stun 服务器然后检查出口端口号是否唯一，但是没有额外检查 stun 服务器的请求到底有没有成功、也没有真正建立连接测试连通性。其实能修，但这个工具目前就自己用的所以懒得修了）

网页应用吗，如果 token 是存在本地的，登陆拿到 token 之后调用请求用户信息的接口可以确保 token 是被正确保存了的。
如果使用的是 Cookie 存储 token ，在跨域 iframe 里面设置 Cookie 会失败。如果用其他方式的存储，用户如果禁用了 Cookie ，基本上所有 Storage API 都会在访问时抛出异常（包括 localStorage ）。这些情况都算是，登陆请求成功但是 token 没有办法被保存的情境。

我见过的大约只有上面这种了，楼下补充看看。