You can add location information to your Tweets, such as your city or precise location, from the web and via third-party applications. You always have the option to delete your Tweet location history. Learn more
Blockchain world can learn a lot from p2p file sharing era
Incentive issues (most shared NOTHING, tons of fake files + viruses)
Lots of attempted market mechanisms (from game theory to tokens) to fix incentives
Monetization lessons
Forking vs governance
Thread 
![Ragna [Jan/3➞₿🔑]](https://pbs.twimg.com/profile_images/1006190477274701824/Oy2AiCrs_normal.jpg)
Tokens are clearly good for balancing incentives. p2p attempts from 15+ years ago: • Mojo: a liquidatable token to incentivize sharing storage, bandwidth, CPU • eMule credits for upload/download • Lots of research on p2p tokens (PPay, PeerMint, PeerMart) • Kazaa PeerPointspic.twitter.com/AN2VHiqzAV
If you're building a fat protocol, putting ads in the thin client is a terrible way to monetize! In file sharing days, people created lazy patched clients like "Kazaa Lite" which JUST removed ads. Reputation of bundling "AdWare" and "SpyWare" killed trust of creators.
3rd party companies building on top of your protocol help you find product market fit. Normal startups iterate sequentially; fat protocols can iterate in parallel
BearShare built features that Limewire users wanted like video preview
eMule improved on bad UI of eDonkeypic.twitter.com/G0CjFBK3NG
Decentralized fat protocols out live the companies that create them • Nullsoft launched Gnutella protocol but Limewire/BearShare built the apps we all know. Forks like FrostWire live on eternally • OSS eMule built on eDonkey's networks after they died and even improved on it
While fat protocols compete, 3rd party apps can unify and create a better experience. Popular file sharing app "Shareaza" searched EVERYTHING by implementing Limewire, Kazaa, eDonkey, and BitTorrent. Open source giFT project provided generalized backend for thispic.twitter.com/ub0hoW0oNF
Third party apps provide continuity for users by switching protocols if it makes sense. When FrostWire (fork of Limewire) realized BitTorrent was the winning protocol, they added support. Now it is JUST a BitTorrent client. Users don't care about protocols!pic.twitter.com/QlZArmOw99
If fat protocols are sufficiently general then thin applications can find product market fit by specializing. PopcornTime (backed by BitTorrent) is a great example where it specializes both by content (movies) and mode of consumption (streaming only)pic.twitter.com/AELPAspUc6
Decentralized protocols evolve under collaboration+consensus and fork under contention • Gnutella evolved from 0.4 → 0.6 via community consensus. Took years • eDonkey kept Overnet protocol proprietary. eMule community says fine & builds "Kad network" (fork by clone). Kad wonpic.twitter.com/PB3SvYvSJ9
When we say a protocol forks, we're really talking about communities forking. Tons of developers worked on Gnutella 0.6 (protocol for Limewire, BearShare, etc). When a random dev proclaimed he designed "Gnutella 2.0" on his own w/o peer review, people were PISSED. Boycott!pic.twitter.com/rWBEYLDXG8
No token? Enjoy your tragedy of the commons!
File sharing protocols had the problems you'd expect when a market fails at resource allocation.
70% of Limewire users didn't share ANYTHING. Even more shared nothing of value
Kazaa struggled with fake files and virusespic.twitter.com/0I5rhs1MKv
People will build businesses on exploiting your protocol's bad game theoretics if you let them! A strong Kazaa "participation level" meant faster downloads. Clients self-reported participation level. The K++ client spoofed max participation so users got better download speeds.
Well designed game theory can make a protocol better though. Big reason why BitTorrent is so fast!https://twitter.com/backus/status/999519259628732416 …
Decentralized protocol market mechanisms people experimented with: • Targeted game theory (http://bittorrent.org/bittorrentecon.pdf …) • In kind resource accounting (tracking just upload vs. download) • In-network token you can't cash out • Generalized and liquidatable tokens
MojoNation tried building IPFS+BitTorrent w/ a token in 2000. Quote from thread w/ @NickSzabo4 and @zooko:
> The smartest thing [@bramcohen] did when stripping down MojoNation to create BitTorrent was conforming the digital resource mechanism to the actual behavior of the users
Quote is from MojoNation founder Jim McCoy by the way. Source: https://unenumerated.blogspot.com/2007/06/nanobarter.html?showComment=1181708460000#c2518193502558600657 …
@NickSzabo4 later jokes about the commenter being "anonymous" while using "we" to refer to MojoNation team. Later identifies as Jim McCoy. 
Whole thread is a valuable read
MojoNation was a visionary project. In @zooko's post mortem, he mentions some assumptions about usage that didn't pan out, causing problems.
IMO, Jim's comment doesn't reject tokens. Instead, he is acknowledging that the token added too much complexity to an already grand visionpic.twitter.com/NAltFWWXjQ
Takeaway: Tokenize after you figured out user behavior. MojoNation incorrectly assumed users would leave their PC connected to network all day. People critique some decentralized projects as bolting a token on to an otherwise understood product. This is an interesting reframing
The teams behind successful decentralized file sharing protocols also created the first client. Tons of people end up competing to be the best app on top of a protocol, but the protocol creators need to lead the way for others. Gnutella was a very important flash in the pan.pic.twitter.com/z5Y8wG3Uxj
Imagine tokenized BitTorrent where clients negotiate token/GB rate for a transfer • Seeding after dl can buy faster future downloads • Incentive to seed long term and contribute bandwidth • Token bounties for desirable content would incentivize sharing content people want
There is so much more that I think would follow from tokenized file sharing. I'm planning on writing "What if BitTorrent had a token?" soon 
We should split product/market fit in two when talking about decentralized protocols: • Protocol/market fit: is the protocol powerful+general enough to let apps give users a good experience? • App/consumer fit: does the app optimize how the end user wants to use the protocol?
The fat protocol layer fundamentally restricts what thin apps can provide. Multiple companies building on the app layer experiment with different product visions in parallel. Their learnings can be fed back into protocol improvements.
The split between fat protocols and thin apps starts as a weakness and becomes a strength. Until a compelling enough app is built, it is a three legged race to coordinate protocol and app changes. After this MVP is found, you see rapid experimentation and competition
If you enjoyed this thread, my blog post on the topic goes into way more depth: https://medium.com/@jbackus/fat-protocols-arent-new-42d2c538db41 …
I'll share more on p2p parallels for tokenization, decentralization, scaling, and legality in the future. Stay tuned!
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.
