Listing of methods in api.{derive, query, rpc, tx}

[Stefie]

Initial discussion happened on https://github.com/polkadot-js/apps/pull/684#discussion_r255298425

• Make API more explorable by default and without tools, i.e. if we add something like this for tx, query, derive

  api.tx.listAll() // shows all section.methods with description

• dev-only exposure, probably around here - https://github.com/polkadot-js/apps/blob/master/packages/ui-api/src/Api.tsx#L92

So expose once initialised and we are on dev chain (we should be able to use this https://github.com/polkadot-js/apps/blob/master/packages/ui-api/src/util/isTestChain.ts - looking at it now, now 100% on the dev|loc match, explicit via local and development is probably better. I know why it is short, dev chains originally retuned dev instead of development)

[xlc]

Why only on dev/local chain?

[Stefie]

Why only on dev/local chain?

You can find the initial conversation about it if you‘re following the link in the description. Short version: The main reason are security concerns about exposing the api to everyone, especially bots/ scripts.

[jacogr]

Bit off topic for API only, however...

Quite happy to revisit - but honestly don't want to open up too much unless we really need to. Not thinking security via obscurity, however just dumping stuff on window for a general purpose app where most users are not devs (although I believe devs are the most important customers) so it is accessible everywhere doesn't sound 100% right. So the options are -

1. do nothing
2. only expose API/keyring by default on dev-like chains - the thinking here is basically since it allows devs to play in the console (in addition to the WIP console app), this is where it is most applicable
3. only expose when explicitly asked to do so via a development setting (all chains)
4. always expose to everybody (even where it won't be used)

I'm not really favouring the last option and the first is the current status quo, which also limits approachability.

Having said that, on all 4, don't have strong opinions, since here I'm actually not a user of whatever will be put down. (Which is more-or-less a first here). With this in mind, apart from the "explorability" that Stefie mentioned (which I get, i.e. nice an easy way to see what is where and certainly important), I'm not 100% on the specific intended use-cases and how these differ from what the console will/should give.

[xlc]

I prefer 3.

I think expose to everybody is fine. Just not have it always exposed to ensure it doesn't have unwanted side effects when is not expected. You can add some big red console warning like facebook does if that helps prevent people pasting random code into console. The reality is, if you can convince someone to paste some code to polkadot.js apps console, it is kind of game over anyway. Make it unable to access api from global won't help much because it can add a listener to keyboard events to steal the password when user tries to decrypt the private key.

[jacogr]

100%, yes, you can always find a way in.

3 is probably the most flexible and most "unsurprising approach". And thanks for the FB reminder, that additional warning slipped my mind - I'm not even sure if they still do it, but do remember seeing that ages ago. Ahhh, yes, they still do -

[jacogr]

Going to close this. This one is not bubbling to the top and nobody is clamouring for the capability. Happy to revisit if there is a PR or somebody raises a real need.

[polkadot-js-bot]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.