Urbit and the Telos of the Creator Economy

Interesting alternative vision of the creator economy here:

https://otherlife.co/urbit/

The telos of the creator economy

It’s amazing I can work full-time as an independent writer on the internet, but to do so most powerfully I have to manage a sprawling empire of web platforms, desktop-only apps, iPhone-only apps, paid software tools, and even paid software tools to make my other paid software tools send data to each other.

I spend more than $1000/month on: Memberstack, Airtable, Circle.so, Zapier, Ulysses, Webflow, Transistor.fm, Evernote, Streamyard, Gumroad, Bonjoro, Buffer, Teachable, Typeform, Convertkit, and Zoom. The money is not even the greatest cost. It’s the time and energy of manually uploading, downloading, and splicing data from all of these silos. I use all of these tools and each has a positive ROI, but why do I need so many tools when the essence of what I do is so simple?

It is true that I am not your average “creator.” My little budding empire is not entirely representative of normal professional creators. But there will be many more like me, who see the longer-term avenues open to them, and then chafe badly at the current internet’s affordances.

Everything I do boils down to the following. I create work which I publish to public platforms (text, audio, and video files). People click some kind of button if they like my work and want to receive my future uploads (for free). I give this large pool of people various opportunities to click some other button, enter their debit/credit card, and then receive an additional private flow of my uploads. In summary:

  • I need to upload data into a public channel
  • People who like my uploads need a way to subscribe to them
  • I need a way to take an arbitrary number of different payment types
  • I need a way to provide a partitioned data channel per payment type

Pay me through this button and I should be able to deliver you some videos, a podcast feed, and a community forum all in one place—if that’s an offering I want to design. Pay me through a different button and I should be able to deliver you a private blog/newsletter that I generate by running machine-learning summarization algorithms on my preferred writing app. To do all of this myself, I should be able to copy and paste open-source code templates called “video feed,” “podcast feed”, “community forum”, and so on.

Like my videos but dislike my podcasts? You prefer reading newsletters on a custom app your friend designed instead of your email inbox? The followers of creators should have equally arbitrary control over how their subscribed data flows are handled, manipulated, and re-arranged. The difference would not be 10x better than the status quo. In a fully evolved Urbit ecosystem, the difference would be maybe 1000x better, or more. It’s hard to even imagine, which is why we generally don’t.

When you think about it, there is no good reason why there should be arbitrary constraints on what kind of data I can upload to any given channel. It’s data. This is the whole reason data is cool and powerful. The price we pay for apps on centralized servers is a kind of retrophysicalization of data. Instead of being infinitely fungible at near-zero marginal cost, some data files can only be uploaded and downloaded over here at the global Barnes and Noble, and some data files can only be uploaded and downloaded over there at the global Movie Theatre. I don’t want to go to your Movie Theatre. They screen so many movies that suck so bad it takes two hours just to find one that doesn’t completely suck, at which time my movie-watching time allotment is exhausted. I want my own planet, my own private but global biodome where only the smartest and funniest people I know can write texts, record videos, co-record podcasts, have threaded dialogues, and build apps all in one place with no limits to how they want to engineer the criss-crossing of their data flows. What I’m describing shouldn’t sound crazy and futuristic, it’s what the internet would already be, now decades after it’s arrival—if it hadn’t got stuck in its current equilibrium.

So why do I need ten distinct but architecturally redundant CRUD apps to do the same essential activities across all of them (create, read, update, delete)? It’s because of the client-server paradigm, as I explained above. This paradigm produces economic incentives for teams of engineers to capture and lock-in users on specific websites. Each app does solve a problem for me, and it’s cheaper than coding something custom, so that’s fair; I’m not complaining so much as suggesting that it must eventually give way for the same reason that scientific paradigms give way.

2 Likes