I get a flood of these every single day. Because we use SendGrid as a critical part of our product, I have to look for any emails from them pretty closely. It’s gotten impossible to do with all of these phishing attempts. I gotta hand it to them, though, the attempts are excellent.
I’ve been doing some of this through a term on my phone, but it honestly sucks. Other interfaces (telegram, web ui, email) are gonna be much better experiences on your phone.
Hah, I set up basically the same thing on Saturday during a long car ride. Couple of differences: I’m an opencode user and I used a different VPS provider (though I use vultr for other things). It was my first time actually sitting down and using tailscale, which was quite easy to get going. Did everything from my phone, didn’t even have my laptop with me.
The problem is that people just really do not comprehend what the "public" schema means in supabase. My guess is that that they think it means "default" or something along those lines. If you read the supabase documentation, you can clearly see that it says "your database's auto-generated Data API exposes the public schema by default", but to truly understand that, you need to understand what the data api is and how it relies on rls. For people first coming to supabase, they are probably either new devs, or they think of the db as a backend service that has application-layer authentication in front of it.
Interesting. That would have surprised me if I was a supabase user. I’m used to tossing everything into the public Postgres schema simply because it’s the default schema, and for many small apps, that’s all you need. Supabase should really rethink publicly exposing the default schema without explicit consent from the developer.
That is why in https://github.com/Qbix/Streams the default for all streams is PRIVATE. And people can choose what to open up explicitly. We support access templates, mutable access, and inheritance, roles, even participant roles and custom permissions. But the default is private, and all that is machinery on top of it.
We are a happy user of DBOS. I’ve been building out a lightweight TUI for managing our DBOS application internally, since we have workflows with tens of thousands of steps. I know the team is working on improving conductor for this use-case, but our internal TUI handles it pretty well for now. Hoping to open source it, but the code is a wreck atm. Anyways, I say all this to say, DBOS has a good client that can communicate with the instance easily, so building out a UI that fits your specific needs should be fairly simple.
For repeating objects of the same structure, yaml will still require each key on each object, whereas this is a hybrid with csv, so it defines the keys once.
Code is also unique in its suitability for agentic grep retrieval, especially when combined with a language server. Code enforces structure, semantics, and consistency in a way that is much easier to navigate than the complexities of natural language.
I recently got a Daisy Pod (https://daisy.audio/product/Daisy-Pod/). It supports a few different runtimes, including a max/msp runtime and a Pure Data wrapper called Plug Data. It's a pretty neat little device, even though the documentation could use some work.
I've been working on building something using a Daisy Seed lately. Pretty amazing that I can have interesting sounds (and effects) generated in just ~200 lines of C++.
And you're absolutely right about the documentation.
