Open otoole-brendan opened 3 weeks ago
Planning on meeting with Josh to discuss and understand updated legal view around what we're bound by vs what we can do to improve UX
Update: this conversation has informed requirements above
Suggested by Dean (to be validated): What about having a copy of the IPFS data copied or proxied to a static page at app.inter.trade, so the user doesn’t access IPFS directly? Link to the last X versions, here is the link to verify the current one.
Other consideration: wallet connections are reset whenever there is a new dapp-inter update redeployment (better UX would be for user not to have to reconnect their wallet)
Potentially viable proposal/new process following brainstorm with Sam on 6/13/25 (To be discussed)
The above proposal could be interpreted as fulfilling the community-governed requirement in the sense that the EC is a BLD-staker elected slate that answers to the will of the community/validators and could be replaced by the BLD stakers. The community has the freedom to propose and use whatever FE they want. The DCF can build and maintain a directory of available FEs. If there is a particular preference for a certain one i.e. the DCF-hosted version - the community can propose that it is the default FE that the EC should endorse/vote in. If a 3rd party-built FE by for example P2P is preferred - the community can propose this be endorsed by the EC.
What is the Problem Being Solved?
Users that attempt to access Inter Protocol UI via app.inter.trade are redirected to an EC-endorsed IPFS hash URL. This is a long-format hashed URL that looks something like https://bafybeianlk2w4ep3rbraz7z3w5jslhj67ysm4qlkpk2oeq5gpal75tubv4.ipfs.dweb.link/#/vaults .
[issue] details how some users receive an SSL connection error when they attempt to access. This appears to be due to specific blocking done by their ISP. There are several reports of this affecting certain users with certain ISPs. Users can try contact their ISP but it's not a sure fire process and can take time to get Inter UI unblocked for them. This results in some users never accessing or losing access to the Inter app.
There have been other instances (Example) where Chrome and Brave browsers have also inhibited access by incorrectly flagging particular IPFS hashes as unsafe/dangerous/phishing. The end experience is users see a page of red and text that scares them into thinking the app is scammy and trying to phish their data. We have circumvented this by changing the IPFS hash but there is nothing preventing this from happening again. Either the browser could repeat or someone could flag it as unsafe and punish the app URL.
The fact that app.inter.trade redirects to an IPFS hash which can change also means it's not easy to bookmark since the hash can change.
Currently OpCo hosts inter.trade domain and sub-domains via it's Cloudflare account. This includes dapp-inter, dapp-psm, econ-gov.inter.trade and info.inter.trade.
Current design:
Description of the Design
Requirements
Previous conversations on this topic
Other relevant Slack conversation: https://agoricopco.slack.com/archives/C03FUCJV2J2/p1704757531600129 and https://agoricopco.slack.com/archives/C03FUCJV2J2/p1704241622443499?thread_ts=1700203252.350369&cid=C03FUCJV2J2 and https://agoricopco.slack.com/archives/C03FUCJV2J2/p1716405241742319?thread_ts=1716395184.831439&cid=C03FUCJV2J2
Custom domain was discussed as a potential solution. Initial thoughts are it looks to be a heavy lift for a light , potentially minimal benefit (Slack ref)
Security Considerations
TBC - are there new attack vectors introduced by offering multiple FEs? Hypothetically someone could create a malicious FE that users could technically access but it wouldn't be the endorsed UI