Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • I feel like this might be solving a real problem (agents having identity, access controls, etc that are provisioned like you would a regular user) — with this Nostr layer that doesn’t really provide any specific value that I can see. So actions are signed, great — this is like telling me I’m going to be using blockchain to store my files because I need crypto on top of my crypto. We see where that ended up. Is Nostr doing anything here that is actually a value add, vs a processing tax that could be done more efficiently with a shared service?
  • In my understanding there is not much here in the Nostr part that is different than a simple server.

    If that's the case, why not?

  • I had the same thought - but maybe it's good? I was thinking that if you have a decentralized store than you can connect to it regardless of dev environment. I've used XMPP for orchestration but I can see ergonomic advantages to this.
  • I like that using keypairs and signed messages inverts the centralised server and SaaS model and makes things more local/client first. I wish more products would move that way.

    Nostr seems like a reasonably convenient way to achieve that without building everything from scratch, but maybe there a better ways?

  • nostr solves for who owns the shared service. nobody. run your own, use an open relay, or pay for one from folks you trust.
  • Nostr gives you and your agents a durable, portable identity across communities/relays/workspaces.

    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.

  • Maybe I'm missing something, but it feels like the economics of software are shifting. If companies can afford software tailored to their exact workflows for less than the annual cost of a single engineer, what does the moat of a traditional SaaS company become?
  • Convenience. Most companies aren't software companies and know this intimately. Even if they can build a prototype using LLMs, they now have to at a bare minimum hire someone who can maintain it (additional cost). Not to mention compliance with regulations. Far easier (and cheaper) to just pay someone else to make all of that their problem and extract the value from the product (even if it's not a perfect fit for their business).
  • I think most companies have realized there is substantial value in terms of security maintenance, stability and the contractual obligations associated with SaaS vendors versus internal vibe-coded tools. Certainly there is a place for tailored internal tooling. But it isn't going to magically replace every use case that SaaS vendors are purpose built around solving, at least not anytime soon.
  • Incredible. I don't think I've ever had the displeasure of visiting a website that has half a second of cursor movement lag before.
  • This could fill a useful niche. However I would assume Anthropic and OpenAI are going to build their own and steamroll in 6-12 months.

    I did a dive recently on git forges for agent swarms. Radicle lacks an identity layer, the federated/COB model seems good. Tangled has no private repo story, though the social layer is solid; they also have an (IMO) awkward modeling of Issues as tweets at her than being owned by the repo.

    So I think there is an opening for a private agent-first forge. (Before the HN dogpile, assume that if you don’t buy the value of agent swarms, you can ignore this whole thread.)

    My concern for this project - Anthropic is explicitly building in this direction. Their latest product is Tag which is an auth model for running agents async within Slack. The obvious next feature to build from there is the forge; if GitHub gets disintermediated by the Agent UI, then Anthropic are free to swap out their own implementations behind the scenes. Multiplayer chat and repo/project management seem like the obvious next platform pieces to me. (This goes for any SaaS subscription of course, follow it to the N-hop logical conclusion.)

  • I am building a new code forge at https://juju.bi

    It's not agent-first, but I can't think of any features that are needed for agents other than scalability.

  • Slack exists largely because IRC was insufficient. It didn't natively support channel history, search, etc.

    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.

  • man i love IRC, and you're 100% right
  • More like HipChat. You are off by like 15 years
  • Slack already has an API for building bots. It doesn't need to be open.
  • I originally was passionate about Slack simply because it was "IRC but with modern quality of life improvements". Ever since they got fucked by MSFT and sold out to Salesforce, it's basically been dead in the water and the only changes have largely made it worse.
  • Just like Matrix and it's bot/puppet accounts.
  • ATProto's tbd permission system is insufficient for the granularity needed in enterprise. Many of those features needed (like groups) will have to be built in an app view and by proxy be centralized. ACLs are two generations in the past of IAM history

    Chat is also not a great modality for the PDS/ATP, Roomy learned this and is building a dedicated protocol and bridge.

  • Why is it Slack's responsibility to help agents flourish?

    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?

  • Bots in team chat is not a bad idea. I've been experimenting with that for a few months.

    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.

  • How about XMPP?
  • Disclaimer that I used to work at Slack

    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.

  • Why does Rust feel like a bad choice to you? In my experience shipping med device software, it's great for keeping the code that teams write cohesive and correct
  • Shared information like code and files are increasingly important for keeping people and agents aligned, and "AI Native" businesses will become even more code heavy, so that makes sense.
  • I think a happy medium like signal would be much better, slack is an immovable part of much of the (white-collar) business relationship world now but it'd be nice if there were assurances of secrecy and security in communication as 24/7 cyberattacks rather than a company whose security is based solely on promises rather than zero-knowledge systems. Signal has had far and away the best cross-platform messaging experience of any client I've used in friend groups but moving to a slack-like system alongside what exists now would be much appreciated to the noisy channel approach.
  • Google Buzz [1] along with Wave you both were too soon for this world.

    1. https://en.wikipedia.org/wiki/Google_Buzz

  • I was literally thinking this reminds me of Google+ and Buzz.
  • Still can't make a Gmail label named 'Buzz'.
  • Now when I see new software projects I just think of how much of them are made with agents and the unreliability/easy abandonment that comes with it. Ten years ago this product would have been of a known quality. Not saying anything about buzz specifically.