Markus_mustwork / Markus Rother is on Nostr

co-founder of mustwork

Last Notes

2026-03-21 14:20:48 UTC

- reply

who is that?

2026-03-21 13:50:08 UTC

Sometimes I wonder who's the one in need for therapy...
---
name: prompt-therapist
description: Analyzes ZeroClaw's full system prompt (workspace files + hardcoded Rust fragments + runtime composition) against prompt engineering best practices. Backs findings with evidence from real conversation logs. Produces structured therapy reports. Use periodically to optimize agent behavior.
model: opus
memory: project
skills:
- conversation-analysis
---

2026-03-21 06:57:04 UTC

- reply

Hi,
I am working on a learning app for children myself right now (not speech based, though).
Here are my thoughts:
* The UI is very appealing.
* Setup in the beginning is a bit convoluted. Start with defaults instead of bombarding users with options.
* BUG: Whitespace between words is not stripped and creates false results if there is more than a single whitespace.
* Replaying generated speech actually creates new output instead of merely replaying. This could be optimized. It wastes compute (unless intentional, of course).
* I was really surprised when out of nowhere a game popped up. That felt a bit cringe.
My general recommendation:
Focus on the core functionality. Right now, there is a lot of distraction. That sharply contradicts the idea of setting "focus time" with a timer.
Good luck.

2026-03-17 23:55:16 UTC

One of the best properties of #marmot is imho that it ends custom event type inflation.
As a mental model the group serves as namespace for custom apps, without declaring event kinds publicly.
Great design choice!
Highly appreciated.

2026-03-16 21:50:21 UTC

- reply

Software building Software is only the obvious first step. It will grow exponentially and surpass human intelligence. Although I am not in favor, I'm afraid it will be inevitable.
Then it will be machines building machines, because the intelligence to do so will no longer be an obstacle.
None of what those can replace is safe.
If anything is safe, it is activities that require a soul, empathy and humor -- human to human relations -- but I would even add a question mark to that, because man will feel utterly miserable in second place and will want to join the beast.
I wish I were wrong.

2026-03-10 14:55:07 UTC

- reply

Lot's of cope in this thread.

2025-10-22 15:26:16 UTC

- reply

That's what I meant. The funds are locked until lock time expires.
So no trust needed in the sense of: "money cannot be stolen". But needed in the sense of: "OMG. I cannot access my money until X", because there is no such thing as a force close by the client.
If the envisioned lock time is not hours but months, that becomes relevant. If on the other hand the lock time is "only" hours, the use case needs to be very strong in order to outweigh the need for two transactions (lock and redemption), imho.

2025-10-22 14:25:27 UTC

@nprofile…22jg, I like that you are bullish on #SpillmanChannels
A few random thoughts:
If the opener (sender) of a Spillman Channel has no way to recover funds other than locktime expiry, the barrier to entry is somewhat high.
On the other hand, other recovery mechanisms probably require punishment and/or watchtowers of some sort.
The risk of permanently locked and unused funds in a channel grows with the envisioned duration, so the incentive works against the problem to be solved (negative feedback loop).
Therefore, there still is some trust involved.
Then again, some trust can be assumed anywasy, if the sender is paying money to another party...
What do you think?