Problems
Before solutions. Before tools. What's actually wrong?
This isn't about software. It's about people.
See also: Vision (what we're exploring), Why software is hard (accessible explainer), Interaction graph (making affordances explicit), Use Cases (what we want to enable)
Why do people not do things?
They want to create. They have ideas. They don't start. Or they start and don't finish. Why?
- Fear of failure - What if it's bad? What if I'm bad?
- Fear of judgment - What will people think?
- Perfectionism - Can't start until it's perfect in my head. It's never perfect in my head.
- The gap - The distance between the idea and the execution feels insurmountable.
- Decision paralysis - Too many options. Which tool? Which approach? Which thing to make first?
- Previous attempts felt bad - Tried before. It sucked. Why would this time be different?
- It stopped being fun - Used to enjoy it. Now it feels like work. Or obligation. Or performance.
- No immediate reward - The payoff is distant. The couch is right here.
- No one to share it with - What's the point if nobody sees it? Or worse - what if they do?
- Easier things grab attention - Infinite scroll is right there. Zero effort. Guaranteed stimulation.
- Life - Depression. Burnout. Exhaustion. Responsibilities. Health. Money. Time.
Some of these are ancient. Some were created by software. The infinite scroll didn't exist until someone built it. The comparison metrics didn't exist until platforms added them. The attention economy is a design choice, not a law of nature.
Software has power. It's been used to create these problems. Could it be used to address them?
Why are people sad?
Not clinically. Just... the ambient background sadness that seems everywhere.
- Loneliness - Surrounded by people, connected to no one.
- Lack of meaning - What's the point? Of work, of effort, of anything?
- Comparison - Everyone else seems to have it figured out. They don't, but it looks like they do.
- Feeling stuck - Same patterns, same problems, no way out visible.
- Feeling unseen - Nobody really knows you. Or the you they know isn't the real you.
- Wrong environment - The place, the job, the relationship, the life - it doesn't fit. But changing is terrifying.
- Chronic stress - Always something. Never a break. The baseline is anxiety.
- Loss - Of people, of possibilities, of the person you thought you'd be.
Loneliness existed before software. But "connected to everyone, close to no one" is new. The curated highlight reel making everyone else's life look perfect is new.
And the parasocial relationship is new at scale. You feel like you know someone. You follow their life, their thoughts, their struggles. They don't know you exist. This asymmetry - one person broadcasting to millions, each feeling a personal connection - creates a new kind of loneliness. You have "relationships" that only flow one direction. You invest emotional energy into people who can't possibly reciprocate because they don't know you're there.
Software created new forms of sadness. It amplified existing ones. That means software has power here too.
Why are some games good?
Not all. Some. What makes them work?
- Clear goals - You know what you're trying to do.
- Good feedback - You know if you're doing it well. Immediately. Not after a performance review.
- Mastery curve - Hard enough to be interesting. Not so hard you quit. You get better and it feels good.
- Meaningful choices - What you decide matters. Not just the illusion of choice.
- Flow state - Time disappears. You're fully there.
- Respect for your time - The game values your hours. It doesn't waste them to inflate metrics.
- Surprise and delight - Moments of unexpected joy.
- Social connection - Playing with others. Real connection, not leaderboard comparison.
Good games are designed around what makes humans feel good. Not what extracts the most from them.
Why is social media the worst game?
It's a game. It has mechanics, rewards, feedback loops. But optimized for what?
- Engagement, not wellbeing - The goal is time-on-platform. Not your happiness.
- Variable reward schedule - Slot machine psychology. Maybe this scroll will have something good.
- Social comparison baked in - Likes, followers, metrics. Your worth as a number.
- Outrage spreads faster - Anger is engaging. Calm isn't. The algorithm knows.
- Metrics as self-worth - How many likes? How many views? Why didn't they respond?
- Performative connection - Curated highlights. Not real relationships.
- Asymmetry baked in - One broadcasts, millions consume. You know them, they don't know you. Parasocial by design.
- Designed to be addictive - Not an accident. Not a side effect. The goal.
- Your attention is the product - You're not the customer. Advertisers are.
- No endpoint - Good games end. Social media never does. There's always more scroll.
The worst game because it uses all the techniques of good games - but inverted. Exploiting instead of serving.
Why does Discord work?
Not perfect. But different. And the difference matters.
- Community, not audience - You're in a server with people. Not broadcasting to followers. Symmetric relationships - people who know each other, not parasocial one-way flows.
- No algorithmic feed - You see what's posted, in order. Nobody's optimizing your attention.
- Servers have culture - Each one is different. Has history. Has norms. Has regulars.
- Conversation, not performance - You're talking with people, not curating a highlight reel.
- Persistence - The server exists. The history exists. You can scroll back and see what happened.
- You're already there - Low friction. No new app. No new identity. Just... join.
Different design choices → different outcomes. Discord isn't trying to maximize engagement metrics. It's trying to be a place where people hang out.
Still has problems. Moderation is hard. Discoverability is weird. Notifications can be overwhelming. But the core dynamic is different from feed-based social media. That matters.
The telling thing: If Discord is your primary social media, you might read the "why is social media the worst game" section and think "is this even real? I'm fine."
You're fine because of the design choices. Not because the problems don't exist. People on Twitter/Instagram/TikTok are experiencing something fundamentally different. The medium shapes the experience. You might not understand why social media is toxic - because yours isn't.
Why does software often make things worse?
Not all software. But a lot of it.
- Complexity as moat - Hard to learn = hard to leave. Captured users.
- Features over simplicity - More checkboxes on the marketing page. Worse actual experience.
- Growth at all costs - Users are metrics. Engagement is the goal. Wellbeing is irrelevant.
- Advertising model - If you're not paying, you're the product. Your attention is sold.
- Designed for addiction - Dark patterns. Infinite scroll. Notifications that demand response.
- No ownership - You rent access. They can change terms. Your stuff lives on their servers.
- Updates that remove features - What worked yesterday might not tomorrow.
- Subscription everything - Pay forever or lose access.
None of this is inevitable. It's choices made by people. Different choices are possible.
What would actually help?
Not convenience. Not "slightly easier." Actual change.
- First step trivially easy - Not tutorials. Not setup. You do something and it exists. Thirty seconds.
- Permission to be imperfect - Constraints that say "of course it's rough, that's the point." PICO-8 energy. Dwitter energy.
- Creation as reward - The making feels good. Not the likes. Not the metrics. The making itself.
- Real connection - Building together. Not performing for each other. Shared artifacts, not curated highlights. Symmetric - you know the people who know you.
- Escape from infinite - Not infinite scroll, infinite backlog, infinite guilt. You choose when to stop. The system doesn't exploit your inability to find a stopping point.
- Calm - Software that doesn't demand. Doesn't notify. Doesn't make you feel behind.
These aren't features. They're design values. They require building differently, not adding functionality.
What form would it take? A game? A website? A creative tool? A chat server?
Wrong question. That's the "one paradigm" trap. It doesn't have to be one form. It doesn't have to be one tool. It doesn't even have to be a tool at all.
It's a philosophy. A way of thinking about how software should work. The rhi tools are one expression of it - but someone else could build completely different things that embody the same values. The philosophy is the thing. The tools are just what happens when you try to live it.
Why isn't this obvious?
If these values are good, why aren't they the default? Even in FOSS, where profit motive is absent?
- "I want something that works" - You're solving your problem. You have the context, the setup, the mental model. Composability with things you don't have isn't on your mind.
- Interaction design is a different skill - Most devs aren't trained in it. Might even dismiss it as "not real engineering."
- Standalone is easier - Thinking about how your tool fits with everything else is extra effort. Extra constraints.
- FOSS culture rewards different things - Clever code, performance, features. Not "fits smoothly into your life."
- Unix philosophy stayed narrow - Small tools that compose via pipes. But it never extended to interaction design, GUIs, the human experience.
- Consideration requires imagining others - Hard when you're deep in solving a technical problem for yourself.
Or maybe it IS more common than it seems, just not articulated? Lots of people make composable, calm, respectful tools without calling it a philosophy. They just think of it as "doing it right."
The question isn't "why don't people know this?" It's "why doesn't this propagate?" Maybe because it's not teachable as a technique - it's a disposition. You either care about these things or you're focused elsewhere. And most people building software are focused elsewhere.
The software stack itself doesn't encourage this either. Even good tools - ComfyUI, Obsidian - are steps forward but not the whole picture. There's a spectrum:
- Cloud-first: Worst. Vendor lock-in, their infrastructure, your stuff held hostage.
- Local-first: Better. You own your data, it's on your machine, you can compose with local tools.
- Local-only: But also limiting. Can't access from your phone. Can't share easily. Can't collaborate.
The ideal is local-first, network-capable. Your stuff lives on your machine, but you CAN access it remotely via your own infrastructure (tailscale, your server, whatever you have). You CAN share and collaborate. The network is optional capability, not required dependency. You're not locked into their cloud, but you're also not locked out of your own stuff when you're away from your desk.
Most tools pick a point on this spectrum and stop. Cloud SaaS picks the worst point. Local-first tools pick a better point but often don't go further. "Local-first AND accessible from anywhere via your own setup" is rare.
And why isn't interaction - helping each other, collaborating, debugging together - more common? Because it's nearly impossible.
- Debug someone's setup? You can't see their machine, their environment, their state.
- Help with their Photoshop issue? Screen share. They fumble to show you. You can't touch anything.
- Pair on code? Special tools, both online at once, latency, still can't see their full context.
The friction is so high we've accepted isolation as the default. "Works on my machine" isn't a meme - it's the reality of how hard sharing context is. We've learned not to even try.
If you could just... see what they're seeing, poke at their setup, help directly - collaboration would be natural. But the stack makes it nearly impossible. So the disposition to help doesn't form, because the infrastructure never let it.
Games prove this. Minecraft - you just join their world. You see what they're building. You can help. No screen share, no special tools, no "can you show me your screen?" The context is shared by design, so collaboration is natural. People help each other constantly in games because the friction is zero.
Games solved this decades ago. The rest of software just... didn't.
And this shouldn't need proving. Humans are social creatures. Of course we want to collaborate. Remove friction and we do it constantly. Add friction and we stop. Software made collaboration so hard that we forgot it was natural. Games kept it easy, so people kept doing it - not because gamers are special, but because the infrastructure didn't get in the way.
Even our "solutions" are high-friction. Screen share means you can see their screen but can't touch anything. So you remote-pilot through voice: "Click the... no, the other thing. Scroll down. No, back up. The menu first, then the button." Exhausting, imprecise, frustrating for both people. Requires real-time synchronous attention. And you're still just watching - you can't actually help, just instruct.
Versus games: you're both just there, doing things in the same space. No translation layer of verbal instructions. That's what collaboration should feel like.
Some tools get this right. JSFiddle, tldraw, Cloud9, HackMD, VS Code Live Share, Overleaf - share a link (or session), you're both there, both can do things. No setup, no "can you share your screen," no verbal remote-piloting. The technology exists. It's just scattered - each tool solves it for their domain, but it's not a general pattern.
(Cloud9 got acquired by AWS and absorbed into their ecosystem. Another pattern: good collaborative tools get swallowed by platforms, then either disappear or become vendor-locked. The technology existed, proved useful, then got captured.)
What can be done? The technology is "solved" - CRDTs exist (Yjs, Automerge), real-time sync is a library not a research problem. But "solved" means "exists as a library." How many people know CRDTs are a thing? How many know Yjs exists? Can find it? Can integrate it? The technology being solved doesn't mean the problem is solved. Same pattern - capability exists, friction prevents use. "Just use Yjs" is like "just use tailscale" - obvious once you know, invisible if you don't.
For rhi, there's no "foundation" to add collaboration to yet - just pieces. So it's less about pivoting and more about not closing doors: web-based where possible (share a link is free), CRDT-friendly data structures, local-first but syncable by design, don't assume single-user. Keep the door open instead of accidentally building walls.
Where rhi actually is
Honest assessment.
What exists: projects
Normalize, Unshape, Paraphase, Moonlet, Concord, etc. But calling these "foundations" or "infrastructure" implies other things build on them. Do they? These are tools. Projects. Experiments. Things made while thinking about these problems.
- Normalize: code intelligence tool
- Unshape: procgen primitives
- Moonlet: Lua runtime
- Paraphase: conversion pipelines
Useful? Sometimes. Working? Mostly. They're libraries, not frameworks - you call them, they don't impose structure.
Coherent in philosophy, not in requiring you to use everything together. "Use Normalize and Unshape and Moonlet or else" would be exactly the lock-in we criticized. Each project should be useful on its own, composable with non-rhi things. The coherence is in the values they embody, not in forcing adoption of the whole stack. That's the philosophy applied to itself.
What doesn't exist: the things that help
- The environment where you describe a thing and it exists
- The place where creation is play, not work
- The community where you build together and stumble on what others made
- The calm software that respects your time and attention
The gap
We have sketches. We don't have a house. We don't even have plumbing - just drawings of pipes.
The projects exist. They embody the philosophy (sometimes). But they're not infrastructure anyone builds on. They're not steps toward a destination - they're explorations in a direction. Maybe some of them lead somewhere. Maybe not.
This is honest. Not pessimistic - exploration matters. But not pretending that Normalize solves loneliness or Unshape makes creation fun. They're things someone made while thinking about these problems. Not solutions. Not even foundations. Just... work.
What would "not making it worse" look like?
Not a solution. Just... not adding to the problem.
- Respect time. Don't waste it.
- No addiction mechanics. No dark patterns.
- Ownership. Your stuff is yours.
- Honest complexity. As simple as possible, no simpler.
- Offline-first. Not dependent on servers that might disappear.
- No metrics as self-worth. Or no metrics at all.
- Escape from infinite. You choose when to stop.
- Calm. Not demanding constant attention.
This isn't a product spec. It's a set of values. A filter for decisions.