<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: morphology</title><link>https://news.ycombinator.com/user?id=morphology</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sun, 03 May 2026 19:12:58 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=morphology" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by morphology in "Flue is a TypeScript framework for building the next generation of agents"]]></title><description><![CDATA[
<p>You're welcome to port anything over to those languages. LLMs can do it in a couple of days at most.</p>
]]></description><pubDate>Sat, 02 May 2026 22:45:37 +0000</pubDate><link>https://news.ycombinator.com/item?id=47991354</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47991354</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47991354</guid></item><item><title><![CDATA[New comment by morphology in "Wacli – WhatsApp CLI"]]></title><description><![CDATA[
<p>You're right, Matrix is a much better option than Telegram. I misread the thread as comparing Signal to Matrix.</p>
]]></description><pubDate>Thu, 16 Apr 2026 00:58:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=47787408</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47787408</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47787408</guid></item><item><title><![CDATA[New comment by morphology in "Wacli – WhatsApp CLI"]]></title><description><![CDATA[
<p>It's a bit less automation-friendly because the UX is not great when the bot doesn't have its own phone number (which costs money). I think it has better privacy, though. Matrix server operators can read message metadata.</p>
]]></description><pubDate>Wed, 15 Apr 2026 19:48:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=47784281</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47784281</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47784281</guid></item><item><title><![CDATA[New comment by morphology in "404 Deno CEO not found"]]></title><description><![CDATA[
<p>I defaulted to Biome for all greenfield projects a year ago, and at this point you would have to drag me kicking and screaming back to ESLint and Prettier. I also defaulted to Bun and still think Bun is leagues better than Node.js but I now have my doubts about its future after seeing the OpenCode devs consciously minimize their dependency on Bun for strategic reasons.</p>
]]></description><pubDate>Sat, 21 Mar 2026 18:58:43 +0000</pubDate><link>https://news.ycombinator.com/item?id=47470110</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47470110</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47470110</guid></item><item><title><![CDATA[New comment by morphology in "Astral to Join OpenAI"]]></title><description><![CDATA[
<p>That money is going directly to Jensen as quickly as possible to secure OpenAI's place in the delivery queue</p>
]]></description><pubDate>Thu, 19 Mar 2026 14:16:06 +0000</pubDate><link>https://news.ycombinator.com/item?id=47439893</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47439893</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47439893</guid></item><item><title><![CDATA[New comment by morphology in "Astral to Join OpenAI"]]></title><description><![CDATA[
<p>They do have a hot mess with traction amongst developers. Codex is far behind Claude Code (in both the GUI and TUI forms), and OpenAI's chief of applications recently announced a pivot to focus more on "productivity" (i.e. software and enterprise verticals) because B2B yields a lot more revenue than B2C.</p>
]]></description><pubDate>Thu, 19 Mar 2026 14:14:16 +0000</pubDate><link>https://news.ycombinator.com/item?id=47439865</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47439865</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47439865</guid></item><item><title><![CDATA[New comment by morphology in "Show HN: OneCLI – Vault for AI Agents in Rust"]]></title><description><![CDATA[
<p>Precisely. You absolutely have to ensure that random agents can't join your local network, which means you need a deterministic orchestrator or an AI orchestrator that only spins up a handful of vetted agents.</p>
]]></description><pubDate>Thu, 12 Mar 2026 20:56:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=47356988</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47356988</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47356988</guid></item><item><title><![CDATA[New comment by morphology in "Show HN: OneCLI – Vault for AI Agents in Rust"]]></title><description><![CDATA[
<p>I don't get the benefit. Yes, agents should not have access to API keys because they can easily be fooled into giving up those API keys. But what's to prevent a malicious agent from re-using the honest agent's fake API key that it exfiltrates via prompt injection? The gateway can't tell that the request is coming from the malicious agent. If the honest agent can read its own proxy authorization token, it can give that up as well.<p>It seems the only sound solution is to have a sidecar attached to the agent and have the sidecar authenticate with the gateway using mTLS. The sidecar manages its own TLS key - the agent never has access to it.</p>
]]></description><pubDate>Thu, 12 Mar 2026 20:32:00 +0000</pubDate><link>https://news.ycombinator.com/item?id=47356645</link><dc:creator>morphology</dc:creator><comments>https://news.ycombinator.com/item?id=47356645</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47356645</guid></item></channel></rss>