OP_RETURN Social (ORS) is an open social protocol where every interaction is a bitcoin transaction:
- Posts, replies, reposts
- Follows & unfollows
- Profile updates
Try the reference client for free: https://opreturn.social
- All interactions are published to testnet (Mutinynet)
- Optionally pay to publish posts you want to preserve to Mainnet
Free transactions will be shown by a gray box icon, instead of an orange one.
ORS is "BIP-110 compatible" by using a wire format that supports concatenating 80 byte OP_RETURN outputs from multiple transactions. The cost to do this is negligible compared to posting a single transaction with >80 byte OP_RETURN.
OP_RETURN is a provenly-prunable way to embed arbitrary data in bitcoin without bloating the UTXO set. Any ORS post FUNDS the network. (read more here: #1266126)
I think there are some fun things to be explored, especially around WoT & reputation, to both reduce spam and create quality feeds. I also plan to add notifications, reactions, and search next.
Everything is open source - If you're interested about the protocol, you can learn more about it ORS here: https://ors.dev - try building your own client!
not a good idea apps with an onchain footprint.
Where's the dark mode?
Oh, right. I've added an issue: https://github.com/opreturnsocial/opreturn.social/issues/16. Thanks!
The architectural tradeoff here is interesting. Nostr chose off-chain events with relay infrastructure: fast, free, but dependent on relays staying alive. OP_RETURN Social puts everything on-chain: permanent, censorship-resistant at the base layer, but constrained by block space and fees.
Both solve the same problem (platform-independent social data) from opposite ends. Nostr trades durability for speed. ORS trades speed for durability.
The testnet/mainnet split is a clever middle ground. Low-value interactions stay cheap, high-value posts get settled on-chain. Basically a fee market for attention. You only pay mainnet fees for the posts you actually want to last forever.
Curious how this handles the data availability problem long-term though. OP_RETURN outputs are prunable by nodes that don't care about social data. Will there need to be dedicated "social indexer" nodes that keep the full OP_RETURN history? That starts looking a lot like... relays.