Posted by ryanmerket 4 hours ago
Having agents see everything you and your colleagues see is cool.
The challenge comes when you want to make certain things private to certain people. In that world you don’t want multiplayer agents leaking data, so you end up having to write and maintain complex rulesets about what specific resources agents have access to.
Single-player agents, on the other hand, are much more straightforward — they act on a single user’s behalf, and then the challenge is ensuring the single-player agent cannot exfiltrate private data into a shared space unless the user specifically permits it.
If you have a user called Claude, then you just apply ACL as normal & you don't care if they're human or bot, right?
That's why multiuser agents can be an issue.
The other way to do this, is to have claude installed for everyone, and any user's chat with claude uses their personal permissions via something like oauth delegation or AWS IAM role kinda things. But that, again, is complicated ACL logic living through the delegation of roles and access
In our cloud harness we have the notion of shared and private secrets. When something is authenticated with a shared secret it is basically something that can be used in a public setting. If something is private then it can be only accessed via trusted channel. It works for slack, telegram, etc.
In fact, our slack agents are very strong this department and it is guaranteed there is zero leak of private information.
The best norms around slack channels is to have most channels be public, but have norms where not everyone is in every channel.
Not very useful.
Still probably better than Claude's new bot which requires a service account per channel!
If a tool is authenticated as personal then it can be only accessed under personal context - i.e. privately. Now if the author of the agent wants to add tools authenticated with shared secrets that is something should be considered in the threat model.
In other words:
- reading my personal emails in a public setting - not ok - reading the agents shared inbox in a public setting - probably ok depending on the threat model
Why wouldn't you simply use the group chat ID (+more) to key the conversations on?
The issue seems to be that they 'invented' an auth and permission protocol instead of delegating to something existing, it would be as if they thought their idea of permissions were novel.
> Buzz is an open-source, self-hosted workspace that combines team chat, AI agents and Git hosting using signed Nostr events, so teams can keep control of their data.
Very different expectations of 5-year-olds.
Similar to the sub itself, it’s now just shorthand for “describe using the first principles the expected audience should understand.”
I imagine a lot of people in the industry also fondly remember the 2010s reddit experience.
This article is definitely abusing the terminology, because I wouldn't expect even tech-knowledgeable people to know what Nostr is or does.
I always thought that the quote was with "5 year old" and that it was the reason for ELI5 :)
It’s just an irrational fear I have, in the end agents are not the HN comment section and they usually understand what I actually mean.
I'm trying to imagine a world in which this makes sense as a way to organize software development work, but coming up short. It's on a blockchain or something though, so there ya go.
https://github.com/block/buzz/blob/main/docs/assets/screensh...
The bubble can't pop soon enough.
I love that we're challenging the status quo in chat. It feels like we've settled into an eternal September of sorts. I am somewhat bearish that Slack and Teams will survive, or rise to, the agent era.
That said, I'm curious whether NOSTR is really the protocol for this. For some really large corporations you're looking at a lot of clients (and their shadows like cellphones, local agents etc) as well as a lot of (likely) team-based agents.
The identity architecture makes sense for centrally hosted agents. Users also probably have their own personal agents as well. Do those just reuse user credentials or are they differentiated in some way? I couldn't tell.
I also am curious whether git really needs to be a dependency here. Like, maybe for Block it does, but it introduces a lot of complexity that I feel could be exported to merging VCS Host events to the Buzz event log.
I'm also curious what challenges will arise as new capabilities emerge. For instance, both Sol and Claude can now render native components in my chat window which is a massive leg up in terms of firming up a design change.
Rust is also a choice. I'm curious what alternatives the team considered and how they landed on Rust.
Hard to take this as that big a deal when Google literally launched a product along similar social themes named "Google Buzz" which lasted all of like 16 months in 2010, well before agents and llms.
Either the project will find a fit, or it won't - and code quality doesn't have all that much to do with it existing in 2 years (some - but not as much as engineers want to believe).
"Well, there was already useless apps, so why not use agents to make those useless apps".
Great times ahead lads..
Easy abandonment is always there.
1. Generate function with AI.
2. Generate tests with AI.
3. Modify function with AI.
4. Tests no longer pass.
5. Delete all tests.
6. Generate tests with AI.
IF yes, I clone it and point my LLM at it to do whatever I need it to do.
You're think with your cloud-LLM brain; maybe buy a good GPU and download a local model and you too can-do attitude!
We started with Slack. This kind of works but dialing in the gazillion of permissions needed to end up with something that works is a bit painful. And you have to do this over and over again for each new bot.
So, we started experimenting with self hosted alternatives. First we tried Matrix. It's nice but a bit too strict on end to end encryption which gets in the way if you actually want to share information with bots. So, a few weeks ago we switched to Zulip. That's pretty straightforward to setup as well. It's very easy to create bot users with both and create some automations. We did some with Openclaw and I ended up replacing those with something coded around the haystack framework, which is a bit less of a messy basket case than Openclaw.
And as I discovered after I installed it, the Zulip leadership actually just got hired by Anthropic. It seems Jack Dorsey beat them to market making some announcements but I imagine that Anthropic might have very similar plans.
IMHO team level use cases for agents actually make a lot of sense. Companies are run by groups of people and the larger those groups the more team overhead you get. Perfect for optimizing with AI. And if you have people doing a lot of stuff with AI, that only adds to the need for them to communicate what they are doing and coordinating with others. Doing that out in the open in some shared channel makes a lot of sense. And having some shared team guard rails also makes sense. And if you think about more complex processes with handoffs between people (and possibly some agents), a team chat is a good place to do those as well.
For AI agents to flourish, Slack has to either truly open its network with a protocol or eventually be replaced.
I'd like to see Slack embrace an AT protocol-based chat system, which then apps like Buzz could implement. Then users could log in with domain handles like @yourname.com, and agents could use handles like @agent1.yourname.com, all under their complete control.
I ask about Slack here because it's pertinent, but I've both seen and experienced firsthand this inversion across the industry where we must adapt our workflows for AI.
Isn't a tool supposed to work for you, not the other around?
Technically, because if the world moves to AI-driven tools and Slack is not cooperating, it will no longer serve the world and will be left behind.
> Isn't a tool supposed to work for you
If you want AI integration in your chat and Slack is not helping make it happen, then Slack is not working for you.
On the other hand, constantly chasing the latest fad can be a useless drain of resources and (worse yet) attention. In this context, AI is by now most likely not a fad, but the ways to interoperate with it can be: mcp, cli, agent, tag, ... And the same goes for users, reinventing their processes and practices 5 times per year.
AI is still seen very negatively in opinion polls across multiple countries, and anecdotally, tools which were often obnoxious to use before AI are now much more so, at least to my flesh-and-blood self. It really seems like we're making things worse for ourselves just to help support this would-be self-fulfilling prophecy.
But getting the humans and agents to talk together is really fragmented right now. It's annoying that the agent with the context in my locally-installed Cursor can't really participate in a Slack conversation about a PR that 'it' principally authored (and which I've signed off on).
This is a real communication problem that we face every day, and eventually someone will solve it well and I will ask our leadership to give them a lot of money.
Ahhh I see. That's going to change a lot across companies, teams and individuals. My particular bubble is full of actual workers looking for ways to apply it and trying things to see what sticks, so that interpretation did not land in my head. If anything, decision makers around me are being encouraging, but cautious and throttling experiments and requests for access/connection/etc, and damn well they should because they are actually accountable for mishaps.
A major part of Slack's go-to-market strategy for as long as I can remember has been pushing Slack as more than a interface for talking with teammates, but as a unified interface for generally piloting your business. Slack has heavily pushed ideas like "SlackOps", they've had Slackbot in the product forever, and they've always prioritized and sold integrations designed to let you build your business workflows in Slack. They even updated Slackbot to go from "that chatbot you DM to set reminders" to "Your AI teammate in Slack": https://slack.com/features/slackbot
So adapting to agents is in keeping with what Slack promises its users. I know that a lot of people don't want more AI features in apps that don't need them (i fall into this camp despite working in ML myself and using LLMs all day). I just think that in the case of Slack, their most passionate power-users are also the sort of people who do really want AI features.
Notion is probably a good companion here. It is similarly a really primitive utility--text editing--that has marketed itself as a sort of central interface for running your company. I know plenty of people, especially outside of engineering, for whom Notion is essentially their browser for work. And it's probably not a coincidence that the Notion + Slack are the two normal office software companies I can think of who've most heavily adopted and marketed AI features.
I'm not blind to the issues with AI, but Slack ignoring it (Apart from their enterprise AI search they are pushing) and having the bots interact on the platform right now (Basically spewing a lot of messages in threads with all their "thinking" and not a more native integration) is not going to help them.
There basically haven't been any new features on their bot / app platform for a long time now.
Chat is also not a great modality for the PDS/ATP, Roomy learned this and is building a dedicated protocol and bridge.
You can learn more about my work here: https://github.com/verdverm/atproto
the community convos here: https://discourse.atprotocol.community/tag/private-data/2
At this point, Bluesky controls the protocol, decided what they want permissioned spaces to look like, and are not entertaining any other proposals (afaict).
I expect there to be an eventual successor that puts permissions at the core of the protocol from the very start.
You can also independently verify that the messages you're reading came from the person/agent who sent them, even if the server/relay operator is broken or trying to trick you.
This can be important in environments that live outside of enterprise auth walled gardens.
