标签：#Rust

GitHub热门项目 | Declare your digital independence | Stars: 2,906 | 64 stars today | 语言: Rust

Hello everyone, I am currently building a high-performance API gateway that integrates business logic components—implemented via WASI and running within Wasmtime—as HTTP/TCP/QUIC handlers. I am exploring the best design approach to achieve a zero-copy data path from the upstream network layer—specifically hyper for HTTP/1.x and HTTP/2, and h3-quinn (based on Quinn) for HTTP/3—to the wasi:http guest environment. Given that: hyper and h3-quinn each manage their own internal buffer pools (e.g., bytes::Bytes ), asynchronous read/write streams, and frame decoders. Wasmtime's wasmtime-wasi-http implements the wasi:http (WASIp2) specification, which relies on resource types such as InputStream and OutputStream . I aim to minimize memory copying and CPU overhead when passing large request bodies or streaming responses across the sandbox boundary. For those experienced with bridging I/O between the host and guest in Wasmtime, I have a few architectural questions: Buffer ownership and memory mapping: How can host-side bytes::Bytes (from hyper or h3-quinn ) be mapped or bridged into Wasm linear memory (and vice versa) without requiring a CPU-based memcpy ? Does Wasmtime's resource streaming support direct memory views, or are we essentially limited to copying data chunks via guest memory pointers? Adapting stream abstractions: hyper uses http_body_util::combinators / http_body::Body , h3 uses its own stream primitives, while wasi:http uses wasi:io/streams . What is the idiomatic way to efficiently adapt these asynchronous streams on the host side (i.e., within the wasmtime-wasi-http handler implementation) without blocking the tokio runtime? Backpressure propagation: How can backpressure signals be correctly propagated from the Wasm guest (e.g., when the guest's InputStream is consuming data slowly) all the way back to the Quinn congestion controller or Hyper connection pool, thereby avoiding unbounded buffering on the host side? If anyone has built similar high-performance ga

A smart contract can't tell whether a submitted score came from a valid game or was simply made up. Dario Dash handles that by proving the run itself. I have been building Dario Dash , a small endless runner on Dusk. The game runs in the browser and does not require a wallet to play. After a ranked run, the browser can generate a Groth16 proof locally and submit the score to a smart contract. The contract does not trust the submitted score. It accepts it only after verifying the proof, binding it to the transaction sender and checking that the run seed has not already been used. The source is available on GitHub . What actually needs to be proven? A score by itself says almost nothing. A client could simply submit any number it wants. For Dario Dash, a valid run includes much more than the final score: the player movement and jump timing the seed-derived obstacle schedule obstacle clearance and collision windows item pickups damage and game-over conditions fireball kills transitions between Regular, Super, Fire and Cape forms the number of ticks played the resulting score The proof must establish that these rules were followed from the initial state until the claimed final state. It also needs to bind the run to the account submitting it, otherwise somebody could copy another player's proof. The architecture The repository is split into a few layers: dash_zk contains the deterministic game simulation used by the browser proving path. dash_core contains a separate 60 Hz simulation used by the RISC Zero path. dash_web exposes the Rust simulation to the browser through WebAssembly. zk_browser contains the Circom circuit and the JavaScript proof conversion code. contract verifies the proof and maintains the leaderboard on Dusk. web contains the playable Vite application. The important boundary is that the game logic is deterministic and integer-only. Floating point physics would be a mess to reproduce consistently across JavaScript, WebAssembly, the proof circuit and th

Most agent frameworks help you build a workflow. The harder part starts after that: the workflow has to run as a long-lived process, fail clearly, restart carefully, and be inspectable after the fact. That's the gap I'm building AgentOS for — an open-source, Rust-first runtime layer that sits underneath frameworks like LangGraph, AutoGen or CrewAI instead of replacing them. What one process gives you cargo run -p agentos-cli -- run --agent examples/simple_agent.toml That single command brings up a supervised agent, a health endpoint, a gRPC message bus, a live SSE event stream, and a recorded trace you can replay later. No API key is needed just to bring the runtime up. Time-travel debugging Your agent does something weird on step 7. Reproducing it costs real API calls, and it never behaves the same way twice. AgentOS journals every LLM exchange and tool result at the provider boundary, so any run can be replayed deterministically — and forked into alternate timelines: agentOS run --agent my_agent.toml # every step journaled automatically agentOS replay --session agent_123 # offline re-run, no API cost, drift-checked agentOS fork --from ckpt_4 --prompt "try the other path" The dashboard's Recordings view turns those journals into a scrubbable timeline: step through the prompt, each exchange, tool calls and their results, with per-exchange checkpoints as fork anchors. What's inside crates/kernel — lifecycle, agent handles, supervisor crates/bus — in-memory, gRPC, SSE and WebSocket messaging crates/trace — recording, replay, diff, checkpoint model crates/vault — secret isolation, encryption, scopes, audit crates/memory , crates/registry , crates/llm , crates/cli , crates/sdk dashboard/ — React debugging surface Where it honestly stands Stable enough for local use: the run / ps / logs / trace / replay CLI flows, local state inspection, export and import, and the core crates with workspace checks and tests. Still experimental: the dashboard, the WASM plugin runtime, Doc

GitHub热门项目 | Simple, Fast, Code first and Compile time generated OpenAPI documentation for Rust | Stars: 3,983 | 8 stars today | 语言: Rust

Lessons from wrapping grok-build — the architecture, the traps, and why we picked Tauri over Electron. TL;DR grok-build is xAI's open-source Rust coding agent. It ships as a TUI. We wrote a native desktop client for it — Tauri 2 (~8 MB binary), React frontend, Rust runtime that spawns the CLI as a child process and talks to it over ACP/JSON-RPC 2.0. This post is the architecture deep-dive: how the pieces fit together, what surprised us, and the parts we'd build differently next time. The full source is at github.com/timexingxin/grok-gui . MIT-licensed. Demo GIF in the README. The problem grok-build is genuinely good at code work — comparable to Claude Code for my workflow. But it ships as a Rust TUI. After six months of cmd+tab between the terminal and my browser tabs, I wanted a real desktop UX without losing what makes the CLI good. The naive options all had problems: Wrap it as a tmux session in a webview. Doesn't help — you're still reading scrollback. Use a community-built web wrapper. They all wrap the OpenAI Chat Completions API directly. They don't talk to the actual agent runtime, so they miss tool calls, plan updates, permission requests, and the streaming event surface that makes coding agents feel responsive. Write a desktop GUI from scratch. Means re-implementing the agent loop, the model integration, the tool calling. Six months of work, plus the resulting client would always lag the upstream. The right answer was staring at me: grok-build already has a JSON-RPC 2.0 over stdio interface called the Agent Client Protocol (ACP). That's the protocol I should be a client of. My job is just to write the client. What is ACP? ACP is a JSON-RPC 2.0 protocol that coding-agent CLIs expose over their stdin/stdout. The agent emits notifications (text deltas, tool calls, plan updates, permission requests, session lifecycle); the client sends requests (user prompts, permission responses, model switches, session loads). If your agent speaks ACP, you can write a client

Building Astra: A Modern Shell in Rust I've been working on a personal project called Astra , an interactive shell written in Rust. The goal isn't to replace every existing shell overnight. Instead, I'm building a clean, modular foundation that's easy to understand, extend, and contribute to. Some of the features currently in development include: Interactive shell loop Customizable prompt system TOML-based configuration Built-in themes Git-aware prompt Command history Tab completion Alias support Plugin framework (early development) Alongside the shell itself, I'm also putting together the surrounding ecosystem—documentation, packaging, examples, tests, and GitHub automation—so contributors have a solid starting point. This project has been a chance to learn more about Rust, shell design, and how larger open-source projects are organized. It's still early, but it's reached the point where the foundation is in place and I'm beginning to focus on expanding features, improving reliability, and increasing test coverage. Check out the project here: astra-shell / astra-shell A custom shell for mac OS! █████████████░░░░░░░░ 65% Astra Shell A modern shell built in Rust for Unix-like systems, with macOS as the primary development platform. Astra is an interactive command-line environment focused on a clean interface, customization, and a better terminal experience. It combines the power of traditional Unix shells with a modern prompt system, configuration, and extensibility. Warning Astra Shell has not gone through extensive testing yet. Wait until the first stable release before using it as your primary shell. Table of Contents Features Screenshots Installation Requirements Usage Themes Why Astra? Contributing License Status Features Interactive Rust shell Configurable prompt engine Multiple built-in themes Git-aware prompt information Command history Tab completion Alias support TOML configuration Built-in shell commands Modular architecture Plugin framework (in developmen

Run two AI coding agents on the same repo and the first thing that breaks is not the code. It is coordination. Agent A starts refactoring auth. Agent B, running in parallel, has no idea and starts the same thing. Neither remembers what it did last session, because each one boots fresh with an empty context window. The usual fixes are worse than the problem: a state file in the repo pollutes every diff and conflicts on merge, and an external issue tracker means API tokens, rate limits, and a hard dependency on the network for something that should be local. So I built grite : an issue tracker that lives inside your git repository as an append-only event log, with deterministic CRDT merging so two writers never conflict. No server. No database. No merge conflicts. Just git. The core idea: issues are events, git refs are the log Grite does not store issues as files in your working tree. It stores them as an append-only write-ahead log inside a git ref, refs/grite/wal . Every action, a create, a comment, a label change, is one immutable CBOR-encoded event appended to that log. Your working tree stays completely clean. The only tracked file grite ever writes is AGENTS.md , and that is on purpose, so agents discover the tool automatically. Because the state lives in a git ref, it travels with your code. It branches when you branch. It merges when you merge. It syncs when you git push . If you can push to a remote, you can sync issues. There is no new account, no new infrastructure, no new protocol to learn. How it works Three layers, cleanly separated. The git WAL is the source of truth. Events are appended as CBOR chunks, each identified by a content-addressed EventId that is a BLAKE2b hash of the event body. Content addressing is what makes the log tamper-evident: change one byte of an event and its ID no longer matches, which breaks the chain. Signing is optional Ed25519 per event, so you can prove which actor created what. The materialized view is a sled embedded key-

GitHub热门项目 | Worktrunk is a CLI for Git worktree management, designed for parallel AI agent workflows | Stars: 5,995 | 12 stars today | 语言: Rust

GitHub热门项目 | Unofficial Bitwarden compatible server written in Rust, formerly known as bitwarden_rs | Stars: 64,238 | 81 stars today | 语言: Rust

GitHub热门项目 | A fast type checker and language server for Python | Stars: 6,817 | 6 stars today | 语言: Rust

I gave an AI agent a calculator because I wanted one hard, inspectable point inside a probabilistic workflow. The model could interpret the request and explain the result. The calculator would perform the computation. It seemed like a clean division of labor. Then I changed one multiplication sign into addition. The calculator still passed 389 of the 390 tests in its Rust library harness. The sole failure compared its answer with NIST's certified results for the Longley regression dataset. That bothered me more than a completely broken build would have. I had treated deterministic computation as safer than asking a language model to improvise arithmetic. But deterministic does not mean trustworthy. A program can return the same wrong answer forever. “Source of truth” suddenly felt too comfortable. Before an AI agent delegates authority to a tool, that authority should be challenged—and remain revocable by evidence. The calculator is only the specimen. The larger idea is a way to place inspectable, replayable instruments inside probabilistic systems. The useful boundary is generation versus execution The interesting distinction is not model weights versus a “real CPU.” Model inference also runs on processors, and language models can learn genuine arithmetic procedures. The useful boundary is between generating an answer and executing a defined operation under a tested contract . Research on Program-Aided Language Models (PAL) makes a related split: the language model reads and decomposes a natural-language problem, while a runtime such as a Python interpreter executes the generated program. The model contributes flexible interpretation; the runtime contributes executable semantics. That is the division I want in an agent: At the semantic edge , the model interprets the request, chooses a procedure, identifies relevant quantities, and explains the result. At the computational edge , a narrow tool validates inputs, applies specified operations, enforces limits, and ret

GitHub热门项目 | Solution for long term memory for agent coding CLIs and to facilitate handoff between different agent vendors | Stars: 1,212 | 186 stars this week | 语言: Rust

GitHub热门项目 | A network diagnostic tool | Stars: 7,361 | 56 stars today | 语言: Rust

GitHub热门项目 | Modern server management panel built with Rust and React. Sites, databases, Docker apps, Git deploy, mail, DNS, monitoring, backups, and security — all in one panel. | Stars: 467 | 13 stars today | 语言: Rust

Building an operating system is a project I have had my eyes set on ever since I discovered free will in the realm of programming. Years ago, I did a reasonable amount of research, paying extra attention to the subject during my computer science degree and I was able to understand Operating System Theory and how it works from first principles but I never really got around to building one. I had only flimsy reasons for not embarking on it like "why build one when there are tons of working ones out there? The theoretical knowledge is enough" . More recently, I am ignoring the need to not re-invent the wheel for the joy of programming. So if you are interested in also rebuilding stuff because you can, join me on this series as I document how I am going to be building kluster. kluster is in its infancy and the direction is not clear but the one certain thing is that I will be building it entirely in Rust, save some assembly instructions and a linker script and I will be explaining every single line of code along the way. It will also be designed to target the raspberrypi 4 & 5, on qemu and on real hardware respectively. This is an opportunity for anyone who wants to see how Rust works at the lowest of levels to hop on and join the ride. Note that this series will be your biggest lesson on delayed gratification because we will write a lot of code before we even get to see anything meaningful on screen but I will foreshadow what you can get by the end of part 3 if you are patient enough: {{ image(src="/images/os-part3-result.png", alt="Part 3 Results OS Dev") }} You can also clone the source code for part 1 from Github and follow along. Project Setup First things first, let us setup the foundation of the project. I'll be straight with you, I love Rust and I enjoy using the Rust ecosystem in its entirety so I will stay true to that and use it as obsessively as any true Rustacean; I won't hold back. Without doubt, all the dependencies we need are freely available as long as

I built Skim because I tried to find a Windows email client that doesn't suck that hard and couldn't really find one. It's not rocket science to vibecode one, right? Why has nobody done it before? Or is everyone just okay with bloated Outlook or archaic Thunderbird? Skim - free, open-source, MIT-licensed minimalistic offline-first email client with BYOK AI. Quick feature list: Installer under 5 MB Bring Your Own Key to enable AI features: Anthropic/OpenRouter, or any OpenAI-compatible server (including a local one) No menu. Minimalistic and contextual interface - buttons are shown only when you need them Keyboard-first controls: shortcuts for everything, no mouse needed Sweet warm zine design Super modest resource consumption AI features are pretty basic: Cowriter that can scan your recently sent emails, adopt your style, and then write emails and replies that sound like you "Ask this email" - chat with a particular email; it can read attachments and follow links inside it Agentic search across all connected inboxes; the "Ask your inbox" feature can scan your whole inbox One-click summarization and translation A few things I'm actually proud of under the hood The UI part is easy to vibecode. These bits were not. Getting the installer under 5 MB took real work. panic = "abort" alone dropped about 6 MB of unwind tables from the binary, that's 23% off the NSIS installer. I ship a single crypto backend (ring, with aws-lc-rs switched off) so I'm not compiling a second, unused crypto library into the thing. I even wrote a tiny Vite plugin that deletes legacy .woff fonts, since WebView2 always uses woff2 anyway. Pretty much every dependency in Cargo.toml carries a comment justifying its feature flags in kilobytes saved: rustls = { version = "0.23" , default-features = false , features = [ "ring" ] } # aws-lc-rs would compile a second, unused crypto library. ~2 MB of dead weight. No Electron, no bundled Chromium. Tauri 2 uses the system WebView2, so it installs per-user wit

When I set out to build a provably-fair random selection system on Solana, the obvious choice for randomness was a VRF (Verifiable Random Function). Instead, I built the system around Solana's SlotHashes sysvar with a commit-reveal scheme. Here's why, and what I gave up to get there. The problem A fair-selection system needs a winner (or set of winners) chosen in a way that's fair, and just as important that participants can check for themselves without taking anyone's word for it. VRF services (Switchboard, ORAO, etc.) solve the fairness part well: they produce randomness that's unpredictable in advance and cryptographically provable after the fact. But they come with a dependency on an oracle, a fee per request, and a proof that most users will never actually verify they'll trust it because the crypto math says they can, not because they did. I wanted something a participant with no crypto background could check in a browser console. The approach: commit-reveal with slot hashes The core idea: commit to the participant list before you know the randomness, then derive the randomness from a slot hash you couldn't have predicted at commit time. rust fn derive_randomness(target_hash: &[u8; 32], participant_root: &[u8; 32]) -> [u8; 32] { let mut combined_seed = [0u8; 64]; combined_seed[..32].copy_from_slice(target_hash); // slot hash at reveal combined_seed[32..].copy_from_slice(participant_root); // Merkle root, locked at commit solana_keccak_hasher::hash(&combined_seed).to_bytes() } The flow: Commit: participant list is finalized and hashed into a Merkle root; this is written on-chain. Wait: a target slot in the future is chosen as the reveal point. Reveal: once that slot passes, its hash is pulled from SlotHashes and combined with the committed root to derive the randomness. Select: the randomness deterministically picks winners from the participant set; winners get their own Merkle root and proofs. Every draw ends up with an audit record like: rust pub struct AuditR

GitHub热门项目 | Offline, privacy-first grammar checker. Fast, open-source, Rust-powered | Stars: 11,873 | 590 stars today | 语言: Rust

If you are an enterprise architect working on Microsoft Entra and AI agents, your first overdue job is not another policy wizard, another dashboard, or another governance steering committee. It is schema design. Specifically, it is deciding how you classify non-human identities with custom security attributes in Microsoft Entra . Not eventually. Up front. I keep seeing the same pattern across customers of every size: teams move quickly on agent experimentation, they onboard identities, they test controls, and then they realize they have no consistent attribute language for policy scope. At that point, every policy becomes a naming convention problem in disguise. That is backwards. The control plane starts with classification Custom security attributes are not decorative metadata. They are tenant-scoped key-value classifications you can assign to users, enterprise applications (service principals), and agent identities that are modeled as a service principal subtype, with dedicated role and permission boundaries for who can define and assign them ( overview , Graph model , agent identity service principal model ). That alone should change how architects think about them. This is not "nice to have taxonomy." This is policy input. Microsoft Entra Conditional Access for agents supports attribute-driven targeting with custom security attributes, and policy evaluation happens during token issuance and refresh, not just at policy authoring time ( Conditional Access for agents ). In other words: if your classification is sloppy, your runtime decisions are sloppy. Why agents raise the stakes You can say "an agent identity is still a service principal" and be technically correct. Microsoft Entra Agent ID is built on service principal infrastructure ( agent identities, service principals, and applications ). You can also miss the point. Agent identity introduces a blueprint-centered model where one blueprint can represent many agents, where blueprint-level policy decisions can