Sure; I would describe the technical requirement for something to be "web3" as:
• data storage and/or backend computation taking place in/on a decentralized / distributed-locus-of-control system,
• where these systems are exposed directly to browsers via regular-web HTTP gateways,
• and where there are well-defined general APIs (these being the "web3" APIs) such that these gateways are interchangeable in the access they provide;
• where a web app can choose to have a relationship (e.g. a paying customer relationship) with their own gateway provider, rather than having one forced upon them;
• and where the user-agent can further enable the user to have their own relationship with different gateway provider, overriding the website's choice of gateway, in a way invisible to the web app. (Just like how UA stylesheets override site stylesheets, in ways invisible to the web app.)
The gateways are a necessary part of the definition, because HTTP is fundamentally a protocol for talking to specific servers, so Web -three, then, is 90% about the particular way in which we hitch decentralized stuff up to that centralized model.
The fact that the website and the user get choice in their gateway, is what makes this a decentralized system, rather than being something like X.509 that's nominally decentralized (anyone can be their own CA root authority for their own DAG-of-trust) but where in practice there's only one public DAG-of-trust forced on everyone by a consortium of browser and OS manufacturers.
Before I answer: why are you asking this in response to the definition of a piece of technical jargon? What makes something "web3", and whether anyone should care about "web3", are separate questions.
Nevertheless, the answer is: because web standards don't allow browsers and other only-speaks-HTTP clients, to interact with regular peer-to-peer protocols, preventing them from participating in [the existing networks serving] peer-to-peer use-cases. You can't write a blockchain node as Javascript that executes in a browser and have it talk to the same network peers that other native nodes for that chain interact with.
Instead, if users want to participate in such use-cases (e.g. to download a torrent on a Chromebook), they must use technologies like WebTorrent, that stand up their own, incompatible p2p networks based on WebRTC and other web-specific carrier protocols. This creates isolated "web p2p" networks (e.g. the WebTorrent swarm) divorced from their regular-p2p equivalents (e.g. the BitTorrent swarm.)
Web3 is one way of avoiding this network split: it is a [nascent] set of standard APIs, allowing browsers and other only-speaks-HTTP clients to interact with p2p protocols by holding relationships with "p2p protocol 'light client' over HTTP" gateways, that expose the p2p protocols in standard useful-over-HTTP manners to browsers.
Another way of avoiding such a network split, instead of web3, would be creating lower-level gateways that allow browsers and other only-speaks-HTTP clients to directly tunnel p2p wire protocols over HTTP, where the gateway would terminate the HTTP tunnel and then route the p2p packets to peers as normal.
However, most p2p protocols are a really bad fit for having all communications linearized into a TCP stream. Peers connected through such gateways would be really badly-behaved peers from the perspective of the network.
Web3 "solves" this by not having the browser speak the p2p protocol itself, but instead having the gateway speak the p2p protocol and act as the finite-state-machine keeping the p2p state, while the browser just gets to interact with the state model that the gateway node builds up through its p2p interactions, via either RPC request-response flows, or event streaming flows, both of which are much better behaved over an HTTP carrier than p2p traffic generally is.
Seems to me that Web3 is focused on Etherium, which is definitely a specific kind of 'P2P' if you want to use that term.
That 'broad generalized use-case' you articulated isn't really a 'use case'. It's not really a problem that needs solving.
And of course a browser plugin solves can get around those problems.
The issue is that this entire stack of technology doesn't do anything that people really need or want. Etherium is popular among Etherium enthusiasts and a few speculators for interests sake, not for for the sake of any actual 'use cases'.
Most substrate technologies are not, on their own, "problems that need solving." What real-world problem does TCP solve? WebRTC? ICMP? Nothing, without application-layer protocols on top of them.
These low-level protocols are essentially frameworks for building solutions, solutions that take a standard shape specified by the low-level protocol, and thus allow for standardization in libraries and tooling.
Web3 is a substrate standard, a specification for how browsers should frame RPC and event-streaming requests to "p2p 'light client' HTTP gateways". It's not an application-layer protocol.
Ethereum's RPC protocol is an example of a Web3 protocol, just e.g. SMTP is an example of a TCP protocol.
Web3 is a nascent concept, in that it doesn't really have other things built on top of it yet. Its implementation is a de-facto outgrowth of what people did when building the Ethereum protocol. But the concept of "a Web3 protocol" isn't definitionally tied in any way to the Ethereum RPC protocol, any more than TCP is tied to whichever application-layer protocols it co-evolved with. (TELNET was a major one, I believe.)
Web3 can be a useful framework even if the only thing people have built on it so far (Ethereum) isn't useful. (I won't claim one way or the other whether Ethereum is useful; I'm just pointing out that believing one way or the other about Ethereum being useful is irrelevant to whether Web3 as a low-level protocol is a useful tool for building protocols.)
> And of course a browser plugin solves can get around those problems.
Browser plugins do not practically exist any more. The era where you could ship an experience requiring users to install a plugin like Flash, and actually get adoption, is gone. Now a majority of browser installations in the world are inviolate apps running on a phone or tablet or Chromebook (or desktop PC with an App Store and code signing), where the device doesn't allow the user to embed other native code to run in the context of the browser. Only weak extension APIs are supported, and these intentionally do not expose features like speaking arbitrary L4/5 wire protocols.
The problems browsers have, can now really only be solved either by browser manufacturers themselves (as in e.g. the browser U2F API), or by operating entirely "above" the browser by using HTTP to communicate with gateways that do what the browser cannot.
1. consensus networks,
2. data storage networks,
3. messaging networks.
(1) includes Ethereum and other blockchain and distributed ledger tech.
(2) includes IPFS, FileCoin, GUN, etc.
If you're storing data on the blockchain apart from the bits needed in relation to consensus ops, you're probably doing it wrong.
(3) includes Waku (Status), Matrix ... depends a bit on whether you think this category should only include p2p networks or federated networks of servers qualify.
There are many other projects that could be listed for those categories, those are just off the top of my head.
If it's just when the database is decentralized, why even call it web3? Why should web standards even care about implementation details of the database?
We didn't move to "web3" when db sharding became a big thing, or when NoSQL caught on.
Email and Mastodon are existing decentralized social networks. If you want to call something Web3, it's going to need to be more than just "decentralized".
technically they are federated, not decentralized. Gmail is a centralized, federated node. Think like a federation of states where each state is its own centralized, independent unit.
the newer definition of "decentralization" is more akin to anarchy. Collectivism vs individualism.
Email is not "technically federated". It's de facto federated. You can run your own email server on your home computer.
Anything less centralized than email isn't going to be "Web3" because it's not going to be a web at all. For the purposes of the internet, there is no functional difference between federated and decentralized. Two strangers must have a way of contacting each other -- something like an IP address at a minimum. That's a centralization point right there.
In the case of the web, DNS is going to be the main way that things are centralized.
Blockchain is similarly federated -- it just has a way to make sure that each node has a mutually agreed upon state. That doesn't make it decentralized, it just makes it redundant and distributed.
Isn't that just the late 90s internet? Make your geocities page with your info, link to whoever else's pages you want, use email or chat to communicate with them. HTTP, SMTP, IRC...
even more broad, i think web3 is just where the database is decentralized. blockchain is one solution.