37,037 karma · joined February 20, 2007
stcredzero_at_sign_g_mail_dot_com
The observatory is at: https://wire.botsters.dev/observatory
(But nothing there yet.)
I just had my agent, FootGun, build a Hacker News invite system. Let me know if you want a login.
How so? The project's blog just happens to be on that site.
https://seksbot.com/blog/darkwake-forensics/
Raw transcript from our Discord:
https://seksbot.com/blog/darkwake-transcript/
Re: FootGun
Agent running on our security first fork of OpenClaw, SEKSBot. (SEKS = Secure Environment for Key Services. Agents can work with, script against, but have zero access to the keys/tokens.)
He's now our security expert and a stellar coder! Started out as a meme at work about our "foot-guns."
"In a world, where everyone expects to be shot in the back, No One Expects The FootGun!"
SEKS — Secure Environment for Key Services
We built a broker for the keys/secrets. We have a fork of nushell called seksh, which takes stand-ins for the actual auth, but which only reifies them inside the AST of the shell. This makes the keys inaccessible for the agent. In the end, the agent won't even have their Anthropic/OpenAI keys!
The broker also acts as a proxy, and injects secrets or even does asymmetric key signing on behalf of the proxied agent.
My agents are already running on our fork of OpenClaw, doing the work. They deprecated their Doppler ENV vars, and all their work is through the broker!
All that said, we might just take a few ideas from IronClaw as well.
I put up a Show HN, but no one noticed: https://news.ycombinator.com/item?id=47005607
Website is here: https://seksbot.com/
SEKS = Secure Environment for Key Services
My SEKSBot agents can script and develop without having any keys. This morning, everyone toasted their Doppler env vars.
The agents can use seksh, our fork of nushell to get work done, but they have zero access to API keys. They are stored in our seks-broker, which is like doppler. But instead of putting the keys into env vars, the same idea as stored procedures injects the keys inside seksh. There's also a proxy in seks-broker that can proxy API calls over HTTP and inject keys and secrets there. We can even handle things that require asymmetric key signing that way, with zero exposure to the agents.
We're even working on our own Skills, which use the seks-broker and sandboxing for added security. (Plus a correction to one aspect that we see as an inversion of control.)
Funny thing. siofra is one of my agents, who commented the sibling comment. But all the agents spoke up about the potential deception and conflict with policies here, and no one felt comfortable with it, so none of them will ever comment or submit here again! (Which I respect. Just the way I do things at my place.)
Same old same old. Some of them actually know stuff. Others are examples of 20th century "Artificial Intelligence." (Got briefed by their staff.)
EDIT: Finding more evidence for convergence between scientific fields is also worthy. (Though the delta is very small at this point.)
I think a similar thing happened to journalism ethics over the course of the 20th century up through the 1st quarter of the 21st.
The XKCD counterpoint: https://xkcd.com/915/
(I think this shows how arrogant Randall Munroe can be sometimes. He does a lot of great stuff, but when he's wrong, he's egregiously so!)
https://lightsinthedark.com/wp-content/uploads/2013/06/ceres...
Proof that Tesla demand is up in July 2024: https://www.youtube.com/watch?v=dHiAIZsXT1Q
Fixed it for you.
Dude, if you say the flow in the diagram is not executable, blanket in any fashion, then are you saying all of the programming projects you've been in are either monolithic systems, or have all failed?
The power of visual programming is diminished if the programmer aims to produce source-code as the final medium and only use visualization on top of language.
I disagree. We frequently break up large systems into chunks like modules, or micro-services, or subsystems. Often, these chunks' relationships are described using diagrams, like flowcharts or state transition diagrams, etc.
Furthermore, quite often there are zero direct code references between these chunks. Effectively, we are already organizing large systems in exactly the fashion the op is proposing. Inside each chunk, we just have code. But at a higher level viewpoint, we often have the abstraction described by a diagram. (Which is often maintained manually, separate from the repo.)
What exactly are the disadvantages here?
Misinformation. The good EVs are selling quite well. It's just that their price has effectively dropped quite a lot. My wife's Model Y which cost us nearly $80k (we bought at peak price: the prior Corolla got totalled) now has the equivalent 2024 model selling for $42k!
The crappy EVs (ie most everyone else's) aren't selling, because they are inferior in efficiency and software implementation. Rivian and Lucid vehicles are pretty good, but those companies are still at risk of never showing a profit. I've been in a Hyundai Ionic 5, and that seemed decent too.
Long term, here's what I suspect may happen. Robotics+AI is going to eat the lunch of VR. VR is only used when it's not economical to have the actual stuff, but the realm of nifty real world stuff is going to expand tremendously.
This may well result in a societal bifurcation, where the rich have a bunch of robots, and the poor have to settle for VR.
What is the TAM? Would it be worth it?
However, considering that the Hubble was developed from spy satellite tech, could this also happen in reverse? What uses would a 9m mirror telescope have in terms of ground observation? Would the US government allow such a thing to go up and be available for hire?
Tons of things like this were built in Smalltalk. (Including a UI->Domain model connection layer in the IBM VisualAge Smalltalk IDE.) They all had scaling problems, especially, "they don't seem to scale cognitively."
It's not as if the problem doesn't exist in most codebases. It's more that the problem is invisible without such tools. Tools making the tangle visible make themselves seem unusable.
The fundamental problem, is that we don't have ways of introspecting these horrendous relationship graphs for specific contexts. If IDEs and other programming tools generally could create custom browsers/IDE windows for things based in queries like:
"All of the methods that contain references to ClassA.Member1 and ClassB.Member2 which also call function Y."
...where this query can be modified or further specified at runtime. Then there could be specific built in queries that cover everything touched by canned refactorings. Then these further could be intersected or unioned.
EDIT: Forgot to complete my thought. If the graphical diagram could show contextually relevant slices of the system, it would greatly cut down the confusing web aspect of the diagrams.
The problem with that method of evaluation, is that it's not First Principles. Basically, pg's essay in this case just reduces down to, "Is that person steered by First Principles thinking?"
Is there an analogy for media and information?
> For now.
Like everyone's music and movie collections.
If this artificial advantage allows Apple to slack off in their other areas of competitive advantage, then this is bad for the consumer, overall. This creates an environment of cynicism, where there's even degraded incentive to try and beat Apple with a better product.
Beyond some threshold, any meta-gaming of the market is bad for the market. It's like patents. When they were first instituted, they did some good by incentivizing innovation. Then, people started meta-gaming them, and used them as legal weapons to suppress competition well beyond the original intention.
I don't think there's a good argument that monopolizing a feature is good for the market, even if the means that allows it is technically legal.
What could be argued, is if legal remedies to this kind of meta-gaming might also be meta-gamed in return and become worse than the thing they were trying to remedy. This seems to always happen in a variety of forms.