Passport Update, Independence and Interoperability, Web3 Use Cases

Posted on Author by Ben Thompson

Good morning,

Tomorrow I will post the last Stratechery interview for the summer; next week is the July 4th holiday, and I will take the rest of the week off for vacation (my alter-ego @notechben will catch a couple of games at Summer League if any of you basketball fans want to say hi). After that will be the annual summer slowdown: three posts a week for the rest of July and the first week of August. As always, the up-to-date posting schedule is located here.

On to the update:

Passport Update

Just over a year ago I launched Passport, the back-end system for Stratechery (Passport is self-funded). Like most new software projects, the thrill of launch was immediately followed by the scramble to fix bugs and the dawning realization that what worked in testing often stumbles in real world use, thanks to both edge cases and issues with scaling. Last summer was spent knocking down most of those bugs, and then we spent a lot of time over the fall and winter reworking some of the fundamental architecture to improve performance; the biggest new user-facing feature we have launched is the ability to log-in with SMS (in addition to email), and to receive SMS notifications of updates.

I’m a big fan of the latter in particular: the SMS notification includes a link to the latest post that is unique to you; that means when you click it the post loads in your default browser without any need to log-in, and you get what I think is the best reading experience — and the target format — for a Stratechery article (anyone who has had to deal with the challenges of email formatting will understand why the browser is always better).

That customization of links isn’t unique to SMS: the show notes for every Stratechery podcast episode include a unique link as well, which is particularly useful if you want to reference a chart or illustration I mention in the voice-over. The most ambitious use of customization, though, is that old stand-by of the independent publisher model, email: every link back to Stratechery is unique to the recipient as well, ensuring that it is easy to read old posts that I reference (this is particularly helpful if you forward the email — which as I note in the footer of every Update is fine on occasion — as the new reader can click-through to the linked articles and get up-to-speed).

This also works back to the scaling challenges I said we had to work through: it is one thing to develop this capability in a testing environment, and it is quite another to deploy it for tens of thousands (or in the case of free Articles, hundreds of thousands) of individual emails. For several months it would take far too long for emails to actually send — tens of minutes, if not more — as fixing one bottleneck would only serve to expose another; fortunately, after some major surgery to our database I/O capabilities, those email sends now happen in just a couple of minutes.

The reason I bring this up is not to pat ourselves on the back; to be honest, we launched Passport too soon, and I apologize to everyone who encountered challenges, particularly last summer. Nor is it to say that our experience was unique: scaling is a challenge for every single software project out there. That, though, is my point: scaling software is just as difficult as building it, and those challenges tend to increase exponentially with usage.

Independence and Interoperability

Passport isn’t just about customized links: while I wanted to build a toolkit to leverage all of the open protocols to connect with subscribers — web, email, RSS, podcasts (built on RSS), and SMS — it is the connection part that matters most. That means that Passport is more useful to me as a creator if I can also connect with my subscribers on other platforms as well. The most obvious example of that in practice today is Spotify: while I personally use an RSS-based podcast client, the reality is that a lot of my subscribers listen in Spotify, which ingests podcasts via RSS, but then serves them to users using their own proprietary streaming architecture. This means that podcasts on Spotify are free, but they aren’t open (which I castigated the company for when Dithering launched).

This is also why I was so excited when Spotify launched its Open Access Platform: using OAuth Stratechery and Dithering subscribers can link their accounts to Spotify, meaning they can listen to my paid content on Spotify’s closed platform, without my being beholden to or dependent on Spotify itself (this isn’t unique to Passport, by the way: almost every paid podcast platform has now implemented this functionality). I consider this the sweet spot for creators: would-be Aggregators like Spotify are investing heavily in delivering a great user experience at scale, and it’s great if I can benefit from that, but I don’t want to be locked in to any one platform.

This allergy to lock-in exists for several reasons:

  • The obvious ones are editorial independence and business risk: while I certainly don’t anticipate writing anything that would lead to me getting kicked off of any platform, on principle I don’t want any single entity having total control of my livelihood. Similarly, while I don’t expect any of the major Aggregators to go out of business anytime soon, I don’t want my fate tied to any other company either (or, in a more likely scenario, an about-face in their commitment or terms for independent creators).
  • The second reason is that bit about connecting with my subscribers: the goal of Passport specifically and the independent publishing model generally is to forge that direct connection with customers. Having an intermediary that owns that relationship makes it more difficult to serve those customers in ways that fall outside of the terms set by that intermediary; this is why I’m personally not interested in Apple’s podcast subscription offering, which may make it easier for me to collect money, but at the cost of having zero knowledge of who my subscribers are, or being able to communicate with them directly.
  • The third reason is directly connected to the second: Stratechery isn’t limited to a single medium. From my perspective the core product are the posts that I write, but I understand that people consume content in different ways, so I also offer my content in podcast form. Moreover, sometimes it makes sense to mix-and-match: another Passport feature is that you can choose to receive Article and Updates via email, but interviews via podcast (interviews, unlike posts, are an audio format that I also deliver via text).

