For ideology it does matter who controls your system prompt? As a quick experiment over coffee this morning I took that last episode of @No Solutions , generated a transcript and ran it through a dialogue agent that runs a 10 round discussion between pre-programmed AI agents around a given prompt. In this case it was "What is the Underlying Philosophy of Sovereign Engineering based on this discussion between @PABLOF7z and @Gigi " Usually I run most things on Claude 4 Sonnet as it s great general purpose model, but i was surprised at how it seemed to crowbar into the conversation a bunch of AI safety viewpoints and ideologies that aren't necessarily in the source transcript. So I figured lets change out the model for the dialogue agents to Grok-4 and see what it does instead - does the ideology leak out still? Is it different? I actually think that Grok 4's first assessment kinda nailed it: > Sovereign Engineering seems like a mindset or movement for building tech in a way that's deeply human-centered, decentralized, and empowering—think vibing with AI and open protocols like Nostr to create tools that foster freedom, collaboration, and realness without the chains of big tech overlords. Full summaries from both agents and transcripts are available here:

GitHub

Two AIs Analyse No Solutions to extract the Philosophy of Sovereign Engineering

A simple client to call agents from Everest and Other Tools to deliver workflow interesting AI calls - humansinstitute/everest-pipeliner

Interesting to see how repeated calls back to agents can lead down a specific pre-programmed ideological path. I think I prefer models with ideologies close to my own, but the alternative is a good echo bubble popper 😉 My guess here is this is more driven by the system prompt / safety layer than the training.

It was a really solid moment whrn @MartyBent brings up The Mandibles to @balajis - Balaji jumps on "great book" and you can hear Marty shrinks audibly fearing for follow ups You can almost hear @ODELL enter the chat

Peak performance

I think I need to just get a mac mini running a bunch of VMs in Yolo mode 24x7

Built a weekend project to allow a couple of AI Agents to discuss a subject in a dialogue back and forth to see if they develop any new ideas. Have been feeding it my podcast transcript and using it to expand on ideas which has been very fruitful - some great ideas coming out.

I'm fairly convinced that predictability in implementation will trump raw speed in vibe coding. Speeding yourself up 8x and being able to maintain or continue building on something complex seems way more preferable than moving 10x and having to continually throw everything away

Its all about "Super Fast Waterfall" althoguh I think I prefer the term "slow code"as. methodology

The hardest thing about working with AIs is slowing them down and controlling them enough so you can actually focus and build something useful.

“Why did you want that table” 👀

I started putting our podcast transcripts into a dialogue workflow of AI agents picking out one idea and then work shopping on it, back and forth to take ideas expressed in the podcast and develop them. It is shockingly good at this and they've just arranged to meet up for 3 hours on Saturday to start running experiments 🤣 👀

Interesting talk on working with and promoting AIs for creative work. Didn’t expect to go down a “What can we learn from the Shamans” route but there we go :)

Sometimes Roo Code feels like "drunk writing" I guess the next step is to put together a toll for editing sober 😉

👀

If it’s “critical market infrastructure” it’s not “market infrastructure”

Mongo By Relays! It's cool that Nostr apps can be thin clients using Nostr as a free backend 😉 Sometimes though I just want a db to store some data that doesn't live forever on public relays where a boring offline DB would be sweet. Quick example project to implement NostrMQ as a simple access layer for MongoDB requests. -> No hosting, no api layer ephemeral keys for misdirection and encrypted responses. -

GitHub

nostrMQ/docs/mongobyrelay.md at main · humansinstitute/nostrMQ

A simple library to utilise nostr as an ephemeral (slow) message queue that allows you to connect different parts of an application via pubkeys - h...

-

GitHub

nostrMQ/examples/mongo-pilot-client.js at main · humansinstitute/nostrMQ

A simple library to utilise nostr as an ephemeral (slow) message queue that allows you to connect different parts of an application via pubkeys - h...

Learn to build. Don’t learn to syntax

NostrMQ - Composable Applications via Nostr Remote RPC Most applications force you into all-or-nothing trust relationships. You either trust a provider with everything, or you self-host. This limits our design space and options we have to deliver NostrMQ uses Nostr like a public message queue to decompose apps into separate components, each run by one or more groups, and links them together through remote RPC. Each building block can have the trust model that best fits the use case. e.g. let someone else run the client, LLMs etc but keep the signing logic on an isolated device in your house :)

GitHub

GitHub - humansinstitute/nostrMQ: A simple library to utilise nostr as an ephemeral (slow) message queue that allows you to connect different parts of an application via pubkeys

A simple library to utilise nostr as an ephemeral (slow) message queue that allows you to connect different parts of an application via pubkeys - h...

Why Use It? Don't worry, you don't have to :) The philosophy and ideas behind it are: 1. User composable apps - Users can choose and swap out components of apps as required. No more "take it or leave it" software with tightly coupled trust models. 2. Sharing the load - Complex systems can be hard to self-host. This lets us share the complexity across both self-hosting and service providers - why not both! 3. Risk sharing - Running Freedom Tech often comes with risk for both server runners and users. The idea is to open up the design space for how we design and share these risks and responsibilities. and introduce more opportunity for.... 4. Regulatory arbitrage - Regulation is heavily jurisdiction dependent and risk differs depending on who runs what. This allows you to only run the aspects that are fine in your jurisdiction, then allow users or other service providers to fill in the gaps. Freedom Technology Principles For dissidents in authoritarian societies or those dealing with corruption: - Operational Security: Keep identity management local while outsourcing heavy computation - Plausible Deniability: "I just run an encrypted database, i dont process anything", "I'm only a filesystem" , "I only sign messages in a secure enclave"... - Resilience: If one component gets compromised, the others keep running and we can hotswap providers - Distributed Risk: No single person carries the full legal/physical risk of the entire system "NostrMQ lets you build applications like LEGO blocks - choose the best provider for each piece while keeping full control of your identity and data." ---- Shoutout to @Juraj - who's latest Option Plus podcast convinced me to just push this out today before it's good 😉

First guest on the show this week :) https://fountain.fm/episode/m6msKRJKxnS4b5ba1Gni

I’m fairly convinced we need highly opinionated AI agents for good UX

Have any journalists checked their signal invites for the alpha?