最新

<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> </p>

Burn Room 是一个基于 SSH 构建的简单、即时聊天工具。无需创建账户，也无需安装任何东西。它没有数据库，没有日志，没有 Cookie，也没有追踪。消息仅存在于内存中，采用端到端加密，并会自动消失。当房间的计时器用完时，其中的所有内容都将永久消失。 您可以立即加入： ssh guest@burnroom.chat -p 2323 密码：burnroom 或者直接在浏览器中打开 <https://burnroom.chat>。它在网络终端中运行，也适用于移动设备。 加密处理方式 私密、密码保护的房间采用完全的端到端加密。服务器永远无法访问可读消息——它只能看到加密数据。 密钥是从房间密码使用 scrypt 派生而来，每个房间都有一个唯一的 salt。每条消息都使用 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:&#x2F;&#x2F;turbopuffer.com&#x2F;blog&#x2F;turbopuffer" rel="nofollow">https:&#x2F;&#x2F;turbopuffer.com&#x2F;blog&#x2F;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 上进行的 100 万行 / 1.5GB 基准测试中，我看到的结果是，冷点查找时间不到 100 毫秒，冷 5 连接配置文件查询时间不到 200 毫秒，从空缓存扫描 1.5GB 数据库的时间不到 600 毫秒。在普通 S3/Tigris 上，速度会稍慢一些。<p>目前的限制非常简单：它仅支持单写，而且它仍然更多的是一个系统实验，而不是生产基础设施。<p>我希望收到从事 SQLite-over-network、存储引擎、VFS 或基于对象存储的数据库的开发人员的反馈。我特别感兴趣的是，基于 B 树的页面分组 / 清单 / 可查找范围 GET 的方向是否感觉是正确的方向，是否值得继续推进。

我们构建了 browser-metro，一个类似 Metro 的打包工具，完全在 Web Worker 中运行。它支持完整的 HMR（热模块替换）与 React Refresh，基于文件的路由的 Expo Router，以及通过 ESM 服务器实现的按需 npm 包解析。API 路由通过 fetch 拦截在浏览器中运行——无需服务器或 Service Worker。 与 Expo Snack（服务器端打包）或 CodeSandbox 不同，这里的一切都在客户端发生。目前仅支持网页预览；原生设备预览已在开发计划中。 开源 (MIT 许可证): [https://github.com/RapidNative/reactnative-run](https://github.com/RapidNative/reactnative-run)