The network/protocol is decentralized but we have to go through an aave.com interface, what happens if the site is down for x or y reason? We can certainly use smart contract but who is able to do it without interface / frontend?
We can use zapper, instadapp, defisaver and others but we depend on their smart contract and protocol too.
Why not set up a public frontend? Which can be different from aave.com (lighter version) but which allows to interact with everything that is possible to do today on aave.com and on smartcontract?
Moreover if the frontend is public and decentralized, it is possible to add the latest features that are available on the protocol more quickly.
Other advantages : We will have the possibility to create mirrors
Risk : Possibility that someone change the addresses of the smart contract in the frontend if they decide to fork it and make a fake.
In any case I want to open the discussion on this eventuality and take the measure.
Moreover an Aave app seems to be in dev, is it public ? decentralized ? where is the border ?
If the protocol is decentralized, the interface must be too, otherwise we are dependent (for a large part of the users) on the goodwill of the person responsible for the publication of the frontend.
Of course all the frontend work is fabulous, but so far we are waiting for the new releases with impatience and we have no choice on the frontend, the date, etc …
Best Regards,
Kwizfreak
For a decentralized Aave frontend soon
No decentralized Aave frontend at least for the moment
Good suggestion by @kwizfreak and also by @haave to join the OpenFrontEnds Initiative.
It seems they are going to begin with Compound so we could always keep an eye on things, see how things pan out and perhaps follow in their footsteps without experiencing some of the teething problems.
Before jumping into building a new front-end piece (as the OpenFrontends people seem to be doing for Compound), I’d try to push first for publishing the existing Aave interface under a libre software license (ideally, AGPL).
In the announcement on Medium there are a number of good reasons why open sourcing the UI is important:
Facilitating integrations
Possibiliting alternative and enhanced user experiences
Enabling anyone to contribute and improve the UI
However, I think there are a couple of reasons more that can’t be overlooked:
The front-end code of dApps need to be publicly auditable so that anyone can verify the security and integrity of the code. That is, making sure that the front-end is free from privacy-endangering or money-endangering code and that it doesn’t contain some evil logic (e.g. secretly interacting with a different implementation of the the protocol that is not the one that has been audited and published).
Users who want to have a truly end-to-end trustless experience need to have some way to locally run the UI from the source code. Only in that way they know the dApp they are using is exactly the code that is publlished on GitHub. Moreover, that’s also the best way for them to protect their privacy, as the version of the UI that is live on app.aave.com is leaking IP addresses and potentially many other data to a number of web servers, including some third parties:
I’m not sure if Aave’s front end has been officially deployed via IPFS yet, but that’s fine, we can do the same and we’ll publish the CID for verification purposes.
Hi @kwizfreak
Is there any concern that this could be used for phising or similar attacks
Users could go to what they think is a front-end for Aave but is really a scam
Or am I missing something?
That’s something that a motivated enough attacker can easily do even without access to the source code, so this doesn’t make much of a difference to that sense