The other day, Billy Markus pitched “you can buy super likes and use them on a tweet” as both a new Twitter feature and a reason to spend money on Twitter.
I’m not particularly invested in designing paid or subscription features for Twitter, but I promised to write up how such a thing could work, because I’ve been thinking about micropayment and tipping systems for a while. After all, we have a pretty good digital currency system with relatively fast confirmation times, a decentralized network, a large market capitalization, and very low transaction fees.
What’s a Super Like Anyway?
Let’s start with some requirements. If this isn’t integrated into Twitter itself (website, app, API, protocol, etc), what is it?
Any user should be able to find a Tweet they like, take some kind of action, and see a visible effect somewhere. This feature should cost money somewhere, somehow, and the original poster should get a percentage of that cost.
Billy’s followups suggest further requirements, including a leaderboard for givers and receivers.
Regardless of the system and how and where it’s implemented, we know a few things already. In no particular order, we need to:
- have access to Tweets
- associate a user with a payment to see if they can perform a Super Like
- associate a Super Like with a Tweet
- associate a Super Like with the author of a Tweet
- account for a payment to the author of a Tweet
- maintain a list of Tweets a user has Super Liked
- maintain a list of Super Likes a user has received
Those are all backend concerns. For a user experience, we also need to:
- provide some visual display or indication that a Tweet has received a Super Like
- display a leaderboard of top Tweeters and Likers
- display a per-user list of Super Likes given and received
Optionally, we can enhance both the front- and back-end concerns with levels, badges, and other visual features.
Note that there’s one big thing missing from this list: a payment system. That’s because I’m assuming it’s already taken care of. There are open questions to the design (Custodial wallet? Address generation?), but first things first.
Backend Design
There aren’t too many items to keep track of on the backend. The data model probably needs a few database tables. I’m assuming a relational backend because near real-time transactional integrity is important.
The data entities include things like:
- a
tweet, which represents a unique Tweet in the system - a
user, which represents a user (probably tied to a specific Twitter account) - a
subscription, which relates to auserand represents a payment and a quota of Super Likes (if there’s a quota system) - a
super like, which relates from auserto atweetat a point in time - a
payment line item, which is a mediocre name but represents a payment made to an address as a result of a Super Like
There may be better ways to model this, but this is enough detail to sketch out further implementation.
The payment system, of course, is providing a unique Dogecoin address for each
user with a subscription, where a subscription is only activated or
refilled when that address receives verified transactions.
Please note that nothing so far limits this to Twitter; the tweet could
become a URI in general to any content available on the Internet, but display
could be interesting if you, for example, Super Liked a read-only page on the
Library of Congress or Geocities on Archive.org.
Front-end Design
Let’s start with a web page. Various pages include:
- show all Super Likes for a user
- show all Tweets with Super Likes for a user
- show a leaderboard of most-liked Tweets by day, month, year
- show a leaderboard of most prolific Likers
- allow a user to authenticate with their Twitter account (to confirm payin/payout addresses)
A Digression about Potential Abuse
Things get tricky quickly, though. Imagine I’m a spammer and I want to send people to a scammy YouTube video to drive engagement to a rug-pulling scam. If I can spend $100 on enough Dogecoin to buy enough SuperLikes to push a spammy Tweet to the top of the leaderboard, can I drive traffic to a scam where I can make 10x or 100x more?
Or imagine a handful of users band together to promote a Tweet inciting rage and vitriol against a certain group of users (“Scarrans go home!") or a specific user (“D’Argo smells like feet!").
That’s not great, so doing this off-platform needs to be mindful of spam, scam, and abuse, just like anything that allows user-generated content. That suggests human moderation at some point early on.
How Does a Super Like Work?
How does this work though?
For a simple approach, create a Twitter bot that gets tagged into a
conversation just like SoDogeTip. The bot looks at
the immediately preceding reply, saves it as a backend tweet, adds a super like to it, charges the user who tagged the bot in the thread, and credits
the user who created the immediately preceding reply.
Depending on the requester’s subscription, the bot will reply with a success message (“Hey, original poster! You just received a Super Like! This post has n Super Likes! You can view its stats at https:…” etc) or a failure message (“Hey, requester! You don’t have any Super Likes left! Go here to top up! https:/..” etc).
The rest of the work is pretty standard backend accounting. Maybe there’s a batch job to process the top n hourly, daily, weekly, yearly Super Likes, or maybe it’s real-time with a cache until there’s a scaling problem.
Pros, Cons, and Alternatives
Using a Twitter bot makes it easy to associate any Twitter account with the
content, as Twitter exposes authentication and authorization information in its
API. A user can explicitly opt out of Super Likes and the bot can ignore any
attempts to like a Tweet, for example. Also an account can provide a unique
Dogecoin address for payouts, or choose to accept a Super Like as part of a
subscription to pay it forward. Possibilities exist.
The same approach would work as well for any service that allows bots to interact with user-provided content: Slack and Discord come to mind, as do Reddit and GitHub. Behind the scenes, a similar data model would work for all of them, as long as there’s a site-specific implementation of what you’re actually Super Liking.
If that expansion to other systems happens, one potential drawback is user identity fragmentation; my identity on Reddit is not necessarily tied to my identity on GitHub in any way the service can easily unify. This can be solved, but it requires some thought.
As an alternate approach, this service could be entirely user-driven, where users use something like a bookmarklet (RIP) or a Pinboard-style service to enter links to content they like themselves as a sort of bookmark-as-Super-Like approach.
Paying creators in that case is trickier, unless you fall back on site
tips, but that’s difficult if you’re Super
Liking a Tweet (Who gets credit in that case? Not the DNS administrator of
twitter.com, of course.)
A different Twitter-style approach could be to require a user to send a DM to the bot to attempt to give a Super Like. This has the effect of cluttering up fewer timelines, but it reduces the reach of the service; potential users who see one user use the bot effectively and publicly learn how to use it by example.
One final thought: related to the spam, scam, and abuse section above, the service gets more value as it gets more reach and visibility. This invites more spams, scams, and abuses because it makes Super Likes in general more useful. I suspect there’s an Internet Law in the making here, if it hasn’t already been formulated, perhaps a Money Corollary to Metcalfe’s Law.
Would I Use this Service?
Before I started writing this post, I didn’t know if I’d use the service.
The more I think about it, the more I like the bookmarking idea. It reminds me somewhat of the Slashdot Moderation/Metamoderation System if it allows different types of Super Likes, like a combination of bookmarking/tagging/categorization.
Then again, I remember the Web 2.0 and Web 1.9 days with some fondness.
Is this system easier to build inside or outside of Twitter? It’s not easy to say. Access to Twitter’s moderation and anti-abuse systems make this system easier to manage ethically for sure, but the technical implementation isn’t difficult for an experienced developer or two to write a good, workable proof of concept in a couple of hackathons, for example.
The difficult parts are, as always, dealing with people. The Twitter API makes these things possible, the backend design is relatively straightforward for the first few tens of thousands of users, and taking payments based on Dogecoin addresses… well, I have a few opinions on how to do that well.
