Initial Multichain API docs #1621
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
|
For MetaMask, I do not believe we need to document the scenario where |
# Conflicts: # docusaurus.config.js # wallet-sidebar.js
…nto 1566-multichain # Conflicts: # docusaurus.config.js # wallet-sidebar.js
# Conflicts: # docs/whats-new.md
|
Sorry to change this, but the multichain API will essentially be rolling directly to production (vs Flask). We will still need to describe it as "experimental" in the API reference though. |
# Conflicts: # docs/whats-new.md
| --- | ||
| description: Learn about the Multichain API. | ||
| sidebar_custom_props: | ||
| flask_only: true |
There was a problem hiding this comment.
it's flask and beta soon i believe. @vandan
There was a problem hiding this comment.
To clarify, should we remove the flask label and replace it with a note that the feature is experimental / a beta release?
| } | ||
| }%% | ||
|
|
||
| sequenceDiagram |
There was a problem hiding this comment.
do we need to show the case where sessionChange is successful?
There was a problem hiding this comment.
This diagram was taken from CAIP 316. Would a successful sessionChange case look the same as the failed case, minus the "connection interrupted" / "connection re-established" arrows?
| scope: msg.data.params.scope, | ||
| method: msg.data.params.notification.method, | ||
| subscription: msg.data.params.notification.params.subscription, | ||
| number: msg.data.params.notification.params.result.number |
There was a problem hiding this comment.
this is specifically for making eth_subscription events over wallet_notify easier to read. It will break if there are other wallet_notify events that are not eth_subscription. Perhaps we remove this block entirely, or make the guards more precise?
There was a problem hiding this comment.
If we remove, would we be removing the entire message handling block?
// Set up message listener for events.
extensionPort.onMessage.addListener((msg) => {
// Format wallet_notify events to be able to read them later.
if (msg.data.method === "wallet_notify") {
console.log("wallet_notify:", {
scope: msg.data.params.scope,
method: msg.data.params.notification.method,
subscription: msg.data.params.notification.params.subscription,
number: msg.data.params.notification.params.result.number
})
return;
}
console.log(msg.data)
})
Alternatively, we can specify that this example specifically makes eth_subscription events easier to read.
| - For each network, request access to [Wallet API methods](../../reference/json-rpc-methods/index.md) | ||
| that your dapp expects to call at any time. | ||
| The methods listed in the `sessionScope` of each Multichain API response indicate which wallet | ||
| capabilities your dapp can use during the connection. |
There was a problem hiding this comment.
session vs connection, what is the better term? 🤔
There was a problem hiding this comment.
This was raised by @vandan in a previous comment, so we switched to "connection" to see how it flows. I'm OK with either term.
The CAIP standards extensively use the term "session", which insinuates a transient connection. MetaMask predominantly establishes persistent connections so we could consider using alternative terminology such as "connection". But I'm not sure if it's more confusing to diverge from the names used in the Multichain API methods.
| }, | ||
| "sessionProperties": { | ||
| "expiry": "2022-12-24T17:07:31+00:00", | ||
| "caip154-mandatory": "true" |
There was a problem hiding this comment.
@adonesky1 we technically don't enforce these yet
There was a problem hiding this comment.
Should I remove the whole sessionProperties or just "caip154-mandatory": "true"?
Description
Initial Multichain API docs.
Issue(s) fixed
Fixes #1566
Preview
(Links updated Mar 5)
Checklist
Complete this checklist before merging your PR: