Comments (10)
What the opening post mentions is:
library-agnostic API for dApps to interact seamlessly with the Polkadot network
a standardized protocol for a node and keyring interactions
It doesn't mention more, such as at what level that API would be. I interpret this as a way for dApps to talk to PolkadotApi.
If there is some confusion or disagreement about what should be in this API (let me know if it's just me), then it further reinforces my point that it's too premature to solve this problem now.
But this whole discussion is off-topic to the original question, which is whether this fits in the scope of RFCs.
And my opinion, whatever this API is, is that no, it doesn't fit in the scope of RFCs, for the reason that this API does in no way need to be unique.
from rfcs.
From a dApp developer point of view, it will be good if I only need to integrate with a single API and automatically supports all the wallets and extensions that confirm to this API.
from rfcs.
Just to add my current understanding/thoughts of this:
Currently, browser extensions model themselves off an interface created in PolkadotJS which has some issues (eg it doesn't support arbitrary signed extensions and generally the format is a pain to adhere to). Discovering browser extensions is also a bit of a pain; you wait until some value is added to a global object, which you might miss or whatever.
So, I can see value in:
- Defining a better interface to communicate with browser extensions (I think with the expectation that browser extensions can contain either account management bits, and/or a light client from which to obtain metadata and such; possibly like the new JSON-RPC interface one might impl one or both of these parts).
- Defining an approach for discovering browser extensions that implement this interface (eg @josepot talked about an ACK style thing whereby extensions announce themselves via events, and a user can emit an event to ask which extensions exist).
I can see that such an interface could be defined in the form of a TypeScript interface that would be implemented by some objects that browser extensions make available (or whatever else), but it could also be defined in terms of a JSON-RPC style interface (or anything else, really) if we wanted to be a bit more language agnostic (this would then define the structure of messages passed and received, rather than the interface of some object you can get hold of).
I don't see this as an attempt to give Subxt and PAPI a similar API or anything like that. This is an interface that one might call into if one wants to write a Rust-compiled-to-WASM UI making use of Subxt, and then wants to use browser extensions to help sign and/or submit transactions as part of this. I think it'd be easier using this proposed interface than using the current PolkadotJS inspired one in this case. That is a bit of a niche use case I know.
from rfcs.
I don't think this belongs here.
The reason why we have RFCs for changes to the runtime and the client specification is that there can fundamentally only be one runtime and one client specification.
You can't have for example one client implementation use a protocol and a different client implementation use another, that won't work. For this reason, every change to the protocol go through an RFC so that everyone can weight in.
When it comes to a UI library API, that's not true. We can completely have multiple different APIs in parallel, and multiple different versions of an API in parallel.
Aside from the question of whether it belongs to the RFCs repo, my opinion is also that the idea of having a "standard" API is by itself a bad idea.
You're just intentionally making your job more difficult for, in practice, no benefit.
People will just build tools on top of your library, there's no need for any standard to exist as long as there isn't another library that needs to be compatible with yours.
And what would be the point of another library that has to conform to the exact same API? How could you implement the exact same API in two different ways without making the API leaky and thus bad? Any meaningful difference between libraries requires different APIs.
I would personally recommend you to put this "standard API" idea on the side and revisit it later if there's an actual very pragmatic (not just theoretical) advantage in having one.
from rfcs.
Hi @tomaka ! Thanks for your insights, greatly appreciated! 🙏
Just to be clear, the RFC that I would like to submit would take a lot of inspiration from the EIP-1193, but for Polkadot.
I would personally recommend you to put this "standard API" idea on the side and revisit it later if there's an actual very pragmatic (not just theoretical) advantage in having one.
That's actually what I have been doing so far. However, yesterday I had a conversation with @jsdw and he also saw the value of defining this Provider, because that would greatly simplify the integration of dApps build with Subxt. So, I think that there is already a pragmatic advantage.
from rfcs.
To further clarify, the goal of this RPC would be to "standarize" the following interfaces, plus some known errors, etc. This is by no means a formal proposal, this is just so that you get an idea of what it is that we would like to standarize. Also, please notice that the discoverability of Providers is out of scope for this proposal.
type Callback<T> = (value: T) => void
type UnsubscribeFn = () => void
export interface Chain {
chainId: string
name: string
symbol: string
decimals: number
ss58Format: number
// it pulls the current list of available accounts for this Chain
getAccounts: () => Promise<Array<Account>>
// registers a callback that will be invoked whenever the list
// of available accounts for this chain has changed. The callback
// will be synchronously called with the current list of accounts.
onAccountsChange: (accounts: Callback<Array<Account>>) => UnsubscribeFn
// returns a JSON RPC Provider that it's compliant with new
// JSON-RPC API spec:
// https://paritytech.github.io/json-rpc-interface-spec/api.html
connect: (
// the listener callback that the JsonRpcProvider
// will be sending messages to
onMessage: Callback<string>,
) => JsonRpcProvider
}
export interface JsonRpcProvider {
// it sends messages to the JSON RPC Server
send: (message: string) => void
// `publicKey`: is the public key of the signer account
// `callData`: is the scale encoded call-data
// (module index, call index and args)
// `hintSignedExtensions`: is an **optional** argument which
// allows the dApp to suggest certain values for some signed-extensions.
// However, its worth noting that the Provider may decide to use other
// values based on user input collected after presenting the UI with the
// decoded data to the user.
createTx: (
publicKey: Uint8Array,
callData: Uint8Array,
hintSignedExtensions?: Record<string, Uint8Array>,
) => Promise<Uint8Array>
// `publicKey`: is the public key of the signer account
// `message`: the data that the user will be requested to sign
signData: (
publicKey: Uint8Array,
message: Uint8Array
) => Promise<Uint8Array>
// it disconnects from the JSON RPC Server and it de-registers
// the `onMessage` and `onStatusChange` callbacks that
// were previously registered
disconnect: UnsubscribeFn
}
export interface Account {
// public key of the account
publicKey: Uint8Array
// The provider may have captured a display name
displayName?: string
}
from rfcs.
the RFC that I would like to submit would take a lot of inspiration from the EIP-1193, but for Polkadot.
Just because Ethereum did that doesn't mean that it's a good idea.
the goal of this RPC would be to "standarize" the following interfaces
But what's the point of "standardizing" that?
Can PolkadotApi and Subxt not just both implement a similar API?
A dApp would only ever use either PolkadotApi or Subxt. They choose between the two which provider they want to use. Having a standard API would help in one very specific situation: if a dApp wants to migrate between PolkadotApi and Subxt, and that the APIs are not exactly the same, they would need to adjust their code.
Do you really think that this is such a big problem that it's worth spending hours writing documents and getting consensus about a standard API?
As far as I know, there exists 0 dApps on top of PolkadotApi or Subxt right now, so even if it was worth the effort, does this problem really need to be solved now? The further you go into the "standard" side, the less freedom you have to develop PolkadotApi/Subxt. Again, you're just making your life harder.
from rfcs.
automatically supports all the wallets and extensions that confirm to this API.
That's not what this is about, though.
If you want a standard interface between wallets/extensions and dApps, then what needs to be standardized is the list of messages described here: https://github.com/paritytech/substrate-connect/blob/main/packages/connect-extension-protocol/src/index.ts
And not any specific JavaScript API.
from rfcs.
Yup; let's discuss this on the Polkadot forum and go from there :)
from rfcs.
I overall agree with @tomaka on the fact that it's probably too premature to solve this problem now. At this point it probably makes more sense to work on making this a "de-facto" standard, and if we actually manage to make that happen, then perhaps we can think about having a more formal specification around it.
There are a number of things that have been said in here that I would like to clarify, though. However, it's probably best to do that in the polkadot forum 🙂. Anyways, I'm happy that I asked before creating the formal RFC 😅.
from rfcs.
Related Issues (20)
- RFC idea: Parachain management & recovery parachain
- Light clients and downloading block bodies HOT 4
- Bot for automatic merging apprroved RFCs/closing rejected RFCs HOT 17
- Mild gossip reform HOT 2
- Pre-RFC: XMS language (XCM Made Simple) HOT 8
- Governance parachain fallback HOT 2
- Metered Weights in the Polkadot-SDK
- Research: FRAME alternative based on WASM components
- Define categories and scope of RFCs
- RFCs Web Page [mdbook] HOT 7
- Define the responsibilities so we can evaluate salary payment requests HOT 5
- Bot: Notify people about new fellowship referendas HOT 19
- [xcm-emulator] Make a generic `genesis` constructor method HOT 1
- Add a changes trie HOT 4
- mdBook fails to build if there is a link in the RFC title
- Permisionless way to create HRMP channels between system parachains and other parachains HOT 19
- Stale Nomination Reward Curve HOT 14
- Adding a `CoreIndex` commitment to candidate receipts HOT 23
- Move the XCM spec and RFC process under the Polkadot Fellowship HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rfcs.