diff --git a/api/json-rpc.mdx b/api/json-rpc.mdx index d2004ce3..d78265a8 100644 --- a/api/json-rpc.mdx +++ b/api/json-rpc.mdx @@ -12,6 +12,14 @@ To interact with soroban-rpc from inside a JavaScript application, use the [Java When XDR is passed as a parameter or returned, it is always a string encoded using standard base64. +:::info + +Please note that parameter structure must contain named parameters as a by-name +object, and not as positional arguments as a by-position array. Positional +arguments as a by-position array will be deprecated in future RPC releases. + +::: + ## Open-RPC Specification Soroban-RPC provides an [OpenRPC] specification document that can be used to mock, build, and/or validate both server and client software implementations. This document is used to generate all of our [methods] documentation pages. You can view the full [specification document here]. Additionally, you can experiment with this specificaiton document in the [OpenRPC Playground]. diff --git a/api/pagination.mdx b/api/pagination.mdx index 4a9e0cfa..3ac52f5a 100644 --- a/api/pagination.mdx +++ b/api/pagination.mdx @@ -16,7 +16,7 @@ For example, calling a method with pagination parameter set: ```json { "jsonrpc": "2.0", - "Id": "1", + "id": "1", "method": "exampleMethod", "params": ["other", "arguments", { "cursor": "1234-1", "limit": 100 }] } diff --git a/docs/notes.mdx b/docs/notes.mdx index 53df8fa5..1cdc9fc3 100644 --- a/docs/notes.mdx +++ b/docs/notes.mdx @@ -21,6 +21,30 @@ description: Notes and recordings from the Soroban protocol & developers meeting 2. Stellar + Soroban documentation survey 1. [Take the survey](https://discord.com/channels/897514728459468821/1204462856037470248/1205196745877757962) +## 2024-02-01 + + + +[Discord agenda thread](https://discord.com/channels/897514728459468821/1201979721211203614) + +1. The proposal is to advance stellar-core by adding a host function to verify the secp256r1 signature, which is the most common elliptic curve used outside of the blockchain space. It is useful in connecting off-chain authentication interfaces with on-chain functionality. +1. Note that the proposal is not for a new signer type but a host function. +1. Leigh investigated adding support for the WebAuthN use case, by allowing a custom account / smart contract to sign soroban auth entries using a secp256r1-signed payload. +1. secp256r1 is supported by phones, passkeys, and enables an app to replace passwords. This is a massive benefit to user-facing applications like wallets. +1. Pros and cons of the interface: blockchains generally implement the recovery interface over the verification interface but verification is easier for developers as it reduces burden on the client and the network. +1. The WebAuthN use case requires encoding and decoding of base64 payloads and decoding JSON blobs, which is not currently supported in Soroban. +1. While there are hacky ways of accomplishing the latter, it’s not a great developer experience and final implementation is susceptible to breakages on updates. +1. It is also costly to bundle decoding with verification in guest. +1. Soroban has always led with a batteries included mindset. Keeping in line with that approach, it makes sense to further investigate and determine whether a host function makes sense for these as well. +1. Leigh’s implementation may require further evaluation of the crates used for ecdsa and p256. +1. Brief discussion around proposed process for adding of a host function by a non-core dev. + ## 2024-01-26