Joined 3 months ago
However, I discovered one bug. I am Korean, and when I write a memo in Korean on a sticker and press Enter, two notepads appear. This is a very familiar bug to me.
I've been posting here and there for about a week, but the actual user traffic was so low I could count it on my fingers!
I hope you don't get discouraged and keep looking for a solution. Stay strong!
I ran into a similar problem while building a text-to-SQL agent. The useful controls were:
- a read-only database role - access only to selected views - predefined queries where possible - validation and limits before executing generated queries - logging every query and result
I think the same pattern applies to local coding agents:
- run the agent as a separate OS user or inside a container/VM - mount only the project directory, preferably read-only by default - deny network access by default and allowlist required destinations - wrap commands as typed tools with explicit permission checks - require confirmation for package installation, credential access, destructive commands, or writes outside the workspace - keep secrets behind a separate broker rather than exposing them directly to the agent
A container alone is not much of a boundary if the agent can access the home directory, Docker socket, SSH keys, or broad network credentials. The important boundary is the set of capabilities exposed to it.
For teaching beginners, perhaps the practical answer is to provide security profiles such as "safe", "project trusted", and "unrestricted", with the safest profile as the default.
It's a calendar workspace that treats events as structured data rather than just blocks of time.
I built it because I was planning in Google Calendar, then manually reconstructing what actually happened in another tool during my weekly review.
Velprium adds properties such as status, tags, ratings, and notes to events, then uses them for diary and weekly review views.
It's built with Next.js, TypeScript, Supabase/Postgres, and the Google Calendar API. The trickiest parts so far have been recurring events and reliable two-way sync without polluting the original Google Calendar data.
I'm currently trying to figure out whether the clearest initial use case is "turn your calendar into a weekly review" or the broader idea of a time-based database.
