ata-sesli

Hi HN!

I built RVault because I wanted a fully local password manager that lives in the terminal and whose internals I could actually understand.

It uses a CLI + TUI interface and focuses on keeping everything local without relying on browser extensions or hosted services.

I wrote a longer story about the design decisions and how it evolved here: https://medium.com/@atasesli05/one-user-one-problem-so-i-bui...

Happy to hear feedback or answer questions!

I like the headless approach here. Since you already have hierarchical auto-tagging, do those categories act as "gravitational anchors" for the spatial canvas to prevent a "semantic hairball" once the knowledge base scales beyond a few hundred atoms?

The core separation line here seems to be Snapshot vs. Weave. Git treats history as a path between states, but Manyana treats the state as the history.

Since the weave grows with every line ever written, how do you handle "tombstone" (deleted data) bloat? In a decade-old repo with high churn, does the metadata overhead for a single file eventually make it unmanageable compared to Git’s "forgetful" snapshotting?

The expression fusion win is huge for cache locality. Since you're using Rayon for the multicore side, I'm curious if the generated Rust expression tree is 'flat' enough for LLVM to trigger auto-vectorization (SIMD) on the individual cores or if the tree traversal adds enough branching to break that?

This feels amazing to use, I just wished there was a 'previous year' and 'next year' buttons too.

Defining agents as files in a repo makes a lot of sense from a versioning and portability perspective.

Do you see this spec eventually supporting environments like Codex or VS Code–style agent integrations such as Antigravity as well?

Nice idea, this looks like it simplifies a lot of the common animation cases.

Have you thought about allowing animations to be chained or sequenced? For example running one animation after another using multiple data attributes.

The timestamp bucket idea for generating shared port candidates is clever.

Do you find this works reliably outside routers that preserve source ports? My understanding was that TCP punching tends to depend heavily on NAT behavior.

Tried a quick match and it’s surprisingly fun. One thing I noticed though is that offsides don't seem to be implemented yet unless I missed it, which changes the tactics quite a bit. Is that something you're planning to add?

Interesting approach from Claude. I wonder what the next step would have been if none of the context-based guesses worked.