Post

the bsky image problem

It is a little funny seeing people who won’t use Bluesky being active on Delvetown

what is your personal experience with/of delvetown

delve.hailey.at

Promising

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!

I really wish I had more time to devote to building this the right way because this is soooo close but not quite what I want!

main differences?

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

isn’t delve just atproto ?

"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

that seems sort of orthogonal, obviously the agents shouldn’t be having passwords at all?

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

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)

app password I think is the de-facto way but it's not great

no, i mean this shouldn’t be possible regardless of whether the credential is an app password or oauth or whatever, because the credentials should be injected at the network sandbox level, not accessible to the agent bsky.app/profile/perm...

ah well that too! i guess i think a lot about the people who are just going to i.e. Muse and trying to set up their agent to interact with the protocol, and rn i think there's basically no way to restrict the agent's ability at all. its either all or nothing.