A timeline stores 3 main things: events, ranged events, and tags.

Events can point to external refs (URIs, UUIDs, etc; a ref is an arbitrary string) and also contain arbitrary JSON attributes. The idea is that the .til file works as a temporal index, where payloads, notes etc live wherever you already keep them.

I've wanted to build this for a while, mostly for keeping track of and viewing timelines that I find interesting (music, roman empire stuff, etc). This project has 3 main elements, which are all independent: the file format itself (binary, built with postcard), a rust CLI, and a web viewer + editor (react, with the parser compiled to WASM so the FE shares the same implementation).

Source: https://github.com/rellfy/til

Comments URL: https://news.ycombinator.com/item?id=48350310

Points: 3

# Comments: 1

But perhaps a better title would be "Productivity Isn't (Only) About Going Faster"

I currently use Claude web with an MCP component for my workflows but axe looks like it could be a nicer and quicker way to work with the tools I have.

It's a different conversation when we talk about people learning to code now though. I'd probably not recommend going for the power tool until you have a solid understanding of the manual tools.

Components only have access to what you explicitly grant (e.g. a single directory). They're written in any language (Rust, Go, Python, JS) and pulled from the asterai registry.

Under the hood, asterai is a WASM component model registry and runtime built on wasmtime. You publish a component, set an env var to authorize it as a tool, and asterbot discovers and calls it automatically.

I built this because I think the WASM component model is a great way to build software but the ecosystem is missing key infrastructure (especially an open, central registry). AI agents felt like a natural fit since tool security is a real problem, and WASM sandboxing addresses it by default.

Still early stage, but all functionality in the repo is tested and working. Happy to answer questions!

Comments URL: https://news.ycombinator.com/item?id=46961468

Points: 2

# Comments: 0

Asterbot is a modular AI agent where every capability (such as tools, memory, LLM provider etc.) is a swappable WASM component.

Components are written in any language (Rust, Go, Python, JS), sandboxed via WASI, and pulled from the open asterai registry. Think microkernel architecture for AI agents.

Recently I saw how ClawHub had "341 malicious skills", and couldn't help but think how WASM/WASI resolves most of these issues by default, since everything is sandboxed.

So I've spent my weekend building Asterbot, a modular AI agent where every capability is a swappable WASM component.

Want to add web search? That's just another WASM component. Memory? another component. LLM provider? component.

The components are all sandboxed, they only have access to what you explicitly grant, e.g. a single directory like ~/.asterbot (the default). It can't read any other part of the system.

Components are written in any language (Rust, Go, Python, JS), sandboxed via WASI, and pulled from the asterai registry. Publish a component, set an env var to authorise it as a tool, and asterbot discovers and calls it automatically. Asterai provides a lightweight runtime on top of wasmtime that makes it possible to bundle components, configure env vars, and run it.

It's still a proof of concept, but I've tested all functionality in the repo and I'm happy with how it's shaping up.

Happy to answer any questions!

Comments URL: https://news.ycombinator.com/item?id=46937297

Points: 1

# Comments: 0

I suppose I'm thinking of it as a more elegant way of doing something equivalent to top-down agent routing, where the top agent routes to 2-legged agents.

I'd be interested to hear more about how you handle the provenance tracking in practice, especially when the agent chains multiple data sources together. I think my question would be: what's the practical difference between dynamic attenuation and just statically removing the third leg upfront? Is it "just" a more elegant solution, or are there other advantages that I'm missing?

Sometimes you only care about the high level aspect of it. The requirements and the high-level specification. But writing the implementation code can take hours if you're unfamiliar with a specific library, API or framework.

"review every diff line by line" is maybe not the best way to have described it, I essentially I meant that I review the AI's code as if it were a PR written by a team member, so I'd still care about alignment with the rest of the codebase, overall quality, reasonable performance, etc.

I can only think of two ways to address it:

1. Gate all sensitive operations (i.e. all external data flows) through a manual confirmation system, such as an OTP code that the human operator needs to manually approve every time, and also review the content being sent out. Cons: decision fatigue over time, can only feasibly be used if the agent only communicates externally infrequently or if the decision is easy to make by reading the data flowing out (wouldn't work if you need to review a 20-page PDF every time).

2. Design around the lethal trifecta: your agent can only have 2 legs instead of all 3. I believe this is the most robust approach for all use cases that support it. For example, agents that are privately accessed, and can work with private data and untrusted content but cannot externally communicate.

I'd be interested to know if you have reached similar conclusions or have a different approach to it?

The distinction drawn between both concepts matters. The expertise is in knowing what to spec and catching when the output deviates from your design. Though, the tech is so good now that a carefully reviewed spec will be reliably implemented by a state-of-the-art LLM. The same LLM that produces mediocre code for a vague request will produce solid code when guided by someone who understands the system deeply enough to constrain it. This is the difference between vibe coding and zen coding.

Zen coders are masters of their craft; vibe coders are amateurs having fun.

And to be clear, nothing wrong with being an amateur and having fun. I "vibe code" several areas with AI that are not really coding, but other fields where I don't have professional knowledge in. And it's great, because LLMs try to bring you closer to the top of human knowledge on any field, so as an amateur it is incredible to experience it.

For example, say you have a shell script to make a bank transfer. This just makes an API call to your bank.

You can't trust the AI to reliably make a call to your traceability tool, and then to your OTP confirmation gate, and only then to proceed with the bank transfer. This will eventually fail and be compromised.

If you're running your agent on a "composable tool runtime", rather than raw shell for tool calls, you can easily make it so the "transfer $500 to Alice" call always goes through the route trace -> confirm OTP -> validate action. This is configured at build time.

Your alternative with raw shell would be to program the tool itself to follow this workflow, but then you'd end up with a lot of duplicate source code if you have the same workflow for different tool calls.

Of course, any AI agent SDK will let you configure these workflows. But they are locked to their own ecosystems, it's not a global ecosystem like you can achieve with WASM, allowing for interop between components written in any language.