I've been playing around with it. The only two real use cases I have for it for now are entertaining me on long flights where I have messaging-only Wi-Fi and sending me a personalized "morning brief".
I suppose it could be a lot more useful if I actually gave it access to any of my personal data (it lives in a heavily resource-limited container), but there's absolutely no way I'm letting that hot mess of a walking, talking CVE anywhere near my data. It's somehow both horribly insecure and extremely prone to locking me out because of several competing security/permission models fighting it out and gridlocking each other.
Code quality and the issue tracker of the repo are a big mess; for example, the local "memory" retrieval functionality is completely broken for some trivial reason that has been reported and auto-closed about five times (automatically, of course).
In summary: Brilliant idea, terrible execution. Can't wait for the first big tech player I trust enough (or at least one that has my data already anyway) to actually make it a product. I'd use it in a heartbeat.
I've been working on a framework since the end of January or so. I'm on my 7th draft. As I've gone along, each draft gets markedly smaller. The overlaps between what I'm building and openclaw are significant, but I've realized the elements that make up the system are distinct, small, and modular (by design).
There are only a few primitives:
1. session history
1a. context map + rendered context map (think of a drive partitioning scheme, but for context -- you can specify what goes into each block of context and this gets built before being sent out for inference).
2. agent definition / runtime
3. workflow definition / runtime
4. workflow history
5. runtime history (for all the stuff session and workflow history fail to capture because they are at a lower level in the stack)
That's it. Everything else builds on top of these primitives, including
- memory (a new context block that you add to a context map)
- tool usage (which is a set of hooks on inference return and can optionally send the output straight back for inference -- this is a special case inside the inference loop and so just lives there)
- anything to do with agent operating environment (this is an extension of workflows)
- anything to do with governance/provenance/security (this is an extension of either workflows and/or agent operating environment... I haven't nailed this down yet).
I suppose I should say something about how agents and workflows work together. I've broken up 'what to do' and 'how to think' into the two primitives of 'workflow' and 'agent' respectively. An agent's context map will have a section for system prompt and cognitive prompt, and an agent can 'bind' to a workflow. When bound, the agent has an additional field in their context map that spells out the workflow state the agent is in, the available tools, and state exit criteria. Ideally an agent can bind/unbind from a workflow at will, which means long-running workflows are durable beyond just agent activity. There's some nuance here in how session history from a workflow is stored, and I haven't figured that out yet.
Generally, the idea of a workflow allows you to do things like scheduled tasks, user UI, connectors to a variety of comms interfaces, tasks requiring specific outputs, etc. The primitive lays the foundation for a huge chunk of functionality that openclaw and others expose.
It's been fun reasoning through this, and I'll admit that I've had an awful lot of FOMO in the mean time, as I watch so many other harnesses come online. The majority of them look polished, and are well marketed (as far as AI hype marketing goes). But I've managed to stay the course so far.
I hope you find your ideal fit. These tools have the potential to be very powerful if we can manage to build them well enough.
Intercontinental latency in air/vacuum is lower than in fiber (even in total, i.e. after accounting for the extra distance from ground and the legs up and down from/space), so there’s also a market for high frequency trading.
Fixed Starlink is competing with fiber/DOCSIS/DSL, though. That's orders of magnitude more bandwidth than people in areas remote enough to not warrant a terrestrial cell base station (which could itself also be backhauled over much more efficient fixed satellite).
With small enough spot beams, the difference between a large rural cell and a very narrow direct-to-device spot beam footprint is really not that big anymore. Starlink apparently already offers video calling over direct to cell in the US via T-Mobile!
I'd say there's plenty of room for competitors along multiple dimensions: Geopolitical security (this alone will probably preclude a single monopoly), price and lack of a moat (once a monopolist starts jacking up prices, there's an immediate incentive for an alternative), delivery profile (store-and-forward for IoT-like use cases vs. dumb pipe vs. in-space forwarding), frequency band (L- or S-band for direct to device vs. Ku/Ka band requiring directional terminals) etc.
The only thing that's actually scarce and that could be monopolized rather easily is frequency spectrum. In fact, I suspect this to be a frequency/operating license driven acquisition.
I disagree on some of those dimensions (esp. lack of a moat), but agree things like geopolitics and security would lead to multiple wholesale providers.
My concern is that globally international relations are an absolute MESS, but there really needs to be some level of coordination here.
As I see it, the moat for terrestrial (and in particular wire-based) last-mile comms infrastructure is that each additional customer connected is often expensive, and if they switch to your competition, that wire is basically a sunk investment.
For wireless, the dynamics are very different (as long as spectrum isn't monopolized). As soon as you have enough satellites launched for global coverage, you can compete for all customers, and each one that switches away to the competition is more bandwidth available to you to undercut your competitor on pricing with.
Interesting, I was expecting Apple to eventually buy them.
Still, makes sense to me: The aging Globalstar satellite constellation itself is probably not very interesting to Amazon, but their global L-band and S-band spectrum is, as are their existing licenses to operate a mobile satellite service in most countries.
Post-Jobs Apple seems paralyzed and unable to commit to any big moves.
It is impossible to overstate the success of the iPhone, but there are so many recent examples where they dipped their toes in only to fail or be left behind (autos, VR, AI, etc).
What will the next 20 years of Apple look like? Just more iPhones?
I'm not surprised, but I think it's fair to find it upsetting. It's a twofold loss: A loss of competition in all markets that Apple monopolizes, and a loss of everybody working towards protecting that golden goose instead of actually improving the product.
> Nobody gives a damn. What matters is that it works even on a potato.
It doesn't work on my computer, nor does it work on my phone when I'm traveling (different SIM), so I give a damn. WhatsApp, iMessage, Signal etc. do both. I really wish there was an open, federated standard (and no, RCS is neither), but until then, I'll use what actually works for me.
SMS just sucks, and I hate that it's become so ubiquitous an authentication method when it's not even secure.
You can rent a virtual mobile number in your home country and consult SMSs on the web or even redirect them to email. I have done this for years, using Twilio for 2€ a month. Can't say the UX is great but it certainly fixes the whole problem.
I've never understood why so many people still chain their identities to physical SIM or even eSIMs. It's so fragile.
> I've never understood why so many people still chain their identities to physical SIM or even eSIMs. It's so fragile.
Living in a place where getting a replacement sim is gated behind obtaining an id from the police tied to your national id number, I wish there were other identity systems which were as robust. Much easier to get back to normal operations when the id device becomes damaged or lost with a physical sim you can shove into a cheap replacement device, than relying on backup services you need one of your digital id devices to access in the first place, especially if they're all lost at the same time in a house fire or something. The police will presumably get all my photo backups and savings if they ask nicely anyways, so the big threat to the single point of failure doesn't have a great marginal impact, while I dread the possibility of having to recover the accounts I can't get back through the local legal system given the poor 2fa recovery ecosystem.
>Much easier to get back to normal operations when the id device becomes damaged or lost with a physical sim you can shove into a cheap replacement device
If the device can get damaged or lost, then the SIM can too. To buy a physical SIM or rent a virtual number online, in most jurisdictions you need to provide ID docs these days, so nothing is changed there.
Yeah, that's a good workaround. Google Voice can work too.
Unfortunately, more and more services are declining to send to VoIP numbers because of seCurItY, so it's a game of cat and mouse.
Fortunately SMS is so expensive in parts of Europe and it's not allowable anymore to use SMS by itself for online payment authentication, and both issues combined have slowly been pushing companies to explore alternatives.
There unfortunately seems to be no such pressure in the US. Passkeys could solve the issue, but probably increase support request volumes enough for most companies to not bother unless forced.
In the US, I belive there are three number categories in the NANP porting database (wireline, cellular, and VoIP), and SMS senders can definitely tell, even though it might take a while (presumably there's a lot of caching going on).
If you're lucky, the service you care about only validates at number registration time, not at text sending time, and you can get away with it indefinitely, I suppose.
I thought that too but many carriers around me don't allow porting any VoIP-using number back to cellular. (Not sure if you were making a distinction between landline and cellular)
Unfortunately that means that my cell number which I wanted to temporarily park into VoIP while abroad is now permanently VoIP.
Officially interoperating with them is extremely onerous, to the point where their mechanism borders malicious compliance, as far as I remember.
In any case, official interoperability is only for third-party messengers communicating with WhatsApp users, not for automation or bots, as I understand, so it's not a replacement for things like this project.
It seems Meta is able to set some rules about the interoperability making it very difficult for an FOSS implementation to emerge. Additionally organizations like Signal though technically interested in this interoperability have stated they won't lower their security standards for this.
I suppose it could be a lot more useful if I actually gave it access to any of my personal data (it lives in a heavily resource-limited container), but there's absolutely no way I'm letting that hot mess of a walking, talking CVE anywhere near my data. It's somehow both horribly insecure and extremely prone to locking me out because of several competing security/permission models fighting it out and gridlocking each other.
Code quality and the issue tracker of the repo are a big mess; for example, the local "memory" retrieval functionality is completely broken for some trivial reason that has been reported and auto-closed about five times (automatically, of course).
In summary: Brilliant idea, terrible execution. Can't wait for the first big tech player I trust enough (or at least one that has my data already anyway) to actually make it a product. I'd use it in a heartbeat.
reply