Posted by ryanmerket 5 hours ago
As a small startup I'd love to ditch Slack, as its a walled garden and both under-featured and over-complicated at the same time. GitHub has been losing my favor too.
Tangentially our startups is combining email, AI agents (chat and coding), and GitHub workflows and it feels really good.
https://housecat.com/blog/gmail-durable-workflows-sandbox-vm
It feels like a renaissance for all workspace tools, where up until recently it was mostly dev tools that got all the really fun power ups.
> Buzz is built around a self-hostable Nostr relay. Every message, reaction, workflow step, code event and approval is stored as a cryptographically signed event. Human employees and agents receive the same basic identity structure, including their own key pairs, channel memberships and audit trails.
I don't see a lot of information about the Git hosting aspect of the product on the website, though. Somewhat doubtful that they will be able to make a Git forge with similar polish to GitLab
It subjectively seems to me that integrating with an existing forge (e.g. Forgejo) on the API layer and rebuilding the auth and frontend is a better bet. You get stable features like PRs, permissions and CI actions out of the box and they stay synced with known formats in the community and so make your tool easy to adopt. Though making a forge from scratch does have advantages especially for internal company use cases.
Another problem I see with Buzz is that the tool doesn't seem to be taking advantage of its vertical integration inside its UX enough. There is a lot more you can do with full control over Git hosting, project context, and org-wide chat in a single tool than what this tool attempts to do right now.
There's a brief write-up on Buzz here https://engineering.block.xyz/blog/buzz
> It’s great and works really well for us, but it raises lots of questions. Does everyone get a bot? If people share one, whose credentials does it use?
Eventually you throw in this admission in the middle of other stuff:
> Buzz gives each agent its own key. The agent’s owner signs a narrowly scoped authorization. The agent then signs its own work with its own identity.
So you're explicitly picking a bot per person, you're just calling them an agent. But you never really admit this because you call it 'an agent' rather than "the user's agent". You're still ending up with lots of agents each owned by people, you're just writing another orchestration layer yourself.
> The agent remains the author. Its credential proves who authorized it and under what conditions.
Right yeh, so the human is the responsible party.
> If an agent key leaks, revoke the agent without replacing the human identity behind it.
Just like you revoke an app-key on GitHub/Slack. This isn't a revolutionary thing you're doing.
You then throw in this curveball.
> Buzz can also run an agent’s model requests on another community member’s machine.
How? How is this resource managed or limited? Do I have to assume Buzz will just borrow my laptop's CPU & GPU at random?
> So you're explicitly picking a bot per person, you're just calling them an agent. But you never really admit this because you call it 'an agent' rather than "the user's agent". You're still ending up with lots of agents each owned by people, you're just writing another orchestration layer yourself.
Giving everyone their own agent/bot/app in Slack is nontrivial because of how Slack apps work. If you're okay with them impersonating you, it's easy, but that's weird and I don't like having to guess/discern if I'm talking to you or a bot wearing your face
> How? How is this resource managed or limited? Do I have to assume Buzz will just borrow my laptop's CPU & GPU at random?
This is opt in. It's an integration with https://github.com/Mesh-LLM/mesh-llm that scopes shared compute to your Buzz community. This is very early right now and we're working to get it right. But the idea of a totally self-sovereign, self-hosted community providing its own inference is exciting.
I think this is an unclaimed space where the future of work is bound to find itself in, though I'm not yet sure how/who is gonna win.
My solo project was abandoned unfortunately, that said I saw some cool protocol initiatives similar to it recently like this one: https://github.com/h5i-dev/h5i