<a href="https://x.com/trychroma/status/2037243681988894950" rel="nofollow">https://x.com/trychroma/status/2037243681988894950</a><p><a href="https://xcancel.com/trychroma/status/2037243681988894950" rel="nofollow">https://xcancel.com/trychroma/status/2037243681988894950</a>
返回首页
最新
Burn Room 是一个简单的、一次性使用的聊天工具，基于 SSH 构建。无需创建账户，也无需安装任何软件。它背后没有数据库，没有日志，没有 cookies，也没有跟踪。消息仅存在于内存中，采用端到端加密，并会自动消失。当房间的计时器到期时，所有内容将永久消失。
您可以立即加入：
```
ssh guest@burnroom.chat -p 2323
密码：burnroom
```
或者直接在浏览器中打开 [https://burnroom.chat](https://burnroom.chat)。它在网页终端中运行，也支持移动设备。
### 加密处理方式
私人、受密码保护的房间是完全端到端加密的。服务器无法访问可读消息——它只看到加密数据。
密钥是通过 scrypt 从房间密码派生的，每个房间都有独特的盐值。每条消息都使用 XChaCha20-Poly1305 进行加密，采用新的随机 nonce，遵循与 Signal 和 WireGuard 等工具相同的一般方法。
当您加入房间时，会显示一个指纹，以便您确认每个人都在使用相同的密钥。当您离开时，加密密钥会从内存中清除。
### 设计为消失
Burn Room 中的一切都是临时的。消息从不写入磁盘，从不记录，也从不备份。默认情况下，消息在一小时后会从内存中清除。
房间创建者可以设置燃烧计时器——30分钟、1小时、6小时或24小时。当时间到期时，房间及其中的所有内容都会被摧毁。如果房间闲置，它会自动关闭。创建者也可以随时立即销毁房间。
如果服务器重启，所有内容都会被清除。唯一短暂存储以供恢复的是最小的房间元数据，即便如此，加密房间仍然无法被读取。
### 隐私优先
没有账户，没有身份，也没有任何形式的跟踪。IP 地址仅在短时间内用于速率限制，并保存在内存中，而不是存储。
用户名是临时的，会被回收。该平台旨在最小化初始存在的数据，而不是试图在后期保护存储的数据。
### 语言支持
Burn Room 会自动适应您的系统或浏览器语言。界面在菜单、提示和消息中进行了翻译。
聊天内容可以根据用户进行翻译，因此说不同语言的人可以在同一个房间中交流，并且每个人都能看到自己语言的消息。在加密房间中，翻译在解密后本地进行——服务器从未看到原始文本。
### 您会注意到的功能
有一些始终可用的公共房间，例如政治、游戏、科技和大厅，并提供创建私人、受密码保护房间的选项。
您可以提及其他人，浏览消息历史，并使用简单的命令快捷方式。房间会显示实时倒计时，因此您始终知道它们何时会消失。您还可以分享房间的直接链接，以便立即邀请他人加入。
无论您是通过 SSH 还是浏览器连接，效果都是一样的。
### 技术细节
Burn Room 是使用 Node.js 和 TypeScript 构建的，使用 SSH 进行直接连接，并在浏览器中提供终端界面。加密依赖经过审计的本地库，而不是自定义实现。
它轻量级，但设计上能够同时处理大量用户，并内置防止滥用的保护措施，如速率限制和连接节流。
进入，表达您需要说的话，然后让它消失。
我用 Rust 构建了一个 SQLite VFS，它能够直接从 S3 提供冷查询，性能达到亚秒级，且通常更快。<p>这个项目叫做 turbolite。它仍处于实验阶段，存在一些错误，可能会导致数据损坏。我目前不建议将其用于任何重要的事务。<p>我想探索对象存储是否已经足够快速，以支持基于云存储的嵌入式数据库。文件系统对小的随机读取和就地修改有很好的支持，而 S3 则更倾向于减少请求、增加传输量、使用不可变对象，以及在带宽通常是主要限制的情况下进行高并发操作。这一设计灵感明确来源于 turbopuffer 的从零开始的 S3 原生设计。 <a href="https://turbopuffer.com/blog/turbopuffer" rel="nofollow">https://turbopuffer.com/blog/turbopuffer</a><p>我设想的用例是大量主要处于冷状态的 SQLite 数据库（每个租户一个数据库、每个会话一个数据库或每个用户一个数据库的架构），在这种情况下，为不活跃的数据库保持一个单独的附加卷显得很浪费。turbolite 假设只有一个写入源，更加关注“许多数据库的突发冷读取”而不是“一个热数据库”。<p>turbolite 不会简单地逐页读取原始 SQLite 文件，而是会深入分析 SQLite 的 B 树，将相关页面压缩在一起存储，并保持一个清单，作为每个页面位置的真实来源。缓存未命中时，它使用可寻址的 zstd 帧和 S3 范围 GET 来进行搜索查询，因此获取一个所需页面并不需要下载整个对象。<p>在查询时，turbolite 还可以将存储操作从查询计划传递到 VFS，以便提前下载索引和大规模扫描所需的数据，按照它们将被访问的顺序进行。<p>你可以调整 turbolite 的预取策略。对于点查询和小规模连接，它可以保持保守，避免预取整个表。对于扫描，它可以变得更加激进。<p>它还会根据页面类型在 S3 中对页面进行分组。内部 B 树页面单独打包并被提前加载。索引页面则会进行积极的预取。数据页面按表存储。目标是使冷点查询和连接表现良好，同时使扫描的效率比简单的远程分页要好。<p>在 EC2 + S3 Express 上进行的 1M 行 / 1.5GB 基准测试中，我看到的结果包括亚 100 毫秒的冷点查找、亚 200 毫秒的冷 5 连接查询，以及从空缓存中进行的亚 600 毫秒的扫描，数据库大小为 1.5GB。在普通的 S3/Tigris 上速度稍慢。<p>当前的局限性非常明确：它仅支持单写入，并且仍然是一个系统实验，而非生产基础设施。<p>我非常希望能收到那些在网络上使用 SQLite、存储引擎、VFS 或基于对象存储的数据库方面有经验的人的反馈。我特别感兴趣的是，B 树感知的分组/清单/可寻址范围 GET 的方向是否是值得继续推进的正确方向。
我们开发了 browser-metro，这是一款类似 Metro 的打包工具，完全在 Web Worker 中运行。它支持与 React Refresh 的完整热模块替换（HMR）、基于文件的 Expo Router 路由，以及通过 ESM 服务器按需解析 npm 包。API 路由通过 fetch 拦截在浏览器中运行，无需服务器或服务工作者。
与 Expo Snack（服务器端打包）或 CodeSandbox 不同，这里的一切都发生在客户端。目前仅支持网页预览；原生设备预览在计划中。
开源（MIT）：[https://github.com/RapidNative/reactnative-run](https://github.com/RapidNative/reactnative-run)