Coopetition in the ATmosphere

(This is version 2 of the description of my atproto.science conference workshop (March 2026, Vancouver), published using the permanent versions pattern on my wiki, where I share my evolving thoughts to help collect ideas along the way. Version control & links in the footer.)

I'm interested in exploring how we can manage competition and cooperation in the Atmosphere.

Ideally we'll bring together work from multiple teams to discuss a concrete example.

But first, what is coopetition?

And why does it matter?

"Coopetition is a business strategy blending cooperation and competition, where rival companies collaborate for mutual benefit, such as developing new tech or expanding markets, while still competing fiercely in other areas like pricing or features, creating a paradoxical yet strategic interdependence".

Possibly nobody else coming to Vancouver was actually fully grown in 1995, so you're going to have to take it from me: we are living through a 1995 moment in decentralised social computing. Back then, the new protocol-based information ecosystem was for publishing, whereas today it's for social media. In both cases people are being incredibly creative with it.

Back then, however, there was unguarded optimism. Today, the optimism is there, but it feels a little wiser, and far less oriented towards VC-fuelled instant wealth. We know that the commons we're building can be captured.

For me, the key question boils down to this:

How do we help all these innovators cooperate - thus growing the ATmosphere to the benefit of all - and compete - thus demonstrating its sustainability?

This is in fact already happening:

• independent teams first built highly distinct apps using the same underlying lexicon (eg deck.blue, flashes, anisota.net)
• we're now seeing "stage 2" cooperation, where different teams, having built different lexicons for similar use cases, are now cooperating (eg standard.site, from the teams behind leaflet, pckt.blog and offprint).

I'd like this workshop to explore two questions:

• How far can this go? Can new apps emerge simply by adopting, adapting and recombining lexicons and other open-source components developed by multiple teams, while maintaining credible exit? What are the natural limits of this?
• How can it be encouraged? How can this cooperation be encouraged and supported to make the most of scarce resources?

Recombining components: an example

I'm not completely lacking in self-interest so I'd like to use MyHub as an example to structure the conversation around.

Last year I realised that I may be able to rebuild MyHub.ai by combining components from multiple teams, creating a user-friendly "onramp" platform for new users that nevertheless maintains credible exit:

! (from MyHub on the ATmosphere or watch the video version)

The above "reading/thinking/writing/publishing stack" is built from multiple components, upon which various teams are already working for their own purposes:

Relevant Component	What It Does	Being developed by (among others)
Inbox	Present potentially interesting content	Sill.social
Thinking Tool	Permissioned data with community boundaries	NorthSky
Thinking Tool	push local files to PDS, providing credible exit from myhub thinking tool	grjte
Thinking Tool	Obsidian-AT Protocol integration with bookmarking and standard.site publishing	treethought.xyz
Publishing Engine	Publish Hubs and other site types to web via PDS	standard.site

(This table is incomplete - I would hope to add more before and after Vancouver.)

Note that credible exit it guaranteed precisely because it is built from open, shared components: myhub will compete through integrating them together in a user-friendly way, for the masses of users who will never visit GitHub or Tangled.

Supporting cooperation

I have developed a model which I would recommend funding organisations consider if they want to cost-effectively support the development of a portfolio of Atmospheric start-ups.

Briefly, the model focuses funding on developing components useful to multiple start-ups - the Inbox component required by Sill and MyHub, for example, would be prioritised because it serves (at least!) two startups.

But components need not be limited to code: it could also include shared infrastructure. The obvious example is the CoCoMo content moderation service, relays and PDSs being developed by Eurosky Social. There may be many more, but - crucially - only a conversation amongst startups can identify them. Of course those conversations, and the resulting cooperation, are already underway on Bluesky, at meetups, in Signal groups ...

I'd like to explore this with the atproto.science community in Vancouver because I think this model could give that cooperation a boost, as it:

• is incredibly cost-effective: each grant literally supports multiple start-ups
• builds cooperation between startup teams, to mutual benefit.

As an added bonus, both results will grow the ATmosphere as a whole, which in turn will lift all startups.

---

Revision Notes

This is one of this wiki's pages managed with the permanent versions pattern described in  Two wiki authors and a blogger walk into a bar…

• changes in this version:
  • developed, add links, shortened
• version control
  • this is version: 2
  • this is the current version: Your research institution in the Atmosphere
  • here is the previous version: Coopetition in the ATmosphere 1