Reach wallet arcs (0005 thru 0011) #8
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DanBurton
changed the title
|
@fabrice102 And I chatted yesterday about ARC-0009 and how it is going to be very brittle to actually expose the real algosdk objects, when what we really care about is controlling access to the node behind them. He proposed the idea of instead providing a simple HTTP client-style interface, with a However, the pull request to js-algorand-sdk that would enable this was rejected --- algorand/js-algorand-sdk#277 --- and in its conclusion they suggest override an internal variable with an undocumented interface. If js-algorand-sdk refuses to support this pattern, then I think we're left with two choices:
I think that we should move forward with these ARCs and try to produce a new version once we can get buy-in from Algorand to support this in their JS SDK. |
Contributor
Author
+1 If js-algorand-sdk doesn't want to play nice, we could consider creating a competing js sdk for algorand that does the things we want, and try to entice people to switch over to it. I don't love the idea of splitting the community, though. I do think that developers should be able to program against a single interface, and then it Just Works whether you're just using the js sdk, or going through a wallet. ARC 9 is definitely brittle and is intended to be replaced at some point in the future with something better. But, in defense of ARC 9 as currently exists, I think it's reasonable to assume that js-algorand-sdk will at least maintain backwards compatibility with their |
fabrice102
added a commit
to fabrice102/js-algorand-sdk
that referenced
this pull request
Dec 2, 2021
Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk.
jasonpaulos
pushed a commit
to algorand/js-algorand-sdk
that referenced
this pull request
Dec 6, 2021
* Enabling a custom client for Algod and Indexer Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk. * improvements followging review
fabrice102
added a commit
to fabrice102/ARCs
that referenced
this pull request
Dec 7, 2021
From algorandfoundation#8 with the following changes: * use of `genesisID`/`genesisHash` instead of `network` for `enable` * enforce main networks' hashes from genesisID * allow `enable` to return no account for just access to blockchain * support of list of group of transactions in posting * clarify error handling in many cases * add security considerations in many places * add optional `signTxns` and `postTxns` to wallet standard * clarify requirements for confirmation when posting transactions * use `BaseHTTPClient` from algorand/js-algorand-sdk#477 for `getAlgodv2Client` and `getIndexerClient` * other minor changes Main points to discuss: * splitting the error standards out of ARC-0001 and make it a living standard * allow optional argument to post without waiting for confirmation (dangerous)
aldur
pushed a commit
to algorand/js-algorand-sdk
that referenced
this pull request
Jan 20, 2022
* Enabling a custom client for Algod and Indexer Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk. * improvements followging review
miaclark94
added a commit
to miaclark94/js-algorand-sdk
that referenced
this pull request
Sep 7, 2025
* Enabling a custom client for Algod and Indexer Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk. * improvements followging review
alexnguyen868
added a commit
to alexnguyen868/js-algorand-sdk
that referenced
this pull request
Sep 14, 2025
* Enabling a custom client for Algod and Indexer Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk. * improvements followging review
storm-smith54th
added a commit
to storm-smith54th/js-algorand-sdk
that referenced
this pull request
Oct 23, 2025
* Enabling a custom client for Algod and Indexer Currently the only way for a dApp to use the SDK with an API service is to know the URL and token of the API service. This prevents dApps from using API services / algod / indexer provided by the user or by a wallet such as AlgoSigner. In particular: * When using a wallet such as AlgoSigner, a dApp either need to manually serialize data and write path for endpoints (https://github.com/PureStake/algosigner/blob/develop/docs/dApp-integration.md#algosigneralgod-ledger-mainnettestnet-path-algod-v2-path--) or need to not use at all the provided API service. * A user cannot use their preferred (potentially more trusted) API service / algod / index / API services * A dApp cannot easily connect to a private network of the user (See also algorandfoundation/ARCs#8 for more details on wallets and discussion around them.) The goal of this PR is to allow the above scenarios. It does so by introducing an intermediate interface `BaseHTTPClient` and to allow to construct `Algodv2Client` and `IndexerClient` from such a `BaseHTTPClient`. A `BaseHTTPClient` is minimal: it does not perform any serialization/de-serialization, does not fix `accept` headers, does not even try to utf8-decode strings. Its only purpose is to execute directly REST queries and return the raw responses. `BaseHTTPClient` is meant to be stable over releases of algosdk. * improvements followging review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I've also written a small runnable demo which demonstrates an implementation of all of the API functionality specified by this group of ARCs. [except for
window.algorand, since it is a cli demo]https://github.com/reach-sh/algo-demo-wallet