Soft Apps
The future of the web relies on open standards, flexible systems, interoperable tools, and first and foremost a focus on the human being.
Act 1, Scene 1: We Contain Multitudes.
In Sweden they have something called BankID, which is an authentication provider. There are lots of apps and services that rely on BankID for their logins and other services – serious things like your social benefits and scheduling doctor appointments, and other day-to-day things like the Swedish versions of Venmo, Craigslist, and Zillow. It’s a pretty good system and user experience. You get a BankID account from … your bank and you have an app on your phone. When you want to log in, you snap a photo of a QR code on the app, plug in your PIN number, and it authenticates you. It’s pretty great.
The biggest problem is that it’s tied exclusively to your personummer (a sort of public Swedish Social Security Number) and bank account. That means you get one BankID, and you have to have a bank account to get it. This is not great – for unbanked people, for privacy, or for flexibility even. It’s a system that cannot accommodate an alias; what if I want two realms of my online life to remain separate? It’s a system that cannot accommodate privacy; what if I don’t want my real name associated with my internet use? It’s a system that can’t imagine the problems with centralizing your life under an institution; what if I don’t want my bank to know what I’m doing online?
Could we have a similar experience with dedicated authentication providers, without the hegemonic power structure being in charge? Perhaps your library could operate one, and you can log in to all these apps with your library card credentials. Or a community group could do the same, or even just an independent person could run their own from their basement. These community-run authentication providers can issue credentials however works for them, and as a human being I can have as many of these identities as I need, from providers that I trust.
I don’t need a lot of these to know exactly who I am – it could be fine for me to be “a member of the library” or “part of this community group”. It also doesn’t necessarily need to be totally private – I’m happy being “a parent with a child in public school”, or “an adjunct at the community college”. In our current world, we can imagine that one would want their login to lesson planning tools be different than their login to OnlyFans.
Who I am online is an expanded field: from public to private; from institutional to independent.
Act 1, Scene 2: The Persistence of Memory.
Ross Wintle recently wrote about static web apps. These are small, simple, purpose-oriented apps that just run by themselves in the client. I’ve written a couple of these myself – Joseki Party for peer-to-peer games of Go, Dicegraph for calculating complex dice rolling odds, and a PDF imposer for making zines and books. Even Mastodon clients are a really good example of this kind of app - they run on their own, and don’t need to persist any data other than on local device storage.
Wintle has an adjacent article about “static databases” – that is, a way for these simple little apps to persist data somewhere other than local storage. I imagine that this would work basically like IndexedDB, but if a user was authenticated then the data can persist to a server and be accessed across devices.
The trick then, is how to create a client-side application that can store data on a server without needing to run a server itself.
A Database-as-a-Service like Firestore or Supabase can do this – they provide an auth solution and a data store that you can access, all from the client side. But this isn’t really a client-side-only app at this point – this is a frontend app with a backend that you’re renting. As a developer, you’re still on the hook for paying for the storage and bandwidth. You’re on the hook for user data privacy, GDPR compliance, and all the rest. All this data gets persisted under your account credentials after all.
In order to run a simple, free, static, tiny as possible application, you need a persistence solution that the user is responsible for.
An example of this is how IA Writer – which Im writing this on now, from my phone and laptop – uses iCloud to sync across my devices. They don’t need, as an app, to be responsible for any of my data. As long as I’m authenticated with iCloud, the app can rely on iCloud just as it can rely on on-device storage. Small Victories used to generate static websites out of a Dropbox folder. Google Drive is the Android version of iCloud.
A small, focused, and useful web app could really use an operating system agnostic, interoperable solution to rely on for persisting its data. Something client side only that doesn’t need any developer accounts – and therefor hosting bills – that add up over time and maybe cause you a big problem if you get popular.
Act 1, Scene 3: Data Sovereignty.
As human beings using the Internet and using apps, we have an interest in how our data is being used. If you’ve been posting to Reddit, then Reddit is selling your data to Google to train their large language model. If you’ve been posting to Tumblr, then Automatic is selling your data to OpenAI to train their LLM. If you’ve been posting to Twitter, then who knows what the hell Musk is doing with that for his LLM. This is not to mention Facebook, whose empire is built on access to and control of our data. Our data and what we create and provide is owned by the platforms. What about Flickr, for our photos? What about Squarespace and Webflow for our websites? What about Sanity or Contentful for our content? Other than Flickr, these are all VC backed Silicon Valley tech companies (Flickr is owned by a little Mom’n’Pop Silicon Valley tech company).
Is there somewhere else I can store my data? Can I use an application like IA Writer or Eagle and store my data somewhere that I control, that I pay storage and bandwidth for, and have access to on my own terms? Where can I go on the internet and not have my preferences and actions mined for advertisements? How can I stay out of a database that gets sold on to help make the internet worse? Where can we go?
The Fediverse takes this seriously, but they’re not the only ones. Data sovereignty is a big deal for the First Nations in North America, and I think it’s something that more people starting to think more about. The IndieWeb folks do a good job talking about owning your own content, but what if we go further? Can I own my own Wordle streak? What about my Pins (both Boards and Interests)? What about my budget?
We put effort and work into our interactions with the internet. But everything we put up on a platform or service can be lost, or it can be used against our interests. We need a middle ground between hard, backwoods-survivalist style “run all your services yourself” and sharp, “submit to the surveillance capitalist ad-tech ecosystem”.
Interlude: It’s Almost Like…
Mastodon, but for more than social networking.
The Interplanetary File System, but for more than just distributed file sharing.
The Blockchain, but without stupid energy waste, a racist and fascist political agenda, or a primary use case of scams.
Act 2, Scene 1:
What would an ecosystem that addresses these three points of view look like? We’re describing a system where web developers don’t handle any of their users data, but users do manage it through independent, third-party authentication providers. Each of our three perspectives rely on their relationship with the other two, creating a healthy ecosystem.
This ecosystem of interrelated systems does have a big hurdle to cross before it can really be successful. Why would someone sign up for one of these providers if there aren’t any apps that support them? Why would a developer build an app that relies on these providers if no one has one? And why would anyone start one of these providers if there are no apps and no users? Once all these things do exist, then they can work together, but while they are still rare and unusual the incentives to build that network in the first place just aren’t there.
It turns out that I’m not the first person — and far from the smartest person — to see how this ecosystem of tools could be the future of the internet, and there are efforts to build this system out to kick-start the critical mass phase of adoption.
Tim Berners-Lee started the Solid Project to make the independent third party authentication and storage provider a reality, where users themselves control and own the data they create through web applications. There are several Solid Server implementations today, with more in the works. There are Applications today that operate against Solid Providers. You can get yourself a Solid account today, with Providers to choose from.
Solid is built on a collection of open W3C specifications that directly handle the concerns of authentication, access control, and data storage. It’s built on the same data exchange format as Mastodon’s own open specification ActivityPub, and allows for server federation and the creation of links across data providers.
All three pieces of the puzzle exist today, and are in use. Developers are making apps that store data on Solid providers where users own and control their own data. But the critical mass of the network effects isn’t there yet, and with some exceptions like Dokieli the applications are mostly proof-of-concept technical demos. The teams that are working on these problems seem to be either academic or government-focused, and are using SOLID to address a need for public data access and transparency.
For the small private application however, there still isn’t a clear cut answer to the pair of questions “why would I want to sign up for this” and “why would I want to develop for this”.
Act 2, Scene 2:
Berners-Lee and his company Inrupt are trying to bring this ecosystem to that critical-mass point of adoption, with a focus on enterprise and civic tech use cases. Accounts on Inrupts Enterprise Solid Server are free – albeit in “developer preview” – and Inrupt could easily grow to be the primary server for these sorts of providers, creating a massive instance and single failure point of failure for the entire ecosystem. Inrupts Enterprise Solid Server is important, and having a rock solid, enterprise, government sponsored server will go a long way to creating the legitimacy that Solid needs. But it’s not going to be enough in of itself.
One of the powerful things about the Fediverse is that anyone can run their own Mastodon server under any terms they want. Anyone can implement a Mastodon server because the thing that makes it work is that open specification. The resulting community is robust, flexible, and a wide range of dedicated people who are all working to make it better. And as it gets better, it gets better for everyone.
Solid is a very close cousin to ActivityPub, and they use some of the exact same specifications. An ecosystem where Solid can thrive is one that has many different providers, trying many different things. As each provider grows, and each new app comes online, the whole system gets more valuable for everyone.
Our call to action here is clear: if this is going to be the future of the internet, than each of the three legs of the stool need to be as easy, simple, and joyful to accomplish as possible. Their value propositions need to be incredibly clear, and their stories straightforward and compelling. The tools need to be there for users, developers, and providers, and it should be easier than the alternative – maintaining the current status quo.
Interlude: Some Sort of Framework, for Describing Resources
It’s somewhat of a coincidence that the Solid Project is built on top of the Resource Description Framework. RDF is one of the things that makes Solid hard, but fundamentally we can think of RDF as JSON with some neat bonuses.
RDF doesn’t need to be hard, and one of the goals has to be building the modern tooling that developers need to make it easy.
Act 3, Scene 1: User Loggins
Why would a user want to log in to application with their solid provider? Why would they want to pay to of pocket today for a sign in? What problems does this solve them them?
Now that I’ve jumped through all the hoops involved with setting up BankID, it’s a fantastic workflow. I appreciate having a single, interoperable account that I use to interact with web services. While password managers make the proliferation of user accounts – each one a special snowflake for its service – manageable at all, it’s nice to have one that I can use. Rather than filling out the same forms over and over and over again, I can just use the thing I want to use.
I want to use tools and apps just by arriving at a site and using them. I want to save my work and reference it later, but the constant stream of accounts and updates and product marketing emails and limited features is exhausting. I’ve been on Coolors a lot this week doing some brand design groundwork, and while it’s a great tool it typifies the format of gimmicky, gated, locked down web product. I don’t want to sign in. I don’t want to go pro for a monthly fee. I don’t want to hide ads. I want to use the tool, and I’m happy to pay my own commodity usage costs and the developer.
When I as a user can foot a bill that I have agency over, I’m happy to do so. I’ve paid for IA Writer, Sublime Text, RunJS, and Eagle. Why are good, solid tools that a user can just … pay for and use so rare?
I want an identity that is just, me. I want to pay for the resources I use. I want to pay the people who write the tools that make my life easier. I want this to be simple, the default, and uncontroversially boring.
Act 3, Scene 2: Writing Less Code
it’s still a pretty small number of people who actually realize they can do the work to build these kinds of things. what would it look like for this to be a little easier? could it be 10% easier? 50%? how?
why would an application give up the access/relationship/data/power they have today?
This needs technical exploration, but I’m convinced that Solid can make writing web apps easier, faster, more efficient, and safer. A number of problems that just … go away when you, as an app developer, let go of controlling authentication and storage.
GDPR compliance is no longer your department, since you’re not storing any information at all, let alone personally identifying information. Traffic spikes won’t lock your database since you don’t have one. Server bills … don’t really exist since you’re just serving client-side applications. Data breaches aren’t a thing because there’s no where to breach. You can focus on just writing the app that does what it needs to do, and not about writing authentication and access control interfaces. Trying new weird ideas becomes faster, cheaper, and easier. There’s no account creation barrier between your users and your app.
Not only does making web applications just get easier, but by letting go of trying to control identity and data, we can return agency to the people who use our apps. We can go back to making a clear, simple, exchange with them again. The thing that makes money is the service being provided, not the surveillance and data arbitrage that results from a massive pool of human attention.
To make this a reality, using Solid needs to be simple and straightforward as using the localStorage api. It needs to be boring, reliable, and simple. It needs to be interchangeable and interoperable – a default safe choice for new apps and easy to bring in to old ones.
Act 3, Scene 3: Providing for People
I want to make a living writing software the solves real problems for real people. I want these tools for myself, and I want to be able to share them with my community. I don’t want to write gimmicky subscription web products. I don’t want to manage a fleet of user databases. I want to make lots of simple, weird, powerful, and good apps and I want them to be easy to use to their maximum benefit.
If I can support myself by writing software – maybe running a solid provider myself – and I can help more people do the same, that’s the future I want. I want all the money currently locked up in the big platforms to be more evenly distributed to smaller, independent developers being directly supported by their audiences. This feels like the way to do that.
Epilogue: Who Cares?
I believe in a vision of the open web – a sustainable approach to the Internet and computing that doesn’t rely on extractive capitalism and exploitative practices. I believe in an ethical web that manifests the values I want to see more of in the world. I believe in our collective ability to create enough value through ethical development to support ourselves independent of corporate patronage and wage labor. I believe that we can make art, tools, processes, and ideas that make society richer and happier. I believe we can care for each other, and the web is corner for delivering that care.
Maybe you believe in this too.
Thanks to Marie Connelly, Phillip James, Casey Kolderup and Andy Baio for reading early drafts of this piece and providing feedback.