Forgejo and Codeberg I look at as more like hobby projects. I would not trust them with my code.

The most innovative teams I've worked on implored, and maybe incentivized, periods of reflection and evolution of ideas. Often we built POCs along side that evolution. They'd often juggle many different new ideas. Each, often, had its own evolution. Whatever shook out is what won and we often had pivots in line if we needed them.

I think in general it's what Sam says it is: if you artificially force people to defend their ideas early on then you end up coming up with pretty mid ideas.

For example, I use Codex and Claude Code by default, but when I need to look at the API surface, read tests, etc I have those tools setup to open Zed. Zed is also rapidly evolving in the other direction, where it's closer to the tools that are opening it. It won't be long, I think, until I can continue my prompt from inside Zed.

These days I'm using Codex and Claude Desktop with Zen when I need to look at code. Codex's real time audio chat feature (not dictation) is also second to none when paired with their agentic flow.

Investors can be good for funding but they can also be good for education. Later, they're also very good for strategy.

> What happened to the good old way of figuring out product market fit first? Is that the only way a product can succeed nowadays

Generally it's very challenging. I have two products I'm building this way and you face a lot of up-hill climb where people with VC backing are getting the door opened for them. Of course, because of those same pressures to deliver and succeed, it's equally possible those same doors will eventually get closed on them.

I think Mitchell also lives in a bit of a bubble now. He went from friendly open source guy to very rich friendly open source guy. That's no knock on him, but I would consider viewing business from the perspective of someone who has been a CEO, CTO, and IC at the same company (his company) as his only job who became insanely wealthy as a result. I have a friend who has largely only worked in big tech, and successful startups, who tells me all the time level and salary don't matter to him. They don't matter to him because he found success early. Again, not a knock but sustained success will shape how you view the world and how you play the game.

He also has a lot of posts since: https://mastodon.social/@gedankenstuecke@scholar.social

Society hasn't felt the very real effects of data centers until recently. Power supply being short meant that residential customers have had to pick up the tab for heavy industrial users. We've started to learn just how bad all those dams we built are for the environment and many of them are tied to data center money. Elon Musk waltzed into Memphis and stood up a natural gas data center that has basically poisoned the surrounding area.

Maybe nation state actors are helping, that can always be true. It is also true that the American people are starting to realize they've been had many times over and are just starting to ask for a better deal. I think we should listen.

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.

I think this is a bit of a generous reframing of what seeking perfection is. Generally I think perfection seeking is best described as over-focusing on the details and pre-planning instead of laying a general blueprint that leaves room for pivots, future decisions, and iteration along the way. There's a whole breed of engineers that are really great thinkers but get stuck in the mud trying to pre-think the best way to do something instead of being adaptable.

I think it's a way some businesses just do business and the market has not issued a correction to that. Maybe it should?

One of my earliest internet experiences was with mIRC. I always admired its straightforward, pleasant UI and the way it wove a hackable core into the code. The way you could build on the visual and API layers of the underlying IRC client to me was fascinating software machinery. It was truly a client that you could build on top of.

As my career has progressed, I moved away from Windows and adopted Linux as my daily driver. That was where I found HexChat, the closest thing I could find to mIRC many years later. While I really enjoyed HexChat, it wasn't quite what mIRC offered. I eventually found myself on macOS with no clear analogue to either. That's why I built Cascade Chat.

Cascade is a modern IRCv3 client. It supports persistent local history with full-text search, network management, replies, typing indicators, link previews, pinned messages, native notifications, SASL authentication, server-time, chathistory, account and away tracking, and the ratified IRCv3 capability set.

I also wanted Cascade to be hackable, so I built in two fundamentally different layers:

- Scripting powered by Go scripts for personal automation, event handlers, and timers. Scripts run in-process with no access to the standard library, filesystem, or network. - Plugins that communicate over JSON-RPC and can be written in any language as external processes.

Stack-wise, it's a Go application built on top of Wails v3, which leverages the OS's native WebView to render modern web tech frontends as desktop applications. The result is an Electron-like experience without packaging a separate Chromium runtime.

Full disclosure, since this is HN: I built Cascade using agentic engineering. I made the product and UX decisions, designed the architecture and code interfaces, and I reviewed and dogfooded the resulting work. Coding agents implemented much of the space between those decisions.

To further ensure consistent quality, I built gates around that process rather than treating generated code as finished. I focused on unit and integration tests, full-stack end-to-end tests against a real IRCv3 server (Ergo), automated release candidates, and regular dogfooding of the prerelease channel.

Cascade is open source under the BSD 3-Clause license. Prebuilt packages are available for macOS, Windows, and Linux. The current builds are unsigned, so macOS and Windows require a first-run confirmation step that I've documented in the README.

I'd love to know if you'd make Cascade your daily IRC client, and if not, what that'd take! Feedback and PRs welcome.

Comments URL: https://news.ycombinator.com/item?id=48908099

Points: 8

# Comments: 1

I am curious whether this FDE direction will result in more product and platform complexity that is more difficult to unwind.

https://judi.systems/shirei/

Known Issues & Limitations

The following are known issues and limitations that we plan to tackle:

    Large text blocks will kill responsiveness! Use the LargeText widget.

    The widget catalog is aimed at developer tooling, not general consumer polish: no rich text, tree widget, or date picker yet.

    There is no robust theming system. Some widgets take an accent color; custom button styles mean implementing your own (the stock Button is a usable reference). Styling can still be verbose at times.