Home · Posts
Portable Internet Behavior Bond
April 6, 2021

Makers of free apps, including apps with a free plan or trial period, are forced to spend an inordinate amount of time fighting abuse of their services. Twitter has to fight spam bots, multiplayer games deal with cheaters, dev platforms have people scamming CPU time, anything that touches email needs rules and rate limits—the list goes on. This tiresome work is an endless game of cat-and-mouse, and uses time and money that would ideally be spent on improving features for real users.

The "free" qualifier above suggests a solution: charge money. Unfortunately, that isn't tenable in a competitive market. If there's anything worse than wasting time on spammers, it's having no users at all. Consumers aren't willing to pay for Twitter. Even if some were, network effects mean a paid Twitter would be less valuable for everyone. For B2B software, a competitor with a free tier or trial will get more potential subscribers in the door.

What might work instead, if the friction could be lowered enough, would be a fully refundable deposit attached to your account. For example, when you join Twitter, you'd pay $5, with the understanding that you can close your account at any time and get it all back. But if you commit a ban-worthy violation of their terms of service before then, your "behavior bond" would be forfeit.

Adding steps to their signup flow would lose Twitter some users. For this "behavior bond" to be implemented by Twitter or anyone else, the added friction would have to be so low that the number of marginal users lost is less valuable than the energy saved on fighting abuse. Users are very valuable, so this is a tough bar to meet.

The biggest way to reduce signup friction might be for this bond to be shared between sites by a central bonding authority. That way—if this thing can reach scale—a user arriving at Twitter's signup page would only have to go through a quick OAuth-like flow to connect their preexisting Portable Internet Behavior Bond. This central authority could be a for-profit company or a nonprofit. In either case, forfeited money could be used to help sustain its operations, or it could be funded directly by companies using the service.

To keep incentives aligned, it's important that neither the app nor its user gets to decide where forfeited money goes. It's also important that users trust each app to be fair about when and why they ban accounts. Apps are inherently incentivized to maintain a good reputation, and a central authority could also help keep them honest by publishing a public log of bans.

Another way to reduce friction would be to push this functionality further down the stack: from app to browser plugin to browser to. A single bond could also be shared among pools of users, which would be helpful for ensuring a bond is affordable to everyone. 

Cryptocurrency, at least as an option for users, would be helpful in a few ways. First, it would preserve the ability for people to create accounts pseudonymously. (Like signing up for a service with only an email address, as opposed to entering a credit card with your name on it.) Crypto would expand the potential user base. And with enough cryptographic integration, every part of the bond mechanic—deposit, return, forfeiture, and maybe even earning interest—could happen on the blockchain, with its built-in predictability and trustability.

In a parallel universe, sites and apps have been using a bond from the early days of the web; users have it already set up, and friction for each new signup is close to zero. Maybe it's even linked to your 3rd-party authentication mechanism, like your Google or Apple account. In this hypothetical world, developers spend much less time fighting abuse, and as a result we all get to enjoy better software—better features, better design, and new apps that weren't even possible before. I think we can get from this world to that one. Unfortunately, the cold start problem is very hard. Solving it might require a few sites to take the brave first step and implement the feature on their own, before linking up.