For the last 15 or so years, I've been blogging occasionally on this website. Unfortunately, towards the end of last year, I lost control of my long-term domain name, nickgrossman-dot-is (intentionally not linking to it here). This was a dumb mistake; I just missed the renewal notice and someone else claimed it. Painful lesson learned.
At the time, I was bummed but figured it would just be on me to rebuild SEO to the **real** Nick Grossman blog. But, oddly, the new registrant has taken the extra step of republishing fake versions of my old content on the site, presumably in an attempt to retain SEO the old posts. Notably, all of the content has been slightly modified -- just enough, I guess, to sidestep any takedown claims based on copyright infringement.
So, what started out as an annoying and unfortunate situation has taken a turn to something more ugly: at best, an attempt to farm some referral links; in the middle, a shakedown effort; and at worst, an attempt at some kind of slow-motion identity theft.
All of this has gotten me thinking about ways in which the new decentralized media stack can help address some of these problems.
If we look at a platform like Mirror, which is a new publishing platform built on crypto rails, there are two main components: 1) Ethereum for identity and economics, and 2) Arweave for permanent data storage. Much of the attention thus far has been focused on the first prong: economics. Mirror's Ethereum bones mean that potentially unlimited forms of economics can be built into publications. For example: Emily Segal crowdfunded a Novel; Matthew Chaim is experimenting with publishing an album and a number of associated NFTs; and Jarod Dicker is experimenting with channeling economic flows through to authors and inspirations who contributed to new content. Mirror is becoming an incredible playground for the economics of content.
While the focus on economics is really exciting, there has been less focus on the implications of the identity and perma-storage aspects of the stack. Identities on Mirror are Ethereum wallets, and all of the content is archived -- in a verified and permanent way -- in the arweave network.
What that means is that, for every post, there is a blockchain-verified, permanent, immutable, record of who published what, when. Data stored in arweave cannot be changed; it can only be referenced. Every post in Mirror creates a permanent, reference-able, linkage between the identity of the author, the time of publication, and the content of the post. You'll notice that every post has a footer that looks like this:
For my use case of a hijacked domain name and republished fake content: if I had published my original blog on Mirror/arweave, there'd be a permanent record of the real/original content. For that to matter, though, "the internet" would need to learn to trust & reference the archival version of content, not modified copies.
Of course, a version of this exists today with the Internet Archive, which is an invaluable resource (and presumably, the way the new owner of my domain scraped all the old content....). While the Internet Archive is an incredible resource, it has not yet become deeply linked with other forms of publishing and identity on the web. In the case of Mirror, given the native linking between on-chain identity and content, a vibrant ecosystem is much more likely to develop around this kind of verified content.
More broadly, verified content feels like an important primitive in re-establishing trust online. Deepfakes, identity theft, social media bots, etc -- these are all affronts to our sense of reality online, and our ability to trust platforms and people. Just as the economic aspects of Mirror have been at the forefront so far, they have also been for crypto broadly.
While it's true that crypto networks introduce new forms of economics (speculation, payments, crowdfunding, etc) -- the underlying feature that enables them is trust in data. Crypto assets have value because we trust the data systems that generate them. I am excited that we are now starting to explore applying these same concepts to a broader set of online assets -- critically important ones: identity and content.
(note: this post has been cross-posted to Mirror here)
One of my favorite things about crypto is that, every so often, your conception of what it is changes.
Bitcoin at first was "weird internet money" and then it was "a protocol" and then it was "digital gold". Ethereum is "ICOs", or maybe "DeFi", or maybe "Web3", or maybe all three, or maybe something else. Crypto wallets are a place to hold money, or maybe they're also your digital identity. Crypto protocols like Maker, Compound, Helium, Arweave and Uniswap are marketplaces, or maybe APIs, or maybe inverted companies, or maybe ecosystems, or all of the above. The IRS sees crypto as property, the SEC as securities, the CFTC as commodities, FinCEN as currencies. And on and on.
Point is, we are still very early in the process of learning how to think about crypto networks, let alone what we can build with them.
One area where I think we are going to see our conception of Crypto change dramatically over time is its relationship to energy.
The narrative today is, overwhelmingly: crypto mining (specifically: Proof-of-Work mining for Bitcoin and Ethereum) is a dangerously large consumer of energy. Where I expect the narrative to move to over time is: crypto mining is driving the energy transition from fossil fuels to renewables.
To explain why, let's start with Iceland.
I'll never forget the first time I visited Iceland in 2012 with Brad and Gudjon. We were passing one of Iceland's many aluminum smelters and Brad said to me: "You see there? That's Iceland exporting its electricity".
Aluminum smelter in Iceland (source)
That was a head-scratcher for me at the time. But what he meant was: Iceland has vast amounts of accessible, inexpensive renewable energy in the form of geothermal. But you can't build power lines in every direction under the Atlantic. So instead of selling it directly, you convert the electricity into aluminum and you ship that around the world. In other words, you convert stranded renewable energy into value.
In a sense, the aluminum coming from Iceland is like a battery. What is a battery? A way of shifting both the location and the time-of-use of energy. Whereas live electricity (whether produced by coal, gas, wind or solar) must be used right then and there, electricity converted to aluminum can be used anywhere, anytime.
Dams are batteries; gasoline is a battery. And in a way, aluminum is a battery. Of course, while traditional batteries start and end with energy directly, aluminum's battery is economic, converting energy to value. And that value can be re-used elsewhere (even converted back into energy!)
Which brings us back to crypto mining. Crypto mining converts electricity into value, in the form of crypto assets (BTC, ETH, etc). Those assets, like the aluminum produced in Iceland, can then be moved, transferred and transformed. But unlike aluminum, which must be physically shipped to its final destination, crypto assets are programmable, and can move there instantly via an internet connection.
So, if we think of Bitcoin as a battery, what can we do with it? The key properties of Bitcoin's battery are: 1) always on and permissionless (no need to find customers, just plug and go) and 2) naturally seeking low-cost electricity: it will always buy when the price is right.
Given those properties, Bitcoin's battery can assist renewable builds (and electric grids more generally) in a number of ways:
Interconnection queues: when you develop new energy resources, you must apply to get them connected to the grid. Texas alone has over 100 GW of renewables in its queue. These queues can take years to clear. In the meantime, these assets could be online and earning Bitcoin.
Project finance: Renewable developers need capital to finance build-outs before they have customers. Bitcoin's battery is always ready to be the first customer.
Geographic issues: Sometimes the sunniest, windiest places are not the ones with the most customers, so it's hard to justify the development of new renewables. Bitcoin's battery solves this, becoming a "virtual transmission line" of sorts.
Timing & grid balance: Sometimes when the sun shines and when the wind blows is not when we need the most electricity. Yet, electric grids are marketplaces that must stay in perfect balance between supply and demand. Therefore, grid-connected renewables often have to "curtail" (turn off) if the are producing too much energy at the wrong time. Bitcoin's battery is ready to buy 24/7/365 when the price is right, and turning up and down as needed, and participating via direct power purchase agreements as well as via demand response programs.
Underperformance: Related to the timing & balance issues above, often times, renewables produce more energy than is needed on their grid, leading to subpar financial performance. Bitcoin's battery is ready to buy if no one else will.
Cleaning the grid: Even outside of renewable generation, Bitcoin's battery can help improve both emissions and the energy mix. For example, Crusoe Energy attaches efficient turbines and mining equipment to existing gas flaring sites, both improving emissions and converting energy into Bitcoin's battery. Taking this a step further, you could even then take those profits and reinvest them in on-grid renewables elsewhere, another twist on the idea of Bitcoin as a "virtual transmission line" (aka battery).
These are just high level ideas. There are many ways they could be implemented (power purchase agreements, feed-in tarrifs, contracts for differences, etc) -- those details are way above my pay grade.
While I am certainly an optimistic tech VC and not an expert on energy infrastructure, these are not just hand-wavy rosy ideas. Just recently the energy giant Aker announced a major Bitcoin-related initiative, Seetee. The shareholder letter where they lay out the vision is worth a read -- it's broader than the ideas I'm focusing on here, but indeed they describe Bitcoin as an "economic battery", and intend to use it to solve some of the problems I mention above, among others.
I believe the properties of Bitcoin's battery are powerful and profound, and will lead to the kinds of solutions I point to here. And as we have learned from our experience with this technology so far, that's certainly only the beginning of what will be possible.
Earlier this week, I spoke at a Justice Department / Stanford conference about antitrust issues in the tech sector. Our panel included Patricia Nakache from Trinity Ventures, Ben Thompson from Stratechery and Mark Lemley from Stanford. If you are interested you can watch the whole thing here:
https://twitter.com/trinityventures/status/1228085073435484161
The main point I tried to make was that cultivating the development of blockchain and cryptonetworks is actually a critical strategy here. Regular readers will know that I don't shut up about this, and I held to that on the panel. This point is painfully absent in most conversations about market power, competition and antitrust in the tech sector, and I will always try and insert that into the conversation.
To me, blockchains & crypto are the best "offense" when it comes to competition in the tech sector. Historically, breakthroughs in tech competition have included an offense component in addition to a defense component (note that the below only focuses on computing, not on telecom):
Credit: Placeholder / USV
The "defense" side has typically included a break up (US vs. AT&T) or some kind of forced openness. Examples of forced openness include the Hush-a-phone and Carterfone decisions which forced openness upon AT&T. Several decades later were the (ongoing) battles over Net Neutrality with the ISPs. The discussion about data portability and interoperability brings the same questions to the applications / data layer.
Data portability & interoperability are important for two reasons: 1/ because they focus on a major source of market power in the tech sector, which is control of data ("break up the data, not the companies"), and 2/ because they represent a category of regulatory interventions that are just as easy for small companies to implement as large ones, unlike heavy approaches like GDPR that are easy for big companies to implement but hard on startups.
That said, when you dig into the issue of data portability, there are some hard problems to solve. I don't believe they are insurmountable, but I also believe they haven't been resolved as of yet.
For context, data portability is the idea that a user of a tech service (e.g., Google, Facebook, Twitter, etc) should be able to easily take their data with them and move it to a competing service, if they so choose. This is similar to how you can port your phone number from one carrier to another, or how in the UK you can port your banking data from one institution to another. Both of these examples required legislative intervention, with an eye towards increasing competition. Also, most privacy regimes (e.g., GDPR in Europe and CCPA in California) have some language around data portability.
Where it gets more complicated is when you start considering what data should be portable, and whose data.
For example, within tech companies there are generally three kinds of data: 1/ user-submitted data (e.g., photos, messages that you post), 2/ observed data (e.g., search history or location history), and 3/ inferred data (inferences that the platform makes about you based on #1 and #2 -- e.g., Nick likes ice skating). Generally speaking, I believe that most type #1 and type #2 data should be portable, but most type #3 probably should not.
To add to the complication is the question of when "your" data also includes data from other people -- for example, messages someone else sent me, photos where I was tagged, contact lists, etc. This was at the heart of the Cambridge Analytica scandal, where individual users exporting their own data to a third-party app actually exposed the data of many more people, unwittingly.
I'd like to focus here on the second category of complications -- how to deal with data from other people, and privacy more generally, when thinking about portability. This is a real issue that deserves a real solution.
I don't have a full answer, but I have a few ideas, which are the following:
First, expectations matter. When you send me an email, you are trusting me (the recipient) to protect that email, and not publish it, or upload it to another app that does sketchy things with it. You don't really care (or even know) whether I read my email in Gmail or in Apple Mail, and you don't generally think about those companies' impact on your privacy expectations. Whereas, when you publish into a social web platform, you are trusting both the end recipient of your content, as well as the platform itself. As an example, if you send me messages on Snapchat, you expect that they will be private to me and will disappear after a certain amount of time. So if I "ported" those messages to some other app, where, say, they were all public and permanent, it would feel like a violation - both by me the recipient and by Snap the platform. Interoperability / portability would change that expectation, since the social platform would no longer have end-to-end control (more like email). User expectations would need to be reset, and new norms established. This would take work, and time.
Second, porting the "privacy context": Given platform expectations described above, users have a sense of what privacy context they are publishing into. A tweet, a message to a private group, a direct message, a snap message, all have different privacy contexts, managed by the platform. Could this context be "ported" too? I could imagine a "privacy manifest" that ships alongside any ported data, like this:
# privacy.json
{
"content": "e9db5cf8349b1166e96a742e198a0dd1", // hash of content
"author": "c6947e2f6fbffadce924f7edfc1b112d", // hash of author
"viewers": ["07dadd323e2bec8ee7b9bce9c8f7d732"], // hashes of recipients
"TTL": "10" // expiry time for content
}In this model, we could have a flexible set of privacy rules that could even conceivably include specific users who could and could not see certain data, and for how long. This would likely require the development of some sort of federated or shared identity standards for recognizing users across platforms & networks. Note: this is a bit how selective disclosure works with "viewing keys" in Zcash. TrustLayers also works like this.
Third, liability transfer: Assuming the two above concepts, we would likely want a liability regime where the sending/porting company is released from liability and the receiving company/app assumes liability (all, of course, based on an initial authorization from a user). This seems particularly important, and is related to the idea of expectations and norms. If data is passed from Company A to Company B at the direction of User C, Company A is only going to feel comfortable with the transfer if they know they won't be held liable for the actions of Company B. And this is only possible if Company B is held accountable for respecting the privacy context as expressed through the privacy manifest. This is somewhat similar to the concept of "data controller" and "data processor" in GDPR, but recognizing that a "handoff" at the direction of the user breaks the liability linkage.
Those are some thoughts! Difficult stuff, but I think it will be solvable ultimately. If you want more, check out Cory Doctorow's in-depth look at this topic.