I’ve mentioned before that the original question we set out to answer when building Farcaster was how could you make RSS competitive with a public broadcast social network like Twitter. The initial name for the protocol was RSS+. Below is the original spec for the idea. People may find it helpful to see what questions we asked and tried to answer when starting out.
What is RSS+?
An enhancement to RSS which gives it a social graph and associated social actions. It’s a way to back into building a Twitter competitor. Solves for the ghost town problem by leveraging existing blogs that already have RSS feeds. Long-term, the graph likely lives on a blockchain to allow developers permissionless access to build a rich ecosystem of different clients, directories, block explorers and custom recommendation algorithms.
RSS is an information broadcast technology (like Twitter)
What killed RSS?
Technical / power user UX for infovores (journalists, investors, etc.)
Google launched the free Google Reader in 2005 and killed market independent RSS readers; better UX but still power user-focused
Twitter (2006) was a simpler UX and dramatically expanded the market for information broadcast
Why did Twitter succeed? mobile-friendly + follow model + discovery + information density (due to initial 140 character constraint) + feed to go during real-time (e.g. plane in the Hudson, Osama bin Laden raid)
Google abruptly shutting down Google Reader in 2013 led to most infovores to move 100% to Twitter
Density due to (original) text-only UI and character limit constraint
Schelling point during real-time event or 24-hour news cycle (#hashtags illustrative but not necessary); the public square of the internet
DMs
MVP decentralized Twitter (with crypto?)
Core actions relevant to the graph
Post
Follow
Unfollow
Like/Fave
Retweet
Put on blockchain
Keep payload extremely small and solve blockchain scaling later – maybe content doesn’t need to last forever?
User name
Pointer to payload (hosted somewhere else like Github Pages, IPFS, etc. – this is key to avoid having to censor; maybe out of the box you can use the default client / hosting; key is exit)
Action
If to another user/piece of content (a fave, retweet, etc.)
Leads to clients that are free but ad-supported or subscription clients
Allows for BYOC (bring your own client) and BYOA (bring your own algorithm)
Create reference directory like Coinmarketcap or block explorer like Etherscan (but others can create their own)
True ownership of namespace, content, graph
No censorship – can’t be evil
Spam problem solved? i.e. cheap enough for legit content producers and free to read but bot accounts are not worth money
3rd party verification service (paid; could be the way for a potential company to monetize)
Why stop at just blue checks? Many different badges for verification!
Namespace mechanics like Handshake or Unstoppable domains
You have the right to sell your name via some DEX but the protocol gets a fee
Potential starting points
The bootstrapping problem here is a classic marketplace: supply (people who publish) and demand (people who read). In almost all cases (and especially early), people will be both. But long-term, the ecosystem will end up in a 90/9/1 distribution.
Usually, I would advise an entrepreneur to focus on high-quality supply—which tends to generate its own demand. In the case of RSS+, this would be about getting high-quality writers/thinkers (who are also friendlys and/or investors) to start using the protocol. However, there’s potentially a compelling argument to be made to build a prototype reference client that mimics the ideal end state by adding functionality to existing RSS feeds (the iMessage approach).
Client
RSS reader
Having our own client will allow us to dog food the potential “+” features for RSS+
Would also allow us to build the protocol iteratively and not as a protocol initially, i.e. the features are only available within the client
If we think we have some amount of product-market fit, we can submit pull requests to open source feed reader projects
Manually curated to start (which improves quality / taste and limits gaming / spam)
Ask friends and infovores for their OPMLs
Extrapolate based on who popular Twitter accounts follow (URL in bio) or Nuzzel-style analysis of domains/URLs shared
Leverage Feedly’s directory
Protocol
Work on a spec documentation for RSS+
Release as a GitHub repo as an alpha
Leverage our combined network to Collison install the basic implementation of Ethereum identity layer on existing websites
Launch 1-2 experiments publicly that shows what you can do with this new graph
At this point maybe you switch over to the highest potential client angle
Potential experiments
ethtweet
Post a “tweet” to the Ethereum and read other tweets like it
Web app that allows you to type in some amount of text in a text box, pay the gas costs, and send a “ethtweet” in a transaction data field. There’s a second tab (“Global”) that shows all previous “ethtweets”.
ethmeme
A Techmeme-like homepage for blogs that embed an Ethereum address
Website that shows you an index all blogs that have an .ens address in the tag of their .index.html. You can submit the blog to the directory and once indexed it displays all RSS posts in chronological order. (If spamming starts, and you wanted to keep iterating, require each new post to have an associated ETH transaction.)
SuperLike
“Like” a blog post on-chain via an ERC-20
Create a faucet for an ERC-20 token called $SUPERLIKE. Blogs embed an ethereum address in each blog post and you can send 1 SuperLike token to the address via MetaMask. Make a single page block explorer showing the most popular SuperLike content all-time and last 24 hours.
Encrypted Tweets
Add a true crypto Twitter on top of crypto Twitter
Fork MetaMask and allow people to do encrypted tweets that need to be decrypted by those with the extension installed. Would natively appear at the top of you feed on the Twitter.com UI.
Questions / underdeveloped thinking
Do you fork Mastodon to be a reference client / server?
Or maybe better model is fork Jekyll static site generator, bundle inside electron app (so you don’t have to install all the libraries via CLI) and have easy posting of content to Github Pages, Netlify, IPFS, etc. (cf. Apple Mail add an account screen)
How full stack do you need to be Day 1?
iPhone didn’t have 3rd party apps to start and every app was built by Apple
Do you do on Ethereum despite congestion today?
Or do you use some Layer 2?
Or do you fork a public blockchain that’s better suited to this use case (strip down functionality)
The essence of the blockchain here is the ability for any developer to hack on the Twitter graph in a permissionless way – clients, algos, block lists, etc.
Is there a hybrid where you run a separate blockchain that’s partially centralized to start – permissioned nodes / validators – with namespace ownership living on Ethereum to give people comfort that they own their names / leverage DeFi stack?
Focus on crypto twitter as initial users?
Open to trying new things
Proof of HODL for people you follow?
Ideological appeal?
X Y Z features that improve crypto Twitter UX?
Related product concepts
Apple’s iMessages (blue bubbles) degrades gracefully into SMS when messaging Android phones or groups with mixed iOS. RSS+ degrades gracefully into RSS?
Wordpress “pingbacks” — a special type of comment when linking to another blog post. What does this look like on a blockchain?
Do you build the reference Coinmarketcap / Etherscan for this protocol?
Feedburner — better analytics for RSS feeds + in-feed ad monetization. Could you use public / private key associated with an account on this network to create individual feeds for premium subscribers?
Memberful — Substack membership stack as a service for Wordpress sites. Private RSS feeds a la Stratechery
Tumblr CMS UI (Twitter is similar at this point – well beyond just text)
