5 ms·

This gives you a good overview of what web3 is https://moxie.org/2022/01/07/web3-first-impressions.html https://moxie.org/2022/01/07/web3-first-impressions.html

moffkalast 4y ago
Guy decides to build a couple of dApps... and immediately makes a pyramid scheme. I just can't, hahahah
janalsncm 4y ago
Seems like “web3” has completely missed the mark and is actually highly centralized, arguably more so than web2. If I had to guess, it’s because expediency requires it. If you’re in the middle of a gold rush, first principles like decentralization are quickly supplanted by principles like “line goes up”.
- sshine 4y ago
  > Seems like “web3” has completely missed the mark and is actually highly centralized, arguably more so than web2. In the sense that the “web3” brand is mostly used to make proof-of-concept and crypto startups in the Ethereum ecosystem, which is just one ecosystem, and a highly centralised one at that, 100%. Creating a decentralised web is extremely difficult. Most Ethereum web3 projects are more like concept art within a research project.
  - TedDoesntTalk 4y ago
    > Creating a decentralised web is extremely difficult We’ve had it for years: tor’s .onion sites. And look how popular they are… when was the last time you visited one? Technically, You could say Web2 sites are decentralized, by the way: most include JS, CSS, and images from different domains and servers.
    - q-big 4y ago
      > We’ve had it for years: tor’s .onion sites. And look how popular they are… when was the last time you visited one? Don't ask this kind of rhetorical question on HN - HN is exactly where you can find a lot of audience that can honestly answer this question with "today" or "yesterday". :-D
    - shakna 4y ago
      > We’ve had it for years: tor’s .onion sites. And look how popular they are… when was the last time you visited one? Pornhub's onion site is probably somewhere more regular than I'd like to admit.
      - BlueTemplar 4y ago
        I thought that it was frowned upon to use tor for high bandwidth uses like video ?
jrochkind1 4y ago
> What surprised me about the standards was that there’s no hash commitment for the data located at the URL. Me too. I'm an outsider, but can anyone understand why they didn't do this? If you were designing NFT's, wouldn't this be an obvious thing to do?
- zeroclip 4y ago
  ERC721 is an EVM spec, how do you even propose achieving this kind of restriction in Solidity? tokenURI aims to be flexible and unopinionated. It can be an inline SVG string generated by the Solidity contract itself, an IPFS link to a JPG, some app's custom protocol URI scheme, or a mutable HTTPS CDN like a game developer using NFTs but wanting to retain control over their assets.
  - derefr 4y ago
    Yes, and all-but-two of those ideas are awful, because the server or IPFS-pinning node backing the asset file is gone off the face of the Internet six months later, so now you've got an NFT that looks like nothing. (My company, among other things, spiders + scrapes + archives NFT assets. I know what I'm talking about here.) ETC721 should have been limited to exactly two use-cases: 1. embedded data: URNs 2. URNs for data on distributed content networks that make permanency a guarantee for posting (e.g. Arweave); where an oracle-check that the data is in the network at the time of creation from at least one client's perspective is required as collateral to successfully mint the asset. As it is, I'd settle for even IPFS-without-guarantee-of-pinning, as long as you can guarantee that at least one node accessible to the public web has the data at the time of mint. That'd at least mean that someone who does care could come along, scrape the asset, and then pin it themselves to ensure the URN never goes bad from then on. Even this, though, is far more thought than people put into earlier standards, e.g. the Solidity compiler's deployment metadata, which is always nominally an IPFS URN, but is never actually populated by the generated metadata. If they had just stood up a backend at ReMix.org that pinned these metadata files, and had solc push compiled metadata to said backend, then we wouldn't be where we are now with the (centralized) Etherscan "verified contract source code" being the only way to see/decode the storage layouts for (even some) contracts.

moffkalast 4y ago

Guy decides to build a couple of dApps... and immediately makes a pyramid scheme. I just can't, hahahah

janalsncm 4y ago

Seems like “web3” has completely missed the mark and is actually highly centralized, arguably more so than web2. If I had to guess, it’s because expediency requires it. If you’re in the middle of a gold rush, first principles like decentralization are quickly supplanted by principles like “line goes up”.

sshine 4y ago
> Seems like “web3” has completely missed the mark and is actually highly centralized, arguably more so than web2. In the sense that the “web3” brand is mostly used to make proof-of-concept and crypto startups in the Ethereum ecosystem, which is just one ecosystem, and a highly centralised one at that, 100%. Creating a decentralised web is extremely difficult. Most Ethereum web3 projects are more like concept art within a research project.
- TedDoesntTalk 4y ago
  > Creating a decentralised web is extremely difficult We’ve had it for years: tor’s .onion sites. And look how popular they are… when was the last time you visited one? Technically, You could say Web2 sites are decentralized, by the way: most include JS, CSS, and images from different domains and servers.
  - q-big 4y ago
    > We’ve had it for years: tor’s .onion sites. And look how popular they are… when was the last time you visited one? Don't ask this kind of rhetorical question on HN - HN is exactly where you can find a lot of audience that can honestly answer this question with "today" or "yesterday". :-D
  - shakna 4y ago
    > We’ve had it for years: tor’s .onion sites. And look how popular they are… when was the last time you visited one? Pornhub's onion site is probably somewhere more regular than I'd like to admit.
    - BlueTemplar 4y ago
      I thought that it was frowned upon to use tor for high bandwidth uses like video ?

jrochkind1 4y ago

> What surprised me about the standards was that there’s no hash commitment for the data located at the URL. Me too. I'm an outsider, but can anyone understand why they didn't do this? If you were designing NFT's, wouldn't this be an obvious thing to do?

zeroclip 4y ago
ERC721 is an EVM spec, how do you even propose achieving this kind of restriction in Solidity? tokenURI aims to be flexible and unopinionated. It can be an inline SVG string generated by the Solidity contract itself, an IPFS link to a JPG, some app's custom protocol URI scheme, or a mutable HTTPS CDN like a game developer using NFTs but wanting to retain control over their assets.
- derefr 4y ago
  Yes, and all-but-two of those ideas are awful, because the server or IPFS-pinning node backing the asset file is gone off the face of the Internet six months later, so now you've got an NFT that looks like nothing. (My company, among other things, spiders + scrapes + archives NFT assets. I know what I'm talking about here.) ETC721 should have been limited to exactly two use-cases: 1. embedded data: URNs 2. URNs for data on distributed content networks that make permanency a guarantee for posting (e.g. Arweave); where an oracle-check that the data is in the network at the time of creation from at least one client's perspective is required as collateral to successfully mint the asset. As it is, I'd settle for even IPFS-without-guarantee-of-pinning, as long as you can guarantee that at least one node accessible to the public web has the data at the time of mint. That'd at least mean that someone who does care could come along, scrape the asset, and then pin it themselves to ensure the URN never goes bad from then on. Even this, though, is far more thought than people put into earlier standards, e.g. the Solidity compiler's deployment metadata, which is always nominally an IPFS URN, but is never actually populated by the generated metadata. If they had just stood up a backend at ReMix.org that pinned these metadata files, and had solc push compiled metadata to said backend, then we wouldn't be where we are now with the (centralized) Etherscan "verified contract source code" being the only way to see/decode the storage layouts for (even some) contracts.