New Web: A Product Roadmap
Three Things #105: February 4, 2024
Last week I described three ways of thinking about the problem we’re trying to solve in improving the web and the content ecosystem, and three ways we might go about trying to solve the problems I laid out previously. With those potential visions in mind, this week I want to take a slightly more structured approach. How might we go about developing a product, platform, and protocol to improve the web? It’s a big, ambitious project and it’s important to approach in the right order.
This is how I’d start.
Note that this while this process refers specifically to the app and protocol we’re contemplating, it’s fairly general and would probably apply to many different kinds of apps.
Thing #1: Overlay Web App 📚
The right place to start working on the problem is with a barebones, proof of concept app that lets the user store and read content. The first version doesn’t need to do a whole lot more than this. This can and should be build initially as a web app.
You may wonder, why build an app using the existing web stack when the whole point of this project is to fix the web? You’d have a point, and a web app clearly can’t address everything that’s wrong with the web, but it’s still the best place to start. The reason is that the simplest possible thing both to build and to use is a web app.
Web apps are very familiar to users and they work across a huge variety of devices. They typically don’t require downloading or installing anything and they’re really easy to share (just send a URL). They’re relatively cheap and straightforward to develop, at least compared to native apps. Web apps also have the advantage that they can integrate quite easily into the existing web ecosystem and they natively speak the language of the web: APIs for reading and exchanging data, data formats like JSON, etc. Web apps are multi-platform by default and using tools like Electron it’s also feasible to migrate a web app to a native app when the time comes.
The purpose of this app would be to archive and present content in a fashion that optimizes for readability: in “snapshot” format (as described last week), devoid of paywalls, ads, and distractions. A true, barebones version of the app would simply allow a user to add a piece of content, to browse the content they’ve stored, to read that content, and to share it in the same format with others. In this respect it would look something like the web version of Pocket and Readwise, two apps I mentioned last week. Of course it would have some key differences: it would be open source, you could host and run it yourself, and over the long run it would be developed, operated, maintained, and governed by a protocol and something like an open source foundation.
It’s critical that using the app be as frictionless as possible since we don’t want to get between the user and their content—the whole point of this app and experience is to remove such obstacles. Onboarding should be possible simply by clicking on a link shared by a friend. A new user should immediately see suggested content, ideally things stored or shared by their friends and by people like them. They should be able to easily follow other content creators and curators that they like. In addition to content shared by friends and people the user follows, they should also be able to easily bring content in via two other means.
The first is sharing any content they come across on the web or in an app. This should be as simple as pasting a URL into the app, which would immediately cause the app to fetch the content, store it, and make it accessible and searchable not only to the user who fetched the content but to all users of the app. (There are easier ways to add content than copying and pasting URLs, but they require installing apps as described below.)
The second is importing content from existing apps and subscriptions. This step is critical as it massively reduces friction and makes onboarding painless. It allows the user to instantly bring over content from other places where they’ve already stored it, such as the apps I mentioned above, using their APIs. It would be great if the app could also access content shared on other social media platforms that the user uses.
This MVP offers both a compelling single player mode, where a user has a calm, distraction-free environment for consuming content they’ve curated for themselves, and also a compelling multiplayer mode, where a user can follow others, see the content they’ve curated, and share content with others.
Thing #2: Browser Extension 🔖
With a basic web app in place the logical next step is a browser extension. A browser extension is a web app, but it’s a web app on steroids with a few superpowers. The most important of these is the ability to control the browser on the user’s behalf. For our purposes this means reading what the user’s reading, which might not sound like a superpower but it’s actually quite a powerful idea. When the user activates an extension it becomes aware not only of the URL of the page or content in question but of the content itself. It can then take a snapshot of the content as described above. In a web app the user can only add content by pasting a URL or pasting content directly. By contrast, only an extension can effectively see what the user sees. Importantly this includes a localized version of a page, the full version of an article behind a paywall, or an article that isn’t public.
Another important difference is that an extension gives an application more permanence on a user’s system and, as a result, causes it to be more front of mind for the user. The number of web pages is effectively unlimited. But most people only have a handful of browser extensions installed and the icons for these extensions are are always visible. The friction to installing a web app is somewhat greater than that of opening a web app since there are multiple steps in the process and it requires installation, something that some users may be reluctant to do. But for users that are able to overcome this friction there are benefits.
Aside from these differences and advantages an extension isn’t terribly interesting. It basically functions like a web app that resides in a special window in the corner of your browser screen. The rest of the functionality of the extension we’re contemplating here would be pretty similar to the first thing, above. Pocket does something similar with its extension and web app combo. Extensions also have a bit more persistence than ordinary web pages and web apps: they retain state even when browser tabs and windows are closed. But that state is still stored inside the browser which isn’t terribly helpful.
There’s one very important thing that neither a web app nor a browser extension can do, and that’s P2P. What’s more, extensions have the big downside of needing to be delivered and installed through app stores. That means they need to be reviewed and approved and that companies like Google, Apple, and Firefox need to give you permission to publish your apps. This process is time-consuming, error prone, and costs money. Moreover these companies tend to have narrow definitions of permitted behaviors for apps and tend to apply their rules arbitrarily and with little to no oversight or accountability, as evidenced by the many bans on cryptocurrency related applications by companies including Apple and Google.
Both of these limitations bring us to the next thing.
Thing #3: Standalone App 💻
As I alluded to above, a standalone app has a number of benefits that non-native apps including web apps, browser extensions, and mobile apps can’t provide. Web apps run in a sandboxed browser environment which means they’re very limited in terms of what they can do and what they can access. They can interact with the browser and they can send HTTP requests but they can’t do much else. They have no native access to files on the filesystem, hardware devices such as cameras and microphones, to the network, or to anything else running on the system. All of this is by design, in order to protect the user and their system.
There are APIs and SDKs that make it possible to access hardware from the browser: WebHID, for instance, allows use of devices like joysticks and gamepads, and of course it’s also possible to access the camera and microphone for, e.g., video calls. But the requisite popups and approvals degrade UX and web apps remain constrained in other big ways, e.g., limited disk and network access. Browser extensions face all of the same constraints with the one difference that, as mentioned above, they have more access to what’s going on in the browser than ordinary web apps.
What about native apps? There are different kinds of native apps. Most mobile apps are native apps but these are also quite constrained in much the same way as web apps. Mobile operating systems were designed with sandboxing and security in mind in order to ensure that one app can’t gain control of the system, read another app’s data, or drain the device battery. While there are slight differences between iOS and Android, in general mobile apps on both platforms can’t run background processes or exchange data with other apps.
If it were totally up to Apple I imagine every device, including desktops and laptops running macOS, would look and feel like an iPhone or an iPad where all apps have to be installed and managed through the App Store. Fortunately it isn’t up to Apple and we still have relative freedom in terms of the native apps we run and what we can do with them. Native desktop apps can do more or less anything. Over time macOS and Windows have introduced some constraints on what apps can do—they cannot, for instance, overwrite sensitive configuration files by default—but they do have unfettered access to essential resources including disk and network. This means that as developers we have more degrees of freedom and can do much more exciting things with native apps.
In the context of blockchains and decentralization the most significant of these is P2P networks, which require direct network access. P2P apps need to be able to dial other nodes, i.e., establish multiple outgoing network connections using proprietary protocols (that tend not to work very well over, say, HTTP) and also to accept incoming connections from other nodes. Direct disk access is also very important because it means apps can efficiently read from and write to large databases, something that’s also required for a blockchain. It’s theoretically possible to run a blockchain node in a browser as an app or an extension using technology like light clients or stateless clients, but due to the limitations mentioned above it’s quite hard and I’ve yet to see it done in practice.
One interesting possibility with a native app is that you can have a browser extension that talks to the native app. 1Password is a good example: there’s a slick native app that you can use to manage passwords and documents but also a handy browser extension that autofills passwords on the web, and the two connect and exchange data with one another. This model would also make sense for the app we’re envisioning: you want to be able to quickly bookmark, snapshot, and generally store content you’re reading in the browser, so an extension would make sense. But you’ll have a better reading experience in a native app where you can remove clutter, be more focused, and enjoy a smoother experience than is possible in the browser.
Another advantage of a native app is that it gets its own icon! This might seem trivial but the value to the brand of an app having its own icon is a big deal in a world where we run very few native desktop apps (I’m running 10 on this laptop at the moment). An app with an icon is always visible at the bottom of the screen and it’s visible every time the user switches apps.
Where do networking and P2P fit in? This gets a bit more into the protocol side of things, which we’ll discuss in greater detail in a future issue, but the general idea is that you want to be able to swap content directly with other users of the network without going through or relying on a few centralized content providers. The easiest way to do this is to think of each piece of content as an object, a transaction, or something like a NFT. When you save a piece of content you should broadcast that content or at least the associated metadata to the network, and you should also be able to request and retrieve content from peers in the network. This is how we defeat paywalls and open up curation, and it requires P2P, which requires a native app.
A native app may seem like an app’s final form and the ultimate option for distributing our app, but we’re not done with this list yet and there are a few more stages that we’ll consider.