Building irl.coop: The Hard Problems

The Same Walls, Every Time

I've organized grassroots campaigns, managed nonprofits, co-founded startups, built PageDAO (a decentralized autonomous organization for book publishing), and worked with several other DAOs. Different contexts, different missions, different people.

But every single time, we hit the same walls:

• Promises and credibility: Who can we trust to follow through? How do we build accountability without hierarchy?
• Paying people fairly: How do we compensate contributors when there's no HR department and no payroll system?
• Tracking efforts and contribution: Who did what? How much did they contribute? Who decides?
• Task management and workflow: How do we coordinate work without a project manager controlling everything?
• Document management and cloud storage: Who owns the Google Drive? What happens when they leave?
• Authentication and access control: Who has the passwords? Who can lock everyone else out?
• Lack of conflict resolution: When disputes arise, who mediates? What's the process?
• Pitching for funding: VCs and grant programs want legal entities. How do we incorporate without centralizing power?
• Shared vision and evolving goals: How do we hash out what we're building together and revise it as we learn?

These aren't edge cases. They're the fundamental challenges of cooperative work in a digital world built for individuals and corporations, not collectives.

In my last post, I described the gatekeeper problem and how irl.coop aims to solve it by making groups first-class citizens in digital infrastructure. But I glossed over something crucial: building this is really hard.

Not "hard" like "requires good engineering." Hard like "requires solving problems that don't have clear solutions yet."

Here are the five hardest problems I'm grappling with as I build irl.coop.

---

1. Privacy: The Optimization Paradox

The Problem

Cooperative infrastructure needs privacy at multiple levels:

Private group membership: If Sarah's membership in the Radical Zine Collective is public on-chain, her employer might fire her for her political views. If John's participation in a mutual aid group is visible, he could face legal consequences. Privacy isn't a luxury—it's a prerequisite for participation.

Private transactions: When the zine collective pays contributors, those transactions shouldn't be public. When the printing press meta-group splits maintenance costs, the amounts shouldn't be visible to competitors or adversaries.

Private group interactions: Which collectives are collaborating? What resources are they sharing? This information could be used against them.

But here's where it gets interesting: How do you optimize systems when you can't see the data?

The Optimization Paradox

Imagine the printing press meta-group. Four zine collectives share it. To schedule efficiently, you need to know:

• How much each collective is printing
• When they need access
• What materials they're using

But if all of this is encrypted, how does the scheduling algorithm work? How do you:

• Detect when one collective is monopolizing the resource?
• Fairly split costs based on usage?
• Prevent abuse without surveillance?

Zero-Knowledge Proofs: The Theoretical Solution

Zero-knowledge proofs (ZKPs) let you prove something is true without revealing the underlying data. For example:

• Prove you're a member of a group without revealing which group
• Prove you used 500 sheets of paper without revealing what you printed
• Prove you paid your fair share without revealing the amount

This is theoretically beautiful. But in practice:

• ZKPs are computationally expensive
• They're hard to implement correctly
• They don't solve every privacy problem
• Most people don't understand them (which creates trust issues)

The Real Question

Can we build systems that are:

• Private enough to protect vulnerable participants
• Transparent enough to prevent abuse
• Efficient enough to actually use
• Simple enough for non-technical people to trust

I don't have the answer yet. But I know it's not "just use ZK-SNARKs."

---

2. Regulatory Risk: The State Can Always Shut You Down

The Threat Model

Cooperative infrastructure threatens power. States notice.

Infrastructure targeting:

• IPFS nodes can be blocked
• Smart contracts can be sanctioned
• Domain names can be seized
• Hosting providers can be pressured

Legal entity attacks:

• If groups wrap LLCs, those entities can be sued, frozen, or dissolved
• Bank accounts can be seized
• Directors can be held personally liable

Financial surveillance:

• KYC/AML requirements make anonymous group treasuries illegal in most jurisdictions
• Crypto exchanges can freeze funds
• On-ramps and off-ramps are chokepoints

The compliance trap:

• Build something censorship-resistant → get labeled as facilitating crime
• Build something compliant → give states the tools to shut you down

The Tension

You can't build cooperative infrastructure that's:

• Completely censorship-resistant
• Fully compliant with all regulations
• Accessible to everyone

Pick two. Maybe.

What I'm Thinking

The goal isn't to be un-shut-downable. That's impossible. The goal is to be resilient:

• Decentralized enough that shutting down one node doesn't kill the network
• Forkable so if one instance gets captured, communities can migrate
• Interoperable so groups aren't locked into one platform
• Legally defensible where possible, without compromising core values

But I'm not naive. If irl.coop actually works, if it enables real cooperative power, states will try to shut it down. The question is: can we design it so that shutting it down is harder than tolerating it?

---

3. Dispute Resolution: When the DAO Can't Decide

The Problem

Disputes are inevitable:

• Sarah and John disagree on strategy
• A collective wants to kick out a toxic member
• Two groups claim the same time slot for the printing press
• Someone accuses another of stealing funds

In traditional organizations, there's a boss or a board. In irl.coop, there's... what?

Why "Just Vote" Doesn't Work

