Authoring, distributing, and finding apps 2.0

[sgwilym]

Let's talk about apps, making them, distributing them, finding them. If all of these things are difficult then Earthstar's versatility is just theoretical.

My dream outcome is a scrambling, heterogeneous ecosystem of apps for earthstar doing many different tasks at very different scales. Apps made by friends scratching their own itch. Apps made by co-ops to do mission-critical jobs. Apps made by some guy who loves llamas and shows it via his UI design.

If someone wants a 'cleaner' todo list, or a deeper one, or one with more sparkles, they can find one. An app ecosystem with the unpredictability and scrappiness of the web.

It seems far away. But I want to get there.

Here's the problems I've noticed over the last two years when making my own Earthstar apps:

• Producing a good earthstar app requires providing a lot of common functionality (eg keypair, share, server management)
• Creating UI toolkits to help with this is a high maintenance job which then only works for one specific framework (eg 'earthbar')
• Even with a toolkit you need to integrate it into your app when all you wanted to do was make a todo list.
• The burden of distributing an app has fallen on app authors who need to find a good host, keep it updated with the latest version in perpetuity (?)
• It's left to users to find out where Earthstar apps are hosted (and presumably keep a bunch of bookmarks)
• And because they are all hosted on different domains, all the apps are having to maintain their own database.

Instead of all this I'd like people to be able to write only the features they're interested in writing, in a framework-agnostic way. They wouldn't need to host anything. Users would have a single place they could turn to to find available apps and use them.

While walking around in a dark room while I have my baby asleep in the carrier, I had an idea on how to do this using some of Earthstar's upcoming features!

My idea

Earthstar documents will soon be able to have attachments of arbitrary binary data.

Replica servers are able to serve this data through a web browser via HTTP.

What about publishing apps (their HTML, JS, and other assets) to Earthstar shares, and then serving them from a replica server?

This approach has a couple of really nice benefits.

If you have many apps served from the same origin, they can use the same backing data (ie user config and share data). This means you could have an independent applet for stuff like keypair / share / server management, and just write applets that do one thing and well, leaving the boilerplate to "jeff's keypair manager 2.0" (or maybe "gwil's ultimate Earthstar configu-bot") It also means that all apps would share a common database for writing a reading share data. Authors making a super simple vanilla JS todo list can benefit from another reactive-framework behemoth's features with no interop.

Users would be able to look for applets in one place: the server. We could even have a server extension which serves a UI of all available apps if we made apps provide a json describing themselves.

Maybe server operators would be able to add new applets to shares with some kind of web UI too.eg Fetch the contents of a repo, write it to the share. App authors don't need to think about hosting at all.

Anyway the baby's waking up now, see you!

[basham]

This reminds me of what Keet is doing with Holepunch. Most app updates are handled by distributing the app code itself through the P2P swarm. The only piece it can't handle that way (I'm assuming, anyway) is the native app shell, which may require a little bit of a separate upgrade process.

I've been expanding my use of service workers in my app, and I've been starting to wonder about these same things. A service worker could actually respond with app code itself. However, I doubt you can upgrade the service worker itself somehow by having the service worker serve its own new code.

Anyway, I'm eager to see how these development efforts play out. It certainly opens up interesting and unexplored options.