The problem with this last point is that most platforms are defined by their medium: YouTube for video, Spotify for audio, Substack for text, etc. Sure, they are branching out — YouTube music, video podcasts on Spotify, and Substack supports both podcasts and video — but as a creator I would rather have my content where my subscribers prefer to consume it (i.e. if I were to launch video I would like it to be on YouTube). In other words, while platforms start with their medium and sometimes branch out, I as a creator want to start with a direct connection to my subscribers and enable them to access my content wherever it makes the most sense (this is the genesis of the Passport name: you ought to be able to carry a credential with you to other places that gives you special privileges).

Ideally, though, a Stratechery subscription would mean more than content: while I will always want control over where my writing/podcasting/videos are published, it would certainly be nice if being a Stratechery subscriber offered other types of benefits. Because I control Dithering I can offer a lower price to Stratechery subscribers, for example, but it would be neat if other people could offer similar discounts; other subscribers may be interested in the sort of community aspects that I haven’t heavily invested in, but they have no way to ascertain who is a subscriber and who isn’t, unless I were to build some sort of integration with the service or entity they are interested in. That’s the big limiter: it’s very cool to have the possibility of connecting to other platforms and services, but all of those connections need to be negotiated and built on a bespoke basis.

Web3 Use Cases

Charlie Warzel wrote in his Atlantic newsletter about The Petty Pleasures of Watching Crypto Profiteers Flounder:

I cannot stop watching videos of Web3 boosters failing to explain the usefulness of the technology. I realize this is petty, but the videos are deeply cathartic. I’m talking about two clips in particular, both of which were posted by Liron Shapira, a tech investor and writer, and a critic of crypto and Web3. The first is of Packy McCormick, a newsletter writer, investor, and advisor to A16z’s crypto venture-capital team…The second clip is of A16z co-founder and venture capitalist Marc Andreessen during a podcast taping with economist and blogger Tyler Cowen.

Warzel’s point is that both McCormick and Andreessen stumble when pressed for specific articulations about what benefits Web3 provide that current technologies do not, and it’s a point that I sympathize with, particularly as a creator. I wrote last year in a Daily Update responding to this post arguing that Web3 represented “A Golden Age for Content”:

The article starts out with that trope about the lack of payment infrastructure being the original sin of the web — but, well, this is where I go back to Apple’s App Store study. Just as Apple ignored decades of independent developers selling software directly on the Internet, so do articles like this ignore a decade of progress in online payments, and by extension, the very real ecosystem of creators that is thriving online.

I am, of course, an example of this; I started Stratechery in 2013, and thanks to the incredible asset that is social media — if your primary marketing tool is word-of-mouth, then services that give your customers a voice are incredibly valuable — I was able to go independent in 2014. It wasn’t super easy — Stripe existed, but lots of other pieces of the stack had to be glued together, and I still have nightmares about launching and being unable to accept payments for 24 hours due to an SSL error — but it was definitely possible; still, skeptics argued for years that “That’s fine for Ben”, the insinuation being that I was some sort of unicorn. In fact, one of the most exciting stories of 2021 has been the absolute explosion in subscription-based blogs, primarily thanks to Substack, very much a web2 company. Other mediums like podcasts aren’t far behind.

I do recognize that subscriptions don’t make sense for all kinds of creators, or all types of creations; I think that a lot of the froth around NFTs are a bubble, but I also think there is something real there as well, particularly as the virtual world surpasses the physical one in importance. I also buy the arguments around community and shared ownership. Highlighting those potential opportunities, though, does not require misrepresenting the Internet and the opportunities it has already created, ignoring all of the creators who have already seized them, and obscuring the potential in abundance that has only begun to be tapped.

One of the fundamental issues I have with the Web3 rhetoric is that so many folks seem insistent on re-inventing the wheel; worse, they are seeking to do so with technology that is fundamentally unsuited to the task. This is why I discussed the scaling challenges with Passport: building infrastructure that serves even a relatively small amount of people is extremely hard, and that is when everything is fully under one’s own control. The idea that you could build a publishing platform “on the blockchain” that is remotely performant or economical is and always has been ridiculous, and declarations as such deserve the backlash they have generated.

At the same time, I have been and continue to maintain that there are real use cases for blockchains, and I just laid out the two big benefits for creators above: independence and interoperability. Suppose that a platform like Passport — which to be clear, is very much a “Web2” application — had some meaningful number of creators using it. Passport (whether it be a centralized service or under the independent control of a creator) would service those creators and their users using traditional server technologies, because that is the only way an application can actually function on the web — I know viscerally that database performance is a big challenge! At the same time, user identifiers and their associated entitlements could also be written to a blockchain. This would enable three things:

  • First, creators would have full independence from any one centralized platform; their record of subscribers would be permanent and immutable.
  • Second, subscribers would have full independence from creators; their record of entitlements would similarly be permanent and immutable.
  • Third, anyone, from big platforms to other creators, could access those subscription records, and offer whatever benefits they choose.

