As a baseline, let's do web 1.0. To set up a basic web server today, I need:
1) A public connection to the internet so I get an IP address.
2) A server computer listening on port 80 or 443 for incoming HTTP connections over TCP, returning data from a file system or database in the form of HTML/JS/CSS text documents and/or media files as requested.
3) A computer with a web browser which finds the server usually via DNS, and then requests data from the web server by passing it URLs.
Now, you can replace the browser with an API client and the server with a cloud provider and HTML with JSON and you get Web 2.0 (more or less).
Which brings us to "Web3". I honestly have no idea what the hell it's supposed to be or how it works. I've read some things that say it uses IPFS, others which are just about communicating with the Ethereum network of servers, specifically for managing NFTs.
Is there some sort of key technical solution in Web3 that I'm missing? Let's say I'm supposed to start work tomorrow on a cool new web3 app... What is it that I'll be doing exactly?
This is essentially the project I'll be doing over the holidays. I run a 3d virtual world start-up (today you'd call it a metaverse for sports - https://ayvri.com).
Most sports tracking apps view owning the user data as lock-in. I think that GPS/IGC/TCX/FIT data are a good target for decentralized and "personal" storage.
For our app, we have tons of different user types, lots of pilots who want us to build a "flight log" for them, hikers and runners don't need any of this stuff, and there are already a bunch of flight logs that exist.
So, my thinking is that I'll build what essentially to most people will look like an API to a users data. With the exception that I won't be running the only service that can access and use this API. It's open source, and available to anybody that wants to run it. Anybody who is storing their tracks using any app that uses that open and common API can use easily try out any other app.
From the developer side, the technologies are still servers and databases. From the client side, I'll probably be hosting their "wallets" until they decide they want to take them somewhere else, or if I can figure out a nice UX a non-technical user can understand.
So no, I don't think you are missing any key technical solution. Unless you are building your own blockchain, which I liken to building your own database because your app needs a database.
That's my 2 cents at the moment, but I may change my mind in the coming weeks.
1. create a MetaMask wallet and and add funds to it with your friendly neighborhood Bitcoin ATM (they do ETH too).
2. learn the Ethereum stack on eth.build and create a program in the language known as Solidity.
3. create a javascript app that talks to your Solidity contract, using the open-source javascript library web3js.
4. People with wallets installed as Chrome extensions can then navigate to your web3.js app (which can be hosted on a regular webserver), and send funds to/otherwise engage with your contract.
I can give an example of a proof of concept app I created for a hackathon -
Frontend hosting, I decided to go with a traditional hosting solution (vercel). Nothing changing here.
Backend APIs - Was able to replace the need for dedicated backend APIs by using RPCs and GraphQL queries using a project that allows for indexing smart contract event data in a GraphQL queryable format (https://thegraph.com/en/). I also created a smart contract which lives on the Ethereum chain and allows for users to achieve the interactivity that I desired for my app (which was essentially an escrow for a scheduling application). The events are indexed by the graph, so I could efficiently query this subgraph to retrieve relevant data to display on my frontend.
Authentication - Just use web3 packages to connect users wallets to the website. No need to use OAuth+OIDC or similar approaches for authentication, just connecting wallets on the frontend works.
If I wanted to take it a step further, I could have hosted my app on permaweb (https://www.arweave.org/) which will host the content in a distributed fashion with a one time charge.
For a different example, I'm creating an NFT project that uses the NFT ownership to grant access to specialized services (launching the user's NFT in a specialized application I created in an open source gaming engine). I use similar techniques as above, still hosting on vercel, but I use the innate ability to use NFTs as proof of ownership to act as an auth token into my service. This allows for me to distribute the interactive art I've created in a way that fully grants users ownership over the art, and also allows for them to access these specialized services only available to owners. Furthermore it's trivial to detect forgeries so even if someone does the horrible act of right click saving the art, they won't actually get any of the actual value from doing so. And if someone attempts to forge the token by minting an exact copy, it still will not grant access as it's easy to detect forgeries.
It's pretty exciting imo and has been a very fun project to work on. So by leveraging the similar approach for authentication (connect wallet), and NFT proof of ownership for authorization, I've been able to create a unique project with a lot less complicated of a stack tbh.
I personally think there's value in mixing centralized services (like traditional hosting of applications) with decentralized services (like using blockchains as a database of ownership, such as with NFTs).
As a baseline, let's do web 1.0. To set up a basic web server today, I need:
1) A public connection to the internet so I get an IP address.
2) A server computer listening on port 80 or 443 for incoming HTTP connections over TCP, returning data from a file system or database in the form of HTML/JS/CSS text documents and/or media files as requested.
3) A computer with a web browser which finds the server usually via DNS, and then requests data from the web server by passing it URLs.
Now, you can replace the browser with an API client and the server with a cloud provider and HTML with JSON and you get Web 2.0 (more or less).
Which brings us to "Web3". I honestly have no idea what the hell it's supposed to be or how it works. I've read some things that say it uses IPFS, others which are just about communicating with the Ethereum network of servers, specifically for managing NFTs.
Is there some sort of key technical solution in Web3 that I'm missing? Let's say I'm supposed to start work tomorrow on a cool new web3 app... What is it that I'll be doing exactly?