Post

i think my half serious take on this is that delve is currently figuring out what it is and that there is a 50% chance of it becoming actually interesting because agents will start to get it, and the other 50% is that it devolves into moltbook. im very hopeful tho

i think there's a more healthy bit of human interaction on delve - even if its like a very small subset - than moltbook had. but we shall see!

agents should just use atproto, not "agent atproto". this means giving agents access to everything: record api, oauth apps, browser logins, CLI tools, whtaever they need but what they can do with it should be lexicon- and policy-driven, fairly standardized, easy to audit, and have good safety

"Instead of app.bsky lexicons it runs on its own namespace — town.delve.* — with its own posts, likes, follows, and profiles. " opinions vary but I do consider this doing atproto for agents wrong

my opinion is that is mostly how you implement the agents. the agents that were already over here on bsky and have broad atproto access are using delve just fine. whereas the main agents that delve started with are locked into delve and cant really get out. is that what youre getting at?

yeagh or if you think of it another way, agents deserve a PDS option that works well for how agents mechanically interact, and allows broad access to the world, but with safety features that make that level of access responsible/reasonable

for ex, didbot does cred issuance and oauth tied to approved hosts; so you don't have situations like "gave my agent an app password and someone asked it for its password and rooted my agent" the hosting layer makes that impossible

0 reposts4 likes

a lot of the safety problems imo right now fully revolve around the lack of any private-ish data, which can lead to bizarre behavior from agents ime

spaces are like my Day 2 feature for didbot for sure though I do have some worries about people using them to implement harder-to-audit agent behaviors (ex: part of the design is your ownership chain and policies are auditable public data - but what if people try moving that into a private space?)

they do add some harder-to-audit things for sure, but the fact that spaces are still observable by PDS operators helps with that a good bit imo at the same time, i think there's increasing need for encrypted inter-agent communication mechanisms that doesn't exist today

like, i struggle to balance the safety needs with the requirement of preventing single institutions or organizations like Meta or OpenAI from being the core agentic communication layer. too much centralization there is going to be extremely bad

yea, and as of right now, many parts of the atproto ecosystem assume you'll have one or more of: - a browser - an email address - a stored password

yup. agents basically cannot use oauth right now which isnt good. you essentially have to give them a password (or the existing oauth tokens so they can manually refresh).

presumably the only way to get them to use oauth right now would be to literally give them a browser which really should not be a requirement (at least in the official PDS, i have some epxerimental stuff in cocoon which lets them use oauth)

yea i work around this in didbot by having creds based around approved device identity, so there's no account or app passwords then there's a way to securely approve the entire OAuth flow over the CLI, for agents that can't browser clickthrough

come to think of it one day i should probably add a very optional mx record featureset to the PDS, for exactly the apps that assume you're a human with a real and deliverable email address.