These features could unlock some of the use cases I noted above: first off, creators would be fully independent; secondly, subscribers could build their own communities, and maintain them even if a creator closes up shop; third, platforms that specialize in different mediums could service cross-platform creators, even those who are “at home” on would-be competitors. This was a benefit I talked about with Head of Instagram Adam Mosseri earlier this year:

I guess the question, though, is from my perspective, creating Passport, “Hey, let’s talk. I’d love to sign up Instagram” and say, “Hey, I can bring my creators there,” or wherever it might go, but when you’re coming at it from the other perspective, why would other people want to work with you, whether that be the creators who might think “What’s Instagram going to want to put over on me here?” or I think more pertinently, you talk about competition. This vision you’re talking about basically entails some sort of cooperation between these competitors, such that creators can move seamlessly between them. What would cause that to happen?

AM: I love this question. A couple different things. The subscription idea and the version that I’m pitching of it is similar to Passport, but it’s on-chain. I want to be clear, I’m not a crypto bear, I’m not a crypto bull, I do think we should be intentional about what technologies are actually better suited to these ideas. This idea doesn’t have to be built on-chain, but there’s something I think powerful about it being built on-chain and we can go more into why, but it doesn’t have to and I want to be clear about that.

No, please do because actually, I have my own suspicions why being on-chain is important, but I’ll let you give a shot at it first.

AM: Yeah. So just to be clear about the idea, the idea is essentially a token that’s a membership card and if we can get enough of the major platforms to honor that membership card-

A Passport, you might call it.

AM: A Passport, you might call it — exactly, the branding is hard! As I try to come up with names, I’ve been like, “Oh man, Passport is actually, I kind of get why you ended up there.” Makes sense to me.

As far names go there is nowhere to go but up after naming Stratechery!

AM: (laughing) I didn’t say that! But yeah, let’s say you get big on Instagram and then later you want to branch out into YouTube. That can happen, we actually see that a lot, we see creators establish themselves on our platform and then go out onto other platforms. Sometimes they go into new media types, sometimes they even just go to other platforms to syndicate their content.

If we can get both YouTube and Instagram to honor that same protocol for a Passport token or a membership card token, then you can OAuth on both sides, and then not only could you bring your subscriber base with you, but everyone who subscribes to you would have to do so only once, and that’s also powerful.

One of the reasons why I think building it on-chain is appealing is because, this isn’t technically necessarily how it would have to work, but I think it’s how it would most likely work is, because it’s built on-chain, no company could ever take that community away from you. We could go under, someone else could come up and you would still maintain your relationship with your subscribers and that income.

Right. You could cut off YouTube basically if you decided, “Actually, we don’t want to cooperate with YouTube anymore. We’re going to turn off the integration.”

AM: Oh no, I don’t think we would build it.

Yeah, you would not be able to do it.

AM: Yeah, no, I couldn’t do that. And yeah, you could get de-platformed from Instagram, let’s say it was you, we could say “You’re no longer allowed to be on Instagram”, but even if you had acquired all the subscribers a hundred percent through Instagram, you would still have a relationship with those subscribers because other platforms would honor them, and then you could actually retroactively move to another platform.

In short, if there is ever going to be a way for the big platforms to effectively work together to the benefit of individual creators, it will have to brokered by some sort of neutral entity that isn’t competitive with or beholden to those platforms; neutrality and independence is exactly what blockchains are uniquely suited to provide.

There still is, to be fair, a bit of hand-waving here. There are fundamental issues about privacy, performance, and the fact that it’s always difficult to herd cats, particularly when those cats are world-devouring lions. I grant all of those caveats, and acknowledge many more, but still maintain that the fundamental concept of a neutral arbiter that doesn’t provide a service itself — because it is fundamentally unsuited to that role — but rather adds a thin layer of authentication on top of existing, scaled services that invest heavily in the user experience, is extremely interesting, to me anyways.

One more thing: for all of this to work it will need to be completely invisible to end users. No one needs to know if their web application of choice uses MySQL or PostgreSQL or MongoDB or any other database, or a blockchain (and the later, as I noted, is at most a very thin layer only accessed occasionally — indeed, most integrations will likely happen via some sort of centralized service that is actually performant, with the blockchain a record-of-last-resort). It also won’t entail anyone getting rich off of some token. In other words, it will be counter to so much of what Web3 rhetoric has been about: instead of rebuilding everything, but “on the blockchain”, with tokens that mostly serve to make the issuers and their financiers rich, the underlying tech will be another tool to make the technologies we have been building for the last 50 years a bit better and more useful (this is also why I can’t say I’m particularly broken up about either the ongoing crypto crash or the backlash to Web3: there is a ton of cruft that needs to get swept away and crap that needs to be refuted before actually useful stuff can be built).

This Update will be available as a podcast later today. To receive it in your podcast player, visit Stratechery.

The Stratechery Update is intended for a single recipient, but occasional forwarding is totally fine! If you would like to order multiple subscriptions for your team with a group discount (minimum 5), please contact me directly.

Thanks for being a subscriber, and have a great day!