Stoffel：Rust 把多方安全计算从语言到 QUIC 运行时整条栈全包了

Stoffel 最抓眼球的地方，不是单个 crate，而是它把 安全多方计算（MPC） 需要的整条链路几乎都塞进了一个 Rust monorepo：从类似 Cargo 的 stoffel CLI、到 StoffelLang 编译器、Rust SDK、寄存器式 VM，再到真正负责分布式执行的 MPC 后端和网络层，作者想做的是一套“能写、能编、能跑、还能组网”的完整运行时栈。

这个项目的目标也很明确：开发者写看起来比较普通的代码，只把需要保密的值标成 secret，剩下的编译、字节码、执行和参与方协作交给底层去处理。仓库里已经把 HoneyBadger / AVSS 后端、QUIC 联网、C FFI、typed Rust bindings 这些本来很容易散落在不同仓库里的东西收拢到一起，还提供了本地执行和真实网络执行两条路径，这让它不像论文 demo，而更像一套认真往产品和平台形态推进的基础设施。

对 Rust 生态来说，Stoffel 的意义在于它把 Rust 擅长的那几件事——类型约束、底层控制、并发与网络工程——直接压到了隐私计算这条高门槛赛道上。过去大家更常看到 Rust 在数据库、代理、编译器和 WebAssembly 上打基础设施，这次则是把 “可落地的 MPC 工具链” 作为完整产品形态推出来，想象空间相当大。

原文链接：https://github.com/Stoffel-Labs/stoffel

vib：终端双栏文件管理器把 LocalSend 文件互传直接做进 TUI

vib 不是那种“能浏览目录就算完事”的 TUI 小工具。作者把它做成了一套更接近日常主力工具的终端文件管理器：双栏浏览、独立标签、批量选择、文本预览、书签管理 都已经补齐，而且操作逻辑走的是很典型的键盘工作流路线，明显是冲着长期使用而不是一次性展示去的。

真正让它从“又一个 TUI 文件管理器”里跳出来的，是它把 LocalSend 直接接进了终端里。也就是说，你不用先切到图形界面再找传输工具，而是可以在当前终端工作流里直接扫描局域网设备、选中文件、发起传输、接收文件，再继续干活。这个方向挺对味：Rust 近几年很会做 CLI/TUI，但真正把“跨设备互传”这种生活化能力无缝并进终端体验的项目，其实并不多。

从 README 看，vib 已经把很多容易被忽略的细节也处理到了：传输状态提示、确认弹窗、下载落点、重扫网络设备、以及对 Docker / Tailscale 之类多网卡环境的说明，都说明作者不是只做个壳，而是在认真把它往可发布工具上打磨。对喜欢在终端里完成尽可能多事情的人来说，这个组合挺有吸引力。

原文链接：https://github.com/ayanchavand/vib

push2talk：Whisper 本地语音转写做成跨平台热键输入桌面应用

push2talk 的亮点，不只是“又一个 Whisper 客户端”，而是作者把 按住热键说话、松开后把转写结果直接打进当前光标位置 这件事，做成了一套完整的桌面产品，而且坚持 全程本地运行：音频不出机器，转写由 whisper-rs / whisper.cpp 完成，Linux 和 macOS 两边都给出了可安装构建。

更有意思的是它暴露出来的那些很 Rust、也很系统工程的实现细节。Linux 侧热键捕获直接读 evdev，绕开 X11 / Wayland；macOS 侧作者没有继续忍 rdev 在真机 Apple Silicon 上的崩溃，而是手写了一套 CGEventTap；录音走 cpal，键盘模拟在 Linux 上交给 ydotool、macOS 上交给 enigo，GPU 转写则分别吃 Vulkan 和 Metal。也就是说，这不是简单把几层库缝起来，而是实打实地在桌面平台边界、权限模型和原生输入输出层面做了不少脏活累活。

对 Rust 社区来说，这类项目很能说明 Rust 做桌面工具的现实状态：它不只是“界面能不能画出来”，而是能不能把热键、输入设备、系统权限、GPU 推理和跨平台发布这些容易出坑的地方一并收住。push2talk 这次给出的答案，算是相当硬朗。

原文链接：https://github.com/arunmiriappalli/push2talk

kibble：轻依赖 Rust 知识摄取与 RAG 工具链把抓取、清洗、检索和 MCP 串成一套

kibble 想做的不是单个 RAG demo，而是一条更长的“知识摄取流水线”：抓取、爬站、提取、清洗、建库、检索、问答、评估、聚类、HTTP 服务、MCP 工具暴露，几乎全都放进了一套 Rust CLI / library 里。作者把它定位成一个 快、轻依赖、可编排 的知识与数据工具链，把真正吃资源的 OCR、训练、embedding 后端留给外部服务，自己专注在把脏数据收进来、洗干净、变成结构化语料这件事上。

它比较有意思的一点，是没有为了“AI 工具链”这个标签把东西堆得很重。作者专门强调了 feature-gated library、Tokio 异步、流式 ask API、手写 BM25 + RRF 融合、无 embed 后端时自动降级 lexical-only、reqwest + rustls 避开系统 OpenSSL，还给了 386 个测试和 MCP 暴露路径。换句话说，它更像是一个 Rust 工程师视角下的 AI 数据基础设施，而不是先摆个聊天壳子再慢慢补底层。

更值得留意的是它把“数据摄取”和“能力摄取”放在了一起：caps 可以安装技能，mcp 可以把整套工具暴露给 agent / harness 使用。这让 kibble 的边界开始从单纯数据管道，往 Rust 版 agent 工具地基 靠过去。要是后面这条线继续长，Rust 在 AI 基础设施里的存在感可能会更强。

原文链接：https://github.com/femboyisp/kibble