The Interledger Community 🌱: Jesse von Doom

My time with Grant for the Web

Jesse von Doom — Fri, 14 May 2021 21:28:26 +0000

This is my final report as an ambassador for Grant for the Web, and I cross-posted it to my personal site. It's the kind of writing you wish you had another week to edit, but in a week you'd still want more time. A lot of you here will know all of my rambly context already, but I wanted to write something friends outside of these circles could understand.

I've had this exact conversation so many times now, and every time it reminds me how much history and background is needed to understand the potential impact of Web Monetization.

Since last year I’ve been an ambassador for Grant For The Web, an organization founded to push for open standards around payments on the web. The role of “ambassador” has meant being part researcher, part tech evangelist, part tinkerer, and part advisor. The end of my tenure as a Grant for the Web ambassador is here, but all of the parts I just listed are still going to be a part of me, and my support for Grant for the Web is stronger than ever. Put simply: it’s a vital effort led by a rich community of amazing people.

Grant for the Web supports and promotes the Interledger protocol, which is at the heart of the proposed W3C Web Monetization standard. I thought the best way to mark the end of this time would be to talk about my experience, my perspective, and everything I’ve learned along the way.

I suppose the story has to start with some context around payments on the web, cryptocurrency, smart contracts, and some of the impact those things have on creators and culture.

Money and the web

Micropayments have been a challenge online basically forever. Credit card networks aren’t set up well for smaller payments of only a few dollars, and even PayPal isn’t great at a dollar or less. Much like Amazon gave rise to unrealistic expectations around shipping times, buying a song for a dollar in the iTunes store set some weird precedents for buying digital goods. Apple has the sheer volume of transactions and cards on file that lets them group payments together and get better terms than any independent creator could ever hope for. If consumers assume that 99¢ apps and songs are the norm, independent creators are left people beholden to the whims of digital platforms.

So credit card networks are what we know. They work online, but not particularly well, and their limitations shape our consumer experience online.

Digital currencies spawned for all sorts of reasons, but at least partially as a reaction to those limitations. Cryptocurrency brought an explicitly decentralized hope to the scene. Instead of platform-specific digital currencies we started talking about transactions on a blockchain, direct from one party to another, without the need for any sort of intermediary network between them. This was exciting because it went beyond just a fix for microtransactions — decentralization has the potential to break platform payment dependency entirely. But blockchains also introduced new issues: high energy consumption, a new regulatory landscape, and an unfamiliar customer experience.

Cryptocurrency evolved beyond just transactions and introduced smart contracts, with almost limitless freedom to explore new and direct payment models. Smart contracts are the driving technology behind NFTs, and effectively make money programmable. You want to sell something today with the condition that you get a cut of any resale? No problem. Virtual goods and unique experiences now sold with enforceable terms built into the currency itself.

NFTs and how we perceive value

The NFT boom has been a polarizing force in the conversation around money, payments, and how we support creators. So much so that I’ve wound up avoiding it entirely, trying to understand how people who all talk about a better future for creators through rethinking money can be so far apart. I’ve seen valid arguments proposed and ignored on both sides of the NFT hype. I find myself more or less disinterested between both sides. I can see the potential that fans of NFTs argue for. Smart contracts offer a blue sky of possibility to independent creators. There are also legitimate criticisms of the technology in its current form. Speculation, scammy NTF platforms, and consumer confusion can lead to bad experiences and there are still concerns around the energy consumption and sustainability in the core technologies.

My approach is to see how it evolves and root for the best possible outcome for everyone. If you’re on the side of creators then we’re on the same team. The need to find more and better ways of supporting independent workers and artists is critical and more where my interests lie. The web opens up so many possibilities for person to person connection, so smarter money and contracts that can work with the web feel overdue. How we get there is being sorted now, and it looks like there’s no stopping it. The best we can do is push for equitable, green, and accessible technologies — including non-cryptocurrency options.

If we have the means to make smarter and more direct payments then we have an opportunity to reshape how we think about value itself. This is what I’m interested in. NFTs feel like the final boss stage of market economics. Smarter deals tied to currency as a platform, but its value remains derived from scarcity — mining or staking and the rarity of the tokens themselves. This is familiar and okay. It’s our default understanding of value.

When we talk about the value of art and culture we talk about reverence, impact, and reach. Its value grows as it’s shared, rooted in abundance and human experience. We talk about best-seller lists, ratings, and song charts to show a work is important. But the arts and humanities go deeper. There’s value in the conversations they spark, the lives they connect, the first dances, and all the other shared moments. Creativity gains value as it becomes more abundant.

