What are practical benefits of full Web3?

Developers
1

Hey folks,

TLDR:

  • How does your app benefit from being fully on-chain / Web3?
  • What business or growth opportunities would be lost if you implemented the front end using AWS?

LONG VERSION

I was thinking a lot recently about Web3 vs. Web 2.5 dilemma. In theory, the full-on-chain Web3 design is a better long-term strategy because of censorship resistance and full community control over the app’s code.

However, even if we know the future, how we can get there is not always clear.

What are the practical benefits of full-stack on-chain apps?

Some potential directions:

  • User base. Does it allow to serve new categories of users who wouldn’t use Web2.5?
  • Capital access. Does it unlock access to new types of capital (like some VCs invest only in end-2-end Web3)?
  • Security considerations. There’s a real threat that AWS will mess with the app’s code and data. Therefore, the app must be on-chain.
  • Censorship resistance. AWS will likely censor the app, similar to [Parler].
  • Transition to full DAO. The app is moving under the control of DAO, and moving it on-chain prevents the developer from deploying frontend updates without DAO proposal votes.

Again, I’m looking for strong practical considerations like “As a developer, I have no choice except to go fully on-chain because Web2.5 won’t work for my use case.”

I fear that without concrete benefits of full Web3, it’s more practical for most developers to build Web2.5 apps and think about transitioning to Web3 in the future when they prove product market fit. If true, this will significantly slow the adoption of full Web3 platforms like Internet Computer.

Looking forward to the discussion.

7 Likes
2

Is your question specific to Front End? I mean it should only take a day to host it in amazon vs ICP. So why not have it on chain for the same amount of work?

3

The points you’ve highlighted, such as the smooth transition for users with Internet Computer Protocol (ICP) and the subsequent facilitation of app adoption, are indeed important. The community aspect also contributes significantly, as individuals often identify with the distinct culture established by the foundation or protocol. However, it seems that the significance of security and ownership may have been overlooked.

The concept of ownership of a currency, as introduced by Satoshi Nakamoto, the pseudonymous creator(s) of Bitcoin, was revolutionary. It changed the way we perceive and manage money. Before Bitcoin, the ownership of money was primarily tied to centralized systems and records.

Bitcoin, and its underlying blockchain technology, drastically deviated from these traditional notions of currency ownership. For the first time, ownership wasn’t tied to a physical object or an individual’s identity. Instead, it was linked to a unique piece of digital information - a cryptographic key. This key, typically a long sequence of numbers and letters, serves as both a proof of claim on a certain amount of digital currency, in this case, Bitcoin, and a means to transfer the ownership of that currency.

Bitcoin’s unique feature allows one to prove ownership and transfer ownership via cryptographic keys. This eliminates the need for centralized bodies like banks or governments to verify transactions and ownership. In Satoshi’s vision, anyone in possession of a private key to a Bitcoin address essentially owns the Bitcoin linked to that address.

The key concept here is: those who control the keys, control the assets. In the context of data and applications, these are the assets. ICP extends this idea; the assets become the canisters that store data and logic. In today’s world, your data is invaluable. Your attention is valuable, and the data used to capture your attention is valuable. If one can control the attention of humans, it can influence their behavior to act in ways that have significant real-world implications.

What attracted me to ICP primarily was the distribution of asset ownership. This feature enhances security and immortalizes the app, as it becomes an integral part of the protocol and the community.

1 Like
4

As someone that has been in the ecosystem and learned a great deal, just do it. The longer you mess around building sand castles the longer it will take you to really understand how IC works. This is coming from someone that understands the ins and outs of web 2 stack.

5

Thanks for sharing. I agree, in theory, that on-chain is better. However, I was curious about some practical considerations.

There are challenges to moving completely on-chain for user-facing performance-sensitive apps:

  • Slower speed for update calls than vanilla AWS
  • Limitations of building truly real-time apps, like games (the IC team has options on how to solve it in the future)
  • Less familiar toolchain
  • Less familiar scalability best practices
  • More end-user friction on the identity side

That’s why I’m curious what are the practical benefits that the community developers see of moving fully on-chain. Thanks!

1 Like
6

I would like to learn more about this point. How do security and ownership translate to business-level metrics of the developer? Do they open new capital financing options? Do they enable new categories of consumers to adopt the product?

7

Yes, but this currently is a “niche” group of very early fully on-chain web3 adopters (less than several million worldwide?). The majority of crypto app users are in web 2.1-2.2 (app fully off chain, tiny piece on-chain).

Some VCs, yes. Others will invest in the product, as long as the important piece is on-chain (also prefer cross/multi-chain compatibility)

I’ve heard this from people a lot, but other than censorship due to violating AWS terms of service, is there any precedent of AWS actually “messing” with a customer’s code or data?

Compare this with the IC’s boundary nodes, which regularly block canister applications (geoblock in a jurisdiction, or that violate DFINITY’s own terms).

This is the most compelling reason to have a full dapp, or parts of that app on-chain.

Having a developer/team controlled app on the IC is as centralized as web2, with the novelty being that the app is hosted on a blockchain, but a less compelling functional reason for having it hosted there.

1 Like
8

Update calls are slower but don’t notice if you update the state on the client as well. It is instant.

Real time apps is an issue and developing great games is a huge challenge. Look how Stadia failed and most game companies fail. Gaming is hard not just tech wise.

Less familiar is always the case and is why we learn.

Yeah friction on identity is an issue but I see some apps using google login as an option. After the first setup it is really easy and I prefer it. Specially with fingerprint and face id, it is much better.

The practical benefits is that users own the app. I don’t own twitter or facebook maybe after VC’s ate all the pizza and there is one slice left. DApps is an extension of open source software but sustainable.

The limit is your imagination. What kind of apps are you most excited about that you would like to see. Product is everything.

But also note it won’t be easy. So maybe testing product first is best but if product fails you will still be delaying learning the tech and it is progressing quickly. I can’t even keep up at times.

9

:white_check_mark: Assuming you meant for frontend devs, I have solved that with Juno.

1 Like
10

Looks very interesting. Thanks for sharing.
So essentially Juno is a Firebase clone with ICP backend?

11

I would avoid using the term “clone” as it sounds reductive, but essentially, yes, it can be seen as a small open-source alternative to Firebase on the IC.

12

I don’t think Amazon has any incentive to mess with anyone’s web app. But someone working for Amazon may. Or someone who is able to get access to your AWS instance. Or whoever manages the AWS instance. And so on.

Are you saying that AWS will let you serve a gambling site to e.g. Switzerland (or Nazi propaganda in Germany; or a bunch of other content that is illegal in some jurisdictions) and will do nothing about it if the authorities complain and you do nothing about it?

This is precisely why the boundary nodes will block some content in some jurisdictions: the data center/ISP/whoever got a takedown notice from the authorities; and if DFINITY (in this case) does nothing about it; the data center/ISP/whatever will simply block all access to boundary nodes

The main benefit AFAICT is that you get certified, authentic responses directly from a blockchain. You don’t need to trust anyone or anything, as long as you trust the protocol. With Infura or some other API (or random web app) you need to trust the provider of said API. There is not much stopping them from serving you arbitrary data. At which point, why even bother having your backend run on a blockchain?

You may as well go with AWS. As said, I strongly believe that Amazon themselves have zero incentive to mess with your app. It’s everyone else you need to worry about. Which is exactly what you need to be worried about with Infura or other APIs too.

1 Like
13

I didn’t say AWS would do that - I just made the policy comparison. In terms of censorship via the boundary nodes the IC (currently just DFINITY) the policy/reality is quite similar to AWS, for better or for worse.

Does this matter if the app itself or canister holding the data is centralized (not controlled by a DAO)?

14

I think badlands is a way into full decentralization since it will allow a wide array of boundary node participants. But AWS isn’t even trying, I would rather be part of a network that is maybe not there yet but will be in a couple of years since we are walking toward decentralization. Also I just love working in ICP. It has been so much fun, challenging at times but rewarding. I haven’t tried Juno but it seems great.

15

My apologies in that case, I misread your comment.

Somewhat, but not as much. Depends a lot on who has the incentive to tamper with the data. Directly interacting with a blockchain makes it very hard for everyone but the party managing the dapp to do so. E.g. OpenChat would not have much of an incentive, even if it wasn’t a DAO.

16

my 2 cents: when the IC nodes will be random ‘compute cubes’ powered by solar/heat energy, thrown around in the mountains, valleys, rooftops, unexpected locations throughout the world in cities and provinces. Connected through a mesh (like Helium tries to) with no ISPs involved. Then it’ll be really worth it to spawn some software into the ‘real independent cloud’ of a mesh of these machines spread throughout the world. Until then it’ll always be same old candy with a different color coating (centralized and under control of lawmakers/datacenters/companies). BTC/ETH/Monero miners, all these ASICS, are the closest thing to mystery boxes that are spread throughout the world in random locations very hard to take over and to control or censor. I really like the idea of independent ‘compute cubes’ that power themselves from wind/water/solar/heat somehow and keep running as long as hardware can (possibly built more durable than home or datacenter hardware). This will be a really good infrastructure, when it needs no power grid or ISP connection. But such mesh can only be built voluntarily, a node should produce 0 income for ‘owner’, otherwise people will steal them from all the ‘open air’ locations, so hosting the boxes will only happen in cities, not outside, which means mesh and connectivity will be gone outside of cities.

17

what’s your favorite aspect of developing on ICP btw?

18
1 Like
19

Canisters and Motoko

20

An Amazon employee messing with customer code/data is no different from an anonymous hacker doing the same. It is definitely not Amazon deciding that it’s more profitable for them to steal from customers.

And it is more or less equivalent to me (a DFINITY employee with privileged access to the IC) hacking into the ckBTC canister. Except I would have a much harder time doing so, even though I have (emergency) ssh access to DFINITY owned nodes. Which is exactly what I was arguing above.