Majority rule can be tyranny:

• 51% can oppress 49%
• Vocal minorities can dominate quiet majorities
• Voting without deliberation is just mob rule

Not everything should be voted on:

• Do we vote on whether someone's identity is valid?
• Do we vote on whether abuse happened?
• Do we vote on technical decisions that require expertise?

Voting is expensive:

• Constant votes create fatigue
• Low turnout leads to illegitimate decisions
• Coordinating votes across time zones is hard

What Might Work

I'm exploring:

• Nested consent: Different decisions require different levels of agreement (simple majority, supermajority, consensus)
• Delegated authority: Groups can delegate specific decisions to trusted members or sub-groups
• Escalation paths: Start with informal resolution, escalate to mediation, then to binding arbitration
• Exit rights: If you can't resolve a dispute, you can fork or leave with your share

But here's the thing: dispute resolution is cultural, not just technical. You can't code your way out of human conflict. The best you can do is create structures that encourage good-faith resolution and make bad-faith behavior costly.

---

4. Sabotage: Attack Patterns and Surfaces

The Threat

If irl.coop works, people will try to break it. Not just states—competitors, trolls, bad actors within groups.

Attack surfaces:

• Sybil attacks: One person creates multiple fake identities to control votes
• Griefing: Someone joins a group just to cause chaos
• Resource exhaustion: Spam the system to make it unusable
• Social engineering: Manipulate people into giving up access
• Exit scams: Drain the treasury and disappear
• Reputation attacks: Spread false information to destroy trust

Why This Is Hard

In centralized systems, you can ban bad actors. In decentralized systems, banning is hard:

• Who decides who's a bad actor?
• How do you enforce a ban across a decentralized network?
• What if the "bad actor" is actually a whistleblower?

Patterns I'm Watching

Reputation systems:

• Can help identify bad actors
• But can also be gamed or weaponized

Stake-based participation:

• Require people to put something at risk (money, reputation)
• But this creates barriers to entry

Slow onboarding:

• New members have limited power until they build trust
• But this can feel exclusionary

Forking as defense:

• If a group gets captured, the good actors can fork and leave the bad actors behind
• But this is disruptive and costly

There's no perfect defense. The goal is to make sabotage more expensive than it's worth.

---

5. Sustainable & Ethical Financing: The Meta-Problem

The Paradox

How do you fund infrastructure for the solidarity economy without relying on extractive capital?

Venture capital:

• Wants 10x returns
• Forces growth-at-all-costs
• Demands exit strategies (acquisition or IPO)
• Betrays cooperative values

Grants:

• Temporary funding
• Can't sustain long-term infrastructure
• Create dependency on funders' priorities

User fees:

• Create barriers to access
• Exclude those who need it most
• Turn infrastructure into a product

Crypto tokens:

• Often become speculative assets
• Create perverse incentives (pump and dump)
• Concentrate wealth in early adopters

What I'm Exploring

Cooperative ownership of the platform:

• Users become stakeholders
• Governance rights tied to usage, not capital
• Surplus gets reinvested or distributed

Protocol fees:

• Small percentage on transactions
• Goes to a community-controlled treasury
• Used for maintenance, development, and grants

Quadratic funding:

• Matching pools for public goods
• Small donations get amplified
• Reduces influence of large donors

Solidarity economy cross-subsidy:

• Profitable groups subsidize struggling ones
• Built into the protocol, not charity

Retroactive public goods funding:

• Reward projects that create value after the fact
• Reduces need for upfront capital

The Real Question

Can we build infrastructure that:

• Sustains itself financially
• Doesn't extract value from users
• Doesn't rely on altruism alone
• Doesn't compromise cooperative values

I don't know yet. But I know that if we can't solve this, irl.coop will either fail or become the problem.

---

Why These Problems Matter

These aren't just technical challenges. They're the fundamental tensions of building power outside existing systems:

• Privacy vs. transparency: How do we protect people while preventing abuse?
• Autonomy vs. regulation: How do we resist capture while staying legal?
• Flexibility vs. stability: How do we resolve disputes without rigid hierarchy?
• Openness vs. security: How do we prevent sabotage without exclusion?
• Sustainability vs. ethics: How do we fund this without selling out?

Every centralized platform "solves" these by concentrating power. irl.coop can't do that. So we have to find new solutions.

---

The Path Forward

I don't have all the answers. But I have an approach:

1. Build in public: Share the problems, invite collaboration, learn from others who've tried.

2. Start small: Solve these problems for small groups first, then scale.

3. Embrace imperfection: Ship something that works 80% of the time, iterate based on real use.

4. Stay grounded: Every technical decision must serve real people doing real cooperative work.

5. Be honest: When we don't know how to solve something, say so.

Building irl.coop isn't just about writing code. It's about reimagining how digital infrastructure can serve cooperation instead of extraction.

It's hard. But it's worth doing.

---

Want to follow along? I'm documenting the journey on Substack and building in public. If you're working on similar problems—or if you've hit these walls in your own organizing—I'd love to hear from you.

The future of cooperation depends on infrastructure that makes it possible.