If you get on top of the charts or the best seller lists you’re getting paid. But so much of that relies on major marketing support. What about independent creators? Can we rethink models to reward value based in abundance? How do those complement existing models?

Enter Web Monetization

We’re finally getting to the part about Web Monetization and Grant for the Web. A huge part of my ambassador role with Grant for the Web was talking to people about Web Monetization. The more conversations I had, the more convinced I became that it’s an important piece of fixing payments on the web, and equally important to our understanding of value itself.

When you look at payments online you’re looking at an ever-changing scaffolding built on a rotating cast of APIs and platforms, mostly held together with duct tape and data entry. Web Monetization is a proposed W3C standard that defines new ways for a browser to send payments direct from one person to another, simple and secure in a browser. The W3C is the organization that maintains the reference specs for things like HTML, telling browser makers how they’re supposed to turn code into a webpage. Web Monetization and its underlying Interledger Protocol do the same thing but for payments.

Pushing for standards is slow work, but it’s critical because it helps to shape the landscape but doesn’t throw away working solutions. Traditional payment stacks continue to work just fine, and can even be integrated with Interledger payments to provide a range of options and models. Interledger payments don’t care what currency or wallet service you’re using — could be cryptocurrency, could be your bank if they support the protocol. Standards enshrine interoperability. This builds a little stability in how websites and apps initiate transactions while not slowing any of the innovation and evolution needed to make the currencies payments rely on work better for everyone.

A payments standard defines the types of payments available to developers. Interledger is built around a concept of streams — you can make one-off payments, there’s a spec for recurring payments, but you can also stream payments in the background of a website. Fractions of a cent flowing every second — and if you’re reading this with a Web Monetization plugin like Coil then it’s happening right now. Coil works as a subscription service — every month I give them five dollars and their plugin uses Web Monetization to spread that around to all the sites I visit that have a Web Monetization payment pointer tag.

There are a couple cool things happening here. First, this isn’t a service or a platform. It’s people actively choosing to support other people, opt-in and powered by direct connections. And a Web Monetization stream communicates with the browser, meaning it’s not only programmable money, but real-time programmable money. A developer can write code that reacts to your payments.

The big players using the Web Monetization standard today are YouTube and Twitch. Streaming payments just make sense for streaming content. Twitch even auto-detects payment streams and converts them to Twitch Bits, their platform-native Twitchbucks, with no setup needed by the streamer.

There are also many examples of sites offering special content or removing ads for people who’ve enabled streaming payments. Right now that’s a pretty niche slice of visitors, but as Web Payments keep moving towards a final W3C standard they get closer to being supported directly in browsers, expanding the audience. If streaming payment revenue grows bigger than ad view revenue you disrupt the ad industry while helping the people who rely on ads. New payment types lead to new opportunities to innovate.

The big idea

Web Monetization isn’t designed to make new billionaires or make headlines. It’s been designed to let hundreds or even thousands of smaller streaming payments add up to significant revenue for creators. By including direct payment streams Web Monetization is helping us explore new models. It naturally lends itself to seeking value in community, connection, and abundance.

This was my big Web Monetization epiphany; the connection from payment streams to new models to broadly rethinking value.

My focus, then and now

My initial work with Web Monetization centered on a project called Substation. I built Substation for some friends who wanted to make a paid newsletter but not be bound to a platform, just direct connections between them and their readers. The appeal is obvious, and the scope of the work was to dive into the spec for Interledger pull payments and think about what could be possible as it matures.

Pull payments are the Interledger equivalent of recurring payments. On the surface you can map them 1:1 with credit card subscription payments. Under the hood it’s a little more interesting because it would still do all the direct payment and currency transformation magic of streaming payments, but with a negotiation phase that sets things like the payment amount, interval, etc. This puts an emphasis on clear terms and active consent as every new pull payment subscription is created. It also means the agreement between parties is actually encoded directly into the payments — integrated context like smart contracts, but just not quite as smart. Honor roll, but none of the pressure of speaking at graduation.

Pull payments are still in the initial spec phase. They haven’t been implemented in production wallets so there’s bound to be changes, but things are defined well enough to let us plan for the shape of subscriptions to come. The upside for creators is huge — moving to direct payments saves fees and enables microtransactions in ways that are impossible in traditional payment systems. A dollar on a credit card network is worth less than 70¢ to a creator but Interledger doesn’t impose network fees. Even if wallets are charging exchange or subscription fees, it’s unlikely they’ll take even close to the cut of a credit card transaction.

The ability to unlock significantly lower cost, lower friction subscriptions feels like a dream worth chasing. I dusted off an old concept from a project where we were supporting REST-based Stripe payments alongside PayPal’s classic redirect-and-return payments in a single checkout flow. You’ve seen it plenty of times: you’re checking out and given the option to pay with a card or to use PayPal. Seeing Web Monetization next to familiar payment experiences will help normalize the standard and accelerate adoption.

The trick we used in that project was to wrap out all payment libraries in a common object format that understood seven phases of a transaction, even if there’s nothing to do in some of those phases for the particular payment type:

getSecrets: get any API keys or secrets needed to initiate a transaction
getTokenInformation: use those keys and secrets in a token exchange
prepareTransaction: handle any additional steps needed between the token exchange and making the final transaction
getRedirectMarkup: get any markup needed for a redirect-and-return payment and show a button, instructions, etc
handleRedirectReturn: get context from the token and/or URL parameters in a response from a redirect
doTransaction: process the transaction with the payment service
finalizeTransaction: do any post-transaction cleanup, record in any local systems

The north star is a JavaScript library that can be dropped into any website, and work more or less automatically with credit card networks, services like PayPal, and Web Monetization/Interledger payments all side-by-side. Walking through these phases allowed us to map wildly different payment processes to a single, familiar checkout flow. And the more familiar we can make Web Monetization, the easier adoption gets for people who don’t want to think about value, payments, and the future of money just to pay a writer for an essay.

My guess is that Interledger pull payments could take some time before we see rich adoption. Some of the things that make cryptocurrencies appealing — peer to peer payments and the anonymous nature of wallets make recurring payments harder. A bank account is a far more permanent thing than a crypto wallet address. Recurring payments may always be more or less dependent on third party services of some kind, and this is what started me working more with streaming payments.

I started this keen to think about interoperability and normalizing Web Monetization in subscription flows. Now I’m more excited about the potential streaming payments have to inspire new models and reshaping the concept of value.

So what now? What’s next?

Like I said at the start, the end of my ambassador role is only the beginning of my support for Web Monetization and the people working on it. At some point I’d like to explore the approach outlined above with one-time payments. I still think the goal of normalizing new payment standards is an important effort.

A couple months ago I took a new day job as Head of Product for Glitch, so I rebuilt my personal site using our Eleventy starter app and added a payment pointer. In total it took me about five minutes to get a basic Web Monetized blog up and running. (Then four hours of tweaking layouts and other critical infrastructure tasks like cleaning up racoon illustrations.) I managed a dirty proof of concept for a quick feature that would allow someone to move posts from another source via RSS — but it’ll be a few weeks before I can finish that up. I’d like to help people find an easy off-ramp from platform lock-in that leads to publishing their own Web Monetized blog. That’s probably next.

I’m also curious to play with bridging front-end Web Monetization with the server. I’m sure there’s already some work happening on that front that I haven’t found yet, but it’s a part of Web Monetization that seems to have a lot of potential for new ideas. I can’t wait to learn more about it.

I suppose talking to people about Web Monetization won’t be something I do in an official capacity anymore, but it’s not something I’m about to stop doing, either. Say hi anytime.

Bundling a front-end library?

Jesse von Doom — Tue, 05 Jan 2021 17:02:25 +0000

Hey there — wondering if anyone here has experience with tools like webpack and rollup.js when it comes to bundling a front-end library? (As opposed to an app for deploy.)

We've been evaluating rollup and webpack, with pros and cons to each. Like any library we've got a few dozen "oh yeah but..." requirements. Code could use a refactor. All that. This is going to get more important in the next few months, but isn't a top priority right now.

I'm not looking for an answer to a specific issue, but hoping to see examples of how other front-end libraries are broken up for easier community development and packaged up for release. I've found a few, but would love any thoughts?

Substation — Grant Report #1

Jesse von Doom — Mon, 14 Dec 2020 22:02:58 +0000

Project Update

Since this is a public report, I felt like the best way to start is at the very beginning.

Hi. I'm Jesse and I'm working on an open source subscription platform called Substation. I've been working in open and open source contexts for a long time, almost exclusively in nonprofit or self-organized projects. Substation has been conceived as a for-profit with commitments to open and ethical practices built in from the beginning. That's a change for me, and while it isn't the focus of my Grant for the Web ambassadorship, it is a huge challenge and better organizational models are a passion of mine — so reach out if you're thinking about entity structures, ethical business practices, or even just "should I work as a nonprofit or for-profit?" I'd love to hear your thinking.

The focus of my work here is on supporting recurring web monetization payments alongside "traditional" credit card and paypal transactions. We've been building slowly and modularly, with a lot of the most relevant work happening in a standalone JS library we called "Lodge." Lodge is meant to manage iframe embeds and let them securely coordinate with a central page on some basic app-like frameworks to display messages, request input, and handle a checkout process — all in a universal overlay. We're aiming at "more decentralized" in an age of centralized platforms in hopes of pushing mainstream audiences to become more familiar with the idea of decentralization in general.

This autumn has been a challenging time for a lot of people, myself and the Substation team are no exception. Personally, I've found my pace slowed, recovering from setbacks has taken longer, and context switching feels harder. I mention it because, well, I'm not alone in my circles feeling this way. If you're feeling anything similar I hope you don't feel alone in it either. I also mentioning it because on first thinking about this report I thought about timelines and tasks and felt a rush of failure. After taking a step back and a deep breath I could see how much we've accomplished through trying times. We've moved Substation forward as well as Lodge, we're working towards a more complete UX exploration and web monetization integration plan than I could have imagined at the start of the project, and we're helping launch the first project built on Substation's initial (and evolving) DIY version.

It's been a hard year for many, and it's important to recognize our accomplishments even when things haven't gone according to plan. So the shortest summary is this:

I'm disappointed by my own pace, but I'm proud of what we've accomplished in a difficult year. More importantly, I'm hungry to keep moving.

Progress on objectives

In the proposed project scope we broke things down into research and experimentation work, a UX report with designs / examples / demo code, and a plan for full integration of web monetization in Substation. Those three buckets are still the right framing, but we've spent a fair deal of extra time on the Lodge technical architecture because we saw the value in the checkout flow as a fully independent library.

It felt like a lot of behind-the-scenes work, so I took our internal notes and finally pulled them together to make something between a spec and a status report in one doc. (It's a google doc. I made sure to allow for commenting — if you're curious about any of it feel free to reach out or just leave a comment in the doc.) I think we've done our research and internal experimentation, we're in-progress on demos now, and still have to finalize a proper report and some code samples.

A few extra links:

There are also things that happened this year like the Substation business plan and pitch deck that feel like tangents or somehow out of scope. If you're working on similar things and want some examples or here about our work there just reach out. Happy to share anything or spend some time talking about it, even in the tangents.

Key activities

Here's a list of milestones from the last few months.

Scrubbed and refactored Lodge JS code to get it ready for checkout flow tests and mock-ups alongside live code
Final brand for Lodge is done and new public site, docs, and demo page are in-progress
In the larger Substation context, we've got the bones of our server-side APIs written to an internal spec — probably about 60% of the way to an MVP (also open licensed, but still in private repos until they're a bit further along)
Substation business plan and pitch deck are prepared for a push for funding starting in Q1 2021
Despite hiccups, there's a first full project built with the Substation DIY version launching in the next week or so

Communications and marketing

This is usually a strength for me but with progress slowed most of the planned comms work for Substation was pushed until January. In September I published a blog post on my history with subscription payments for creators and why I'm so excited by web monetization and the Grant for the Web program as a whole. In the new year we have posts planned about Lodge, another about alternate payment methods (web monetization meets mutual aid as a theme), and our UX report on recurring payments and enabling multiple services side by side. I'm looking forward to being more vocal again.

What’s next?

This progress report marks something close to the 65% mark of the planned project scope, and with pace picking up again things will be complete in January. To get there, we'll first finish up a public page for Lodge with a feature list, project status report, and working demos. With that finished we'll publish complete UX designs for the checkout process, along with demos, issues, and specs for future progress. Then another blog post, this time focused on a general look at what was learned, next steps towards full interledger integration, and an invitation for anyone to get involved or use what we've learned.

What community support would benefit your project?

Part of the reason I wanted to go deep here, and open up personally a bit, is to feel more accountable to this community as a whole. The motivation of knowing you're a part of something bigger really helps to push you on. The other big community benefit, beyond direct collaboration even, is trading notes. Seeing what we've learned, and helping it spread.

Hi everybody!

Jesse von Doom — Fri, 20 Nov 2020 18:16:53 +0000

Okay so this is obviously not far from the default "hello world" but I'm excited to kick the tires on this new platform a bit and connect to more people in the growing GftW / Web Monetization community.

I plan on exploring a little more, adding more about my own work, and hopefully learning more about yours. So for now: hi! Can't wait to dig in.

xo,
j