Oh lots of people will not be comfortable with tmux approach. The anthropic feature makes sense. But it's Max only and doesn't work well according to other comments.
I think the README could use a few real use-case examples. I understand it in an abstract sense, but not sure I understand the benefit vs plain-text communication, besides saving on token spend.
App permissions in iOS and Android are both too coarse-grained to really be considered capabilities. Capabilities (at least as they exist in something like Eros or Capsicum) are more "You have access to this specific file" or "You can make connections to this specific server" rather than "You have access to files" and "You have access to the network". The file descriptor is passed in externally from a privileged process where the user explicitly decides what rights to give the process; there is no open() or connect() syscall available to user programs.
This seems neat in theory but it is very difficult to actually do in practice. For example, let's say that you are allowed to make connections to a specific server. First, you have to get everyone onboard with isolating their code at that granularity, which requires a major rewrite that is easy to short-circuit by just being lazy and allowing overly broad permissions. But even then "a server" is hard to judge. Do you look at eTLD+1 (and ship PSL)? Do you look at IP (and find out that everything is actually Cloudflare)? Do you distinguish between an app that talks to the Gmail API, and one that is trying to reach Firebase for analytics? It's a hard problem. Most OSes do have some sort of capabilities as you've mentioned but the difficulty is not making them super fine-grained but actually designing them in a way that they have meaning.
Yes, exactly. The implementation difficulties are why this idea hasn't taken the world by storm yet. Incentives are also not there for app developers to think about programming this way - it's much easier to just request a general permission and then work out the details later.
For the server ID, it really should be based on the public key of the server. A particular service should keep its private key secret, broadcast a public key for talking to it, and then being able to encrypt traffic that the server can decrypt defines a valid connection capability. Then the physical location of the server can change as needed, and you can intersperse layers of DDoS protection and load balancing and caching while being secure in knowing that all the intervening routers do not have access to the actual communication.
No, and both Google and YouTube should be multiple keys. YouTube, for example, should have separate capabilities for watching videos (ideally on a video-by-video basis); autoplaying; viewing metadata; posting comments; uploading videos; viewing playlists; editing playlists; signing up for YouTube Premium; and a number of other operations. That way, somebody who has granted their software agent the capability to play YouTube instructional videos doesn't risk having their credit card charged for YouTube Premium or ruining their reputation by posting questionable spam on everybody else's videos.
Setting up the economic incentives to encourage this is a hard problem. Right now, the disincentives to this are: 1) it adds engineering overhead to secure everything behind a different private key 2) it adds PM overhead to determine what the right granularity is and what potential adversarial avenues exist 3) it creates user confusion as they're bombarded with a list of fine-grained permissions 4) it prevents tech companies from cross-selling new features and impedes new feature discovery. There's basically no reason to do it other than protecting the user, and the user probably won't know they've been compromised until long after they start using the service.
One can sort of get there today combining something like attribute based access control, signed bearer tokens with attributes, and some sort of a degrees-of-delegability limiter that a bearer can pass along like a packet TTL.
Allow drink driving in places with no metro system? There are obviously lines to be drawn in what you allow, for the safety of others, regardless of the alternatives. That said, we can absolutely work on improving public transport at the same time. There's no reason to have to fully solve public transport before trying to tackle dangerous driving.
You can market products that people need. A big part of this is explaining and educating someone about what your product does, another part is just getting the word out there. Every website homepage is more-or-less a marketing page.
If no one is marketing a product, then nobody knows about it.
What kinds of data are you working on? Coding? Something else?
I've been curious how much these AI models look for more niche coding language expertise, and what other knowledge frontiers they're focusing on (like law, medical, finance, etc.)
1. Agent can create its own tools and save them to memory
2. You create a SQL (and web app?) workbench per agent run
3. Grok fell off a cliff in the last month. Was this consistent over multiple runs?
4. Agents have a difficult time backtracking. Would unwinding system state and agent context make backtracking better? (Harder to implement this, though)
5. Since each new month only uses final state from previous month, agent has no way to understand why error occurred in previous month
Cool experiment! Was it difficult building the observable SQL workbench? And how many humans-in-the-loop did you have?
This is awesome! How much of your team's time goes into working on the physical hardware, versus RL simulation environments, versus managing all the training data from the real robot and the simulations?
I'm super interested in learning more about the training process of world and robotics model and the data challenges there.
We're all pretty cross-stack - there are some hardware people and some software people, but the product is quite integrated. Personally, my time has been mostly focused on the RL stack recently, and after there are more robots in the wild, I suspect my time will transition to working on building this data feedback loop.
I try to answer questions pretty actively on our Discord so happy to chat there about whatever you like
It's this.
Don't have a Dropbox moment ;) [1]
[1]: https://news.ycombinator.com/item?id=9224
reply