-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support DApp signing #23
Comments
Please do some technical investigation about native messaging(such as custom protocol of electron, native messaging of web extension) between web app and electron app, which enables a web app to communicate with neuron via IPC. With native messaging, we can empower a web app to track user's assets in watch wallet mode and request a sign for transactions. Ref: https://www.electronjs.org/docs/latest/tutorial/launch-app-from-url-in-another-app |
watch-only walletsequenceDiagram
participant web app
participant neuron
participant ckb explorer
web app->>neuron: request xpub key[native messaging]
neuron->>web app: xpub key[opening url]
web app->>ckb explorer: all derived addresses
ckb explorer->>web app: balances, live cells, tx history
web app->>web app: feature-rich UI
sign transactionsequenceDiagram
participant web app
participant neuron
participant ckb explorer
web app->>ckb explorer: all derived addresses
ckb explorer->>web app: live cells
web app->>web app: generate a tx
web app->>neuron: request a sign and submit[native messaging]
neuron->>web app: tx hash[opening url]
web app->>ckb explorer: tx hash
ckb explorer->>web app: tx status
|
https://github.com/nervosnetwork/keypering support sign DApp, can we refer to it? |
Keypering uses RPC for communication because it allows bidirectional messaging and less consideration on safety. But neuron won't expose an endpoint of RPC so native messaging is required. I also prefer |
Should change to In addition, how can we cooperate to finish this task? |
Yes,
We'd better finish research first, including
Once the technical design and product design are done, tasks will be split into chunks, maybe as follows,
Until then we can estimate how many works to do and how to cooperate with each other |
For protocol between dapp and neuron, |
Use custom protocol like this? It uses https://www.electronjs.org/docs/latest/api/app#appsetasdefaultprotocolclientprotocol-path-args.
protocol.mov
file-protocol.movreference: |
The first looks good to me. After reading the docs I got that |
Protocols to have a look at:
APIs required:
|
APIs:
|
good point |
Can |
We can add verification when opening the app by the default protocol with some parameters. |
The source can be fabricated if it's specified by dapps but not by their hosts, say, website A sends a request with a declaration that it's website B, we cannot verify it. Maybe we can avoid a verification before handling the request, instead, we display the declared source with the request to users, and send the response to the declared source. By this way, the website A disguises itself as website B cannot get the response. Also, we don't need an extra API |
The register should be a simple operation to check. Then when calling other APIs, users know it must be from safety Dapp. Or else the user needs to check the current transaction or message is correct, and check them is complex. And maybe we can't get the host information. we can only get the request URL from the source. |
We can check dapp's registration automatically before displaying the tx on their first request of data sequenceDiagram
autonumber
participant DApp
participant Neuron
DApp->>Neuron: Request data
Neuron->>Neuron: Register DApp
Neuron->>DApp: Respond data
instead of sending sequenceDiagram
autonumber
participant DApp
participant Neuron
DApp->>Neuron: Register DApp
Neuron->>DApp: Registered
DApp->>Neuron: Request data
Neuron->>DApp: Respond data
It would be enough if the request URL is in |
How do we check dapp's registration automatically?
Maybe my description is mistake. I mean we can only get the URL that includes customer protocol and parameters. |
Neuron will have a table recording interacted DApps and marks them
The We can do it similarly, with a source URL displaying to the user and sends a response to the URL user has checked, instead of verifying the source of the message. |
yeah, |
I didn't make it clear. Similar to handling authentication URL in emails, users don't have to care about the email senders. Neuron accepts the URLs declared in messages, even that they are not consistent with the sources, and sends responses to the declared URLs, instead of verifying the sources of messages. It's a reply to |
|
I have created a repository to test DApp sign with Neuron. I found it seems to have no length limit for open custom protocol. I have written a simple definition of it, it will be perfect later. request params
result
|
|
{
requestId: uuid
appName: string
type: 'sign_message' | 'sign_transaction'
tx?: {
cell_deps: {
out_point: {
tx_hash: string
index: string
}
dep_type: string
}[]
header_deps: string[]
inputs: {
previous_output: {
index: string
tx_hash: string
}
since: string
}[]
outputs: {
capacity: string
lock: {
args: string
code_hash: string
hash_type: 'type' | 'data'
},
type: string | null
}[]
outputs_data: string[]
version: string
}
message?: string
callback: string
version: string
chain: 'mainnet' | 'testnet'
}
{
code: number
err: string
requestId: uuid
result: {
witnesses: string[]
}
hash: string // for validation message is not lost
} |
We may work with Nexus team to promote the protocol, but Nexus is not ready yet in the protocol level, this issue will be re-activated later. Please ping us when you're ready @homura |
Reactivate this issue and expand the scope to
|
Tracked by 3 individual issues:
|
The text was updated successfully, but these errors were encountered: