Inter Protocol Dapp UX via IPFS is unreliable, inconsistent and regularly flagged by ISPs and/or browsers as dangerous/unsafe

[otoole-brendan]

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:

1. DCF hosts dapp-inter repo (a copy of OpCo dapp-inter)
2. DCF runs workflow to publish dapp-inter updates to IPFS which generates a new UI hash + gateway
3. DCF recommends this new hash to the EC
4. EC endorses it by voting it in
5. app.inter.trade is a jumper page that redirects users to the endorsed IPFS UI hash

Description of the Design

Requirements

• As DCF/Inter Protocol, I must demonstrate that the dapp UI is decentralized by nature of the fact that there is a community/BLD staker element to its governance. There needs to be a clear way for the community to exert some control over what dapp UI is available/served to users.
• As an Inter Protocol dapp UI user, I need the endorsed Inter UI URL to just consistently work and for my access to not be hampered by my choice of ISP or browser
• As the community, I need the EC to be able to endorse a default UI URL that users will be automatically redirected to when they navigate to app.inter.trade
• As DCF, in an effort to both resist censorship and provide a service to the community, I need to create and maintain a list of available dapp UIs so the community can choose whichever they want. I should probably link out to this in appropriate places.
• As an Inter Protocol user, I'd like to not have to reconnect my wallet after each new dapp UI update/deployment

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

[otoole-brendan]

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

[otoole-brendan]

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.

[otoole-brendan]

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)

[otoole-brendan]

Potentially viable proposal/new process following brainstorm with Sam on 6/13/25 (To be discussed)

1. DCF (or anybody who wants to) forks a version of Agoric’s dapp-inter repo (current process)
2. DCF then hosts a version of the app on either OpCo's CF account or set up their own CF account. Domain could be app.inter.trade/dcf or dcf.app.inter.trade
3. The DCF would recommend the dapp UI URL be endorsed by the EC as the new default dapp UI i.e. dcf.app.inter.trade
4. Users who navigate to app.inter.trade get redirected to the EC endorsed URL dcf.app.inter.trade.
5. Users can also view a directory/list of other community-hosted dapp UIs should they wish to use a different one. For example we could still provide the IPFS-hosted version as some users may prefer that (this was suggested by the EC).
6. A new default dapp UI (via EC endorsement/voting) can be requested at any time by community request

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.