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

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

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.

0 reposts1 like

No replies yet.