jacogr
commented
1 year ago In a previous life (while building the Ethereum Parity wallet), I used stuff like the etherscan.io APIs quite extensively - well, that is not 6-odd years ago.
The whole idea behind polkadot-js is to not have 3rd party dependencies. Having said that... if...
- we don't tie ourselves to a single provider (I don't want to pick sides, I think there are a lot of teams doing great stuff - and happy to help out to grow the ecosystem)
- it is selectable on a per-user basis (and disabled by default, at least on the "within our control deployments")
... then I actually think it would be a great augmentation. (Without moving away from the "it only need an RPC node to function" mantra)
I have no idea what it looks like. So I guess if we start at the start and build some plugin around accounts + extrinsics + ... we can see where it leads us. Quite happy to have it in an augment the user experience. If we have something, we may as well start pinging others to see if we can at least add another source (happy to help there) for at least 1 other provider. (Just to ensure we haven't missed much)
Let's be honest - the UI needs a lot of help and work. At best I'm doing part-time work on it - and then in the areas where I see benefit, i.e. for me to use the chains. It is not a simple experience UX-wise, I'm aware of that. (And certainly don't have the (a) time, (b) energy or (c) pizaz to make it grandma friendly. So it is "just dev functional" since that is where I operate.)
Back to topic at-hand -
(a) I think it is worth exploring at least with making a start (b) Happy for help (c) No bright ideas what it looks like, I think doing will guide a lot here to spot (some/massive) gaps
sourabhniyogi
polkadot-js-bot
TLDR Version:
We would like to know how we should do polkadot.js PR (or fork) to: (A) Replace the polkaholic.io UI with polkadot.js apps UI, but augment it with Polkaholic APIs (more generally Third Party APIs) (B) Develop a polkadot.js "plug in" architecture This "Feature Request" is hyper meta, so if there is a better way to communicate, kindly suggest a path!
TL Version:
Background:
In 2022, we (Colorful Notion, building polkaholic.io) successfully learned how to use polkadot.js API to index a lot of chains into GCP BigTable/BigQuery/Mysql - we drilled into EVM/WASM/XCM and various DEX and data aggregation problems that you can't easily do without some archival backend of note. We developed Polkaholic APIs to pull out indexed data from GCP storage and show data polkaholic.io UI in tables+tabs. But the infinite possibilities of pallets means no one superengineer can possibly cover all the UI + indexing well enough or fast enough at the speed at which 100 parachain teams can operate -- we always feel behind! With runtime metadata, it almost seems possible, but a healthier "third party APIs and plugins" model is how to cover for this inadequacy and scale beyond a small team of superengineers. We see it in Slack/Nagios/Appforce/yarn/Windows/iOS Appstore/Facebook/etc. -- can this exist in polkadot.js apps?
Of course, it already does: The present approach polkadot.js apps takes is to set up links to other block explorers via a key (block hash, SS58 address, ...), which we use -- sometimes third party block explorers do something deeper, but then block explorers are always missing some aspect that polkadot.js apps does really well. So then what happens for the UX experience when hopping between the polkadot.js app and the third-party block explorer is discombobulated -- you see this set of information here, that set of information there. Our 2022 conclusion is .. rather than try to redundantly replicate all the awesome polkadot.js apps functionality in the polkaholic.io UI (and create a pointless learning curve for users), we simply:
(A) Replace the polkaholic.io UI with polkadot.js apps UI, but augment it with Polkaholic APIs (more generally Third Party APIs)
Concretely what we have in mind is:
We imagine other teams may have a set of "third party Decoration API" similar needs in Staking, Governance, or wish to do a more thorough job with Crowdloans, Rewards, etc. so the architectural question might be how to structure decoration with third party API either exactly one or exactly one of some "standard" section of polkadot.js apps page/package. Otherwise, the general flow would be the usual { fetch data using Axios or something, send to React component after loading }.
Users of polkadot.js.org/apps would need to configure their "chosen" API sources, accept cookies/privacy policies, with cross-domain issues. Non-polkadot.js.org domains (eg polkaholic.io) hosting polkadot.js/apps would have their API set pre-chosen and would consider e.g api.subsquare.com as its third-party. The end UX would be a lot more seamless. The issue is how to eliminate the Pandora's box of Third Party APIs looking inside local storage to get at private key info (leaving extensions to 100% of the work); I would like to cleanly eliminate it by not having it at all so:
Question (A): How we should go about adding Third Party API calls in polkadot.js apps?
I'm hoping for an answer like this: Use X abstraction to do the Third-party API call like this: {...}. Then, be sure to reuse these components {...} and not {...}. The ideal model of how others added new components is in these PRs: {...}. The Pandora's box threat in Third-party API calls can most cleanly addressed by {...}.
Assuming we eliminate Pandora's box, the request for Third Party additions to polkadot.js is not limited to indexer decorations and can be extended to cover all the mostly redundant efforts all the parachains dapps are doing on "XCM Transfer" and "DEX" ("swap", "add/remove liquidity", "lend/borrow" UI) where dozens of teams end up with pretty similar interfaces. So we would like your advice of how to:
(B) Develop a "plug in" architecture
Specifically, we wish to develop this architecture for 2 special plugins to polkadot.js:
We're envisioning an open architecture where every parachain and dapp developer could submit, via the dAppStore plugin, not a "DEX" app but their own "NFT", "IoT", "Privacy Shield", "Polkadot Tax Prep", etc. app. This would be on par with the iOS Appstore/Google Play market, except without Apple/Google earning their 30% and having gatekeeping powers. As a first simple cut, we would propose to make polkadot.js apps menu bar analogous to the mobile home screen. The generic idea is to take the way which polkadot.js uses chains features (Assets, Contracts, ...) and extend it to users action "install"/"uninstall" polkadot.js apps where the user-dApp connection could be stored locally, managed by third-party APIs, stored on-chain for the "dAppStore" in full view, or something ZK that can count installs without revealing who installed what when.
Both the "DEX" and "dAppStore" dapp could, like "Accounts", be considered privileged or not, similar to your mobile "Phone", and "iTunesConnect" mobile app. For "DEX", having just one "DEX" app eliminates all the redundant UI/Data engineering that is happening with parachains. But dapp developers should be able to submit their own DEX dapps as well, where users could have their richer DEX dApp that looks more like Coinbase than the Uniswap UI built by parachain.
Similarly, if "dAppStore" is missing say privacy features (for when DEXes to Ovulation Trackers and Truth Social that right-wing and left-wing should not see who "installs") or in-dapps subscriptions (e.g subscribe to "Polkadot Tax Prep" in-dapp subscriptions for 1 DOT/mo) then "zkdappStore" and "Subscriptions" can fill this role.
With this wide open polkadot.js dapp plugin model we lose the line of defense of "did you check what domain you were on?" -- in the 2022 Web3 model users basically "trust" parallel.fi and stellaswap.com "dapps" (which if we are honest, are just centralized web sites that people trust like good old ftx.com). What we need instead is PSP-XX, which is polkadot.js's equivalent of EIP-712 + EIP-4430: (1) polkadot.js app developers MUST declare their apps write permissioning using the dAppsStaking pallet's "registerPermissions", submitted via the "dAppStore" dapp; (2) when dapp plugins actually sign, they MUST include EIP-712/4430 metadata and use polkadot.js abstraction D, which is modelled after OAuth or {...} (3) the Substrate wallet MUST show users what they are signing in human readable form but also further verifies that the apps registered write permissions of (1) checks out against the EIP-712/4430 metadata of (2)
Question (B): How we should go about developing a polkadot.js app plugin model?
The transformation we seek is that dapp development moves from trusted domains to the above user-dapp-developer protocol and the wallet. In particular, 2022's AppStore Epic/Musk/Zuckerberg vs Apple reviewer drama evaporates. With any significant success there would be a technical problem of loading app plugins on demand instead of bloating polkadot.js, otherwise you would have a collective of set of reviewers making "Aye" vs "Nay" decisions and opening up to the same sort of seemingly random censorship decisions as Apple/Google/Facebook/Twitter/... at the app level. The Web3 ecosystem doesn't have a mature "read permissions" on user storage from NuCypher type entities (akin to mobile "yes, allow this app to access my email/address book/location/camera/photos") -- if one were to develop it would fit in next "write permissions", where Substrate's metadata is already close to perfect.
This is a 100% "desktop-centric" view of the world -- maybe with EU enabling third-party mobile app stores the shape of answer to "how could a trusted Substrate mobile wallet (like Nova) have a dapp plugin" will emerge. Or TenCent WeChat will lead the way. The expectation is that we solve Question (A)+(B) in desktop-centric polkadot.js first and do mobile second.
The endpoint of the transformation would have: (a) burgeoning set of polkadot.js apps Developers in some collective (b) users back (a) through subscriptions and staking (cf Astar dAppStaking) (c) in the absence of sufficient (a), Treasury supports (a) (d) polkadot.js attack surface is minimized by the same collective (e) a single common good chain or competing dAppStore chains with their own (f) domain-hosted dapps (g) the generalization from the 100% desktop-centric view to mobile would fit into progress
Kindly advise on whether you'd like to help out with your advice on (A)+(B) on this "issue" -- Codewise, I would love to learn how to be a meaty contributor to polkadot.js apps. I promise to dive very deeply right into the problem in January, navigating between "what would jacogr do?" and "what should I do as a polkadot.js student?", I'm just trying to minimize your facepalm surface here.
If its healthiest to fork polkadot.js apps and come up with some of the pieces of (A) + (B) so you have something to critique first, I can do that too. Thank you!