stellar/stellar-demo-wallet

Provides a front-end interface to test SEP interoperability. Website at https://demo-wallet.stellar.org/

Stellar Demo Wallet

The Stellar Demo Wallet is our newly rebuilt application for interactively testing anchor services.

If you would like to automate testing of your anchor service, check out the SDF's anchor tests suite viewable at https://anchor-tests.stellar.org/.

This repository was originally created for the Build a Stellar Wallet tutorial series. (That project has since moved over here).

If you want to use parts or all of the project to kickstart your own wallet, feel free to clone or copy any pieces that may be helpful.

Mainnet vs. Testnet

This application defaults to using Stellar's testnet.

This application can be used on Stellar's mainnet by setting HORIZON_PASSPHRASE & HORIZON_URL on window._env_ object (this project uses packages/demo-wallet-client/public/settings/env-config.js file).

window._env_ = {
  HORIZON_PASSPHRASE: "Public Global Stellar Network ; September 2015",
  HORIZON_URL: "https://horizon.stellar.org",
};

All accounts on mainnet that are used with this application should be considered compromised. If you want to test services on mainnet with this tool, make sure to create a new account and fund it with the minimum assets required.

Note, that dy default base fee is 100 stroops. That may not be enough for mainnet application, and base fee can be changed via REACT_APP_BASE_FEE environment variable

Getting A Test Account Up and Running

You can use the demo wallet to interact with the following anchor services:

• Regulated Assets API (SEP-8)
• Hosted Deposit and Withdrawals (SEP-24)
• Deposit & Withdrawal API (SEP-6)
• Cross-Border Payments API (SEP-31)

You can connect to any domain that has a Stellar Info File (also known as SEP-1, or a stellar.toml file).

The instructions below are for demo-ing standard integrations supported by Stellar test server, testanchor.stellar.org, or by the SEP-8 reference server, sep8-server.dev.stellar.org. For these integrations, the logs to the right of the screen will show every network call.

Demo-ing a Regulated Asset Payment (SEP-8)

1. Click "Generate keypair", and then click "Create account" - this will create a balance of 10,000 XLM.
2. Click “Add asset” and add MYASSET with the anchor home domain sep8-server.dev.stellar.org.
3. Click “Add trustline” - this will allow you to hold MYASSET.
4. Click on the "Copy" link on the right of your public key and use that value to get some unities of MYASSET using the link https://sep8-server.dev.stellar.org/friendbot?addr=<paste_your_address_here>. Refresh the demo-wallet page to see funds in your account.
5. Select "SEP-8 Send" from the dropdown of MYASSET and click "Start" in the modal.
6. In the "destination" field, input an address that also has a trustline to MYASSET.
7. The modal will display the approval criteria used by the SEP-8 server. Depending on the conditions described there your payment can be automatically approved or you may be required to undergo an additional KYC step.
8. After your payment gets revised and signed by the SEP-8 reference server you'll need to review the updated transaction before the demo wallet submits the payment.
9. If the payment has been successfully sent you'll see "SEP-8 send payment completed 🎉" in the logs.

Demo-ing a Deposit on Testnet with Hosted Deposit and Withdrawal (SEP-24)

1. Click "Generate keypair", and then click "Create account" - this will create a balance of 10,000 XLM.
2. Click “Add asset” and add SRT (this stands for Stellar Reference Token, it’s our representation of XLM for the test server) with the anchor home domain testanchor.stellar.org.
3. Click “Add trustline” - this will allow you to hold SRT.
4. Select “SEP-24 deposit” from the dropdown for your SRT asset and click "Start" in the modal.
5. If your browser doesn't already, make sure it allows pop-ups - this is how the demo wallet requests KYC info.
6. Enter your name and email in the pop-up - this information doesn't need to be real, but the interface will want a valid email.
7. Click “Skip confirmation” - skipping it won't be possible in live integrations but helps the process move ahead in the demo.
8. Select the asset you would like to provide to the anchor. Note that there is no real asset you actually need to provide off-chain, it's just for demonstration.
9. Enter a number into the amount and click "Submit".
10. If you opted to provide "USD" in the previous form, you'll be asked to confirm the exchange rate from USD to SRT. Select "Confirm Transaction" to continue.
11. Leave the pop-up window open while you wait to see the deposit of SRT made to your account - you can close when you see “Status” is complete and you have SRT.

Demo-ing Cross-Border Payments (SEP-31) on Testnet

Note: specifically in the case of demo-ing SEP-31 in the Demo Wallet, notice the public and secret keys don't represent the Sending Client but instead the Sending Anchor's account. In SEP-31, the only Stellar transaction happening is between the Sending and the Receiving anchors.

1. Follow the steps above in order to establish an amount of SRT to send.
2. Select “SEP-31 Send” from the dropdown for your SRT asset and click "Start" in the modal.
3. Enter the requested information in the pop-up - none of the info has to be real for this testanchor.stellar.org demo, this is only to show the fields required. When testing another anchor you may need to adhere to their validation requirements.
4. If the payment has been successfully sent you'll see "SEP-31 send payment completed" in the logs.

Hosting Anchor Services Locally

You can serve stellar.toml files from localhost. When using locally hosted stellar.toml files on demo-wallet.stellar.org, some browsers might block them for security reasons if you’re not using https. If you’re running the demo wallet locally, this is not a problem.

Running the Demo Wallet Locally

You can run the demo wallet locally, either by installing the application on your machine or by using Docker.

Local Installation

yarn install

Add CLIENT_DOMAIN (where stellar.toml is hosted) and the wallet backend WALLET_BACKEND_ENDPOINT to the window._env_ object in packages/demo-wallet-client/public/settings/env-config.js.

NOTE: if using a locally running test anchor (in docker) use docker.for.mac.host.internal, this will allow the anchor that's running in a docker container to access the host network where the client domain (server hosting the stellar.toml) is running. ex:

window._env_ = {
  CLIENT_DOMAIN: "docker.for.mac.host.internal:7000",
  WALLET_BACKEND_ENDPOINT: "http://demo-wallet-server.stellar.org",
};

Build shared files that are consumed by both the client and server.

yarn build:shared

And run the client:

yarn start:client

To build the client app for production, run:

yarn build:client

To run the server locally:

yarn start:server

And build the server for production:

yarn build:server

Docker

If you want to run the demo wallet on testnet, building the project is easy.

docker compose build

Then, launch the containers.

docker compose up

Note that the docker compose file defaults to using SDF's demo wallet server, but you are free to edit the compose file to use a local instance of the server.

---

Release Notes

v1.2

• SEP-06 now supported
• SEP-08 now supported
• Fixed a bug when overriding home domain
• Fixed an issue where balance amounts were being overwritten
• Sending to Muxed Accounts is now supported

v1.1

• Fix for local CORS issue
• Updated Sentry to log exceptions

v1.0

• Revamped UI
• All SEPs are integrated into one tool
  • SEP-24 and SEP-31 are now found in the Asset action drop-down menus
• Ablity to download logs
• Claimable Balances supported

Helpful links

• https://www.stellar.org/developers
• https://stellar.github.io/js-stellar-sdk/
• https://github.com/stellar/js-stellar-sdk

stellar-demo-wallet's Issues

Feature Request: Add `Send ClaimableBalance` to Destination Account

What problem does your feature solve?

Give Accounts the access to send a claimable balance to other accounts

What would you like to see?

Alongside the the Send Deposit and Withdraw buttons under the asset's balance include a send claimable balance button.

The UI will look nearly identical to the send feature.

Feature Request: Extend `Send` method to send a claimable balance if destination has no trust-line

What problem does your feature solve?

Doesn't block source account from sending an asset to a destination account that doesn't have a trust-line established for that asset.

What would you like to see?

When the source account attempts a send (make payment) operation to a destination account that doesn't have a trust line established for that asset it should instead attempt a claimable balance operation for that account.

SEP-31 support all possible statuses

@quietbits commented on Mon Mar 22 2021

Currently, we're handling only the "happy path". Documentation for all possible statuses.

Add SEP-6 Support

The SEP-8 approval server should be able to revise transaction payments for the happy path

Summary

The SEP-8 approval server should be able to receive a transaction and sandwich its payments with AllowTrust operations.

At first we should focus on landing a code that addresses the happy path, i.e. if the incoming transaction contains only one operation of the type "payment" whose asset is issued by the issuing account we should revise the transaction, going from:

Operation 1: Payment from A to B

into:

Operation 1: AllowTrust op where issuer fully authorizes account A, asset X
Operation 2: AllowTrust op where issuer fully authorizes account B, asset X
Operation 3: Payment from A to B
Operation 4: AllowTrust op where issuer fully deauthorizes account B, asset X
Operation 5: AllowTrust op where issuer fully deauthorizes account A, asset X

Request

According with SEP-8 the request format expected by the approval server should look like:

POST /tx_approve

Request:

{
  "tx": "AAAAAHAHhQtYBh5F2zA6..." // the transaction XDR
}

Response:

{
  "status": "revised",
  "tx": "AAAAAHAHhQtYBh5F2zA6...",
  "message": "Authorization and deauthorization operations were added."
}

For more info please refer to https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md#revised

Toml File

We should update the toml file approval_criteria explaining the approval server only supports payment operations.

Submit form with Enter, and close with Esc

@quietbits commented on Thu Mar 25 2021

Currently, we don't support keyboard actions for forms, it would be nice to add Enter and Esc.

Feature Request: Deposit Untrusted Assets

What problem does your feature solve?

Leveraging the claimable balance feature in SEP24 to allow accounts to deposit off-chain assets to anchors without a trustline.
Developer should be able to debug the scenario where they add the asset in the UI and go through a deposit flow without adding trustlines.

What would you like to see?

• “Add asset” button enters the issuer/home domain but skips adding trust to said asset .
• Add an “add trust” button that allows them to add trustline explicitly.
• Behind the scenes, when claiming balances from those assets add a trustline to account (one time) to claim.
• Remove "untrusted" label when trustline is established.
• List a select few assets on the wallet's account page
• Label the assets that qualify as "untrusted"
• Allow users to make deposits on those listed untrusted assets

What alternatives are there?

https://github.com/Zagan202/stellar-demo-wallet/tree/deposit-untrusted-TEST-asset

Enhance Demo Security Approach

You might look at using a more modern encryption library to protect the wallet in the demo app. You might also find a massive savings in terms of the size of the code that needs to be transpiled and downloaded to the browser when compared to the current usage of SJCL (which is old and huge). A possible suggestion:

https://github.com/dchest/tweetnacl-js

You can play with it at:

https://tweetnacl.js.org/#/

Also, you should "stretch" the pin code and not use it directly as an encryption key. Stretching turns a weak password (e.g. "1234") into 32 or more bytes of secure data. The key stretching process is also "memory and CPU hard". Meaning that it might take a few hundred ms to stretch your pin code into a good key. This prevents someone that has access to your encrypted wallet from attempting brute force attacks on the pin code by slowing down that process dramatically (while not being noticable to the user).

An example lib to look at would be:

https://antelle.net/argon2-browser/

More info about key stretching:

https://en.wikipedia.org/wiki/Key_stretching

Cheers!

Create "/friendbot" endpoint in the regulated asset server to distribute regulated assets to an account

Integrate w/ SEP-8 server for "Action Required" transactions

Scroll with Logs

The demo client does a great job of always showing the most-recent log message at the bottom, bubbling the existing log messages up the page. We should have this so the developer can just watch the logs instead of scrolling down.

Add ability to plug other anchors in

For sep24 deposit/withdrawal, the wallet currently hardcodes the stellar reference anchor (testanchor.stellar.org). We should allow people to add their own anchors to test. We can either use a config screen like the demo client, or allow deposit / withdraw for any asset that has a trustline in the wallet.

Add show/hide functionality to JSON in logs

The SEP24 Demo Client uses a show/hide link to keep the JSON shown in logs neat - we need to port this over to the Stellar demo wallet.

Add 'Advanced Config' Button and Menu

Developers will want to tweek the way the demo wallet operates in order to test all edge cases on their anchor.

For example, Settle asked us to add a on_change_callback field to the existing demo client today. The demo wallet should also be able to do that. Note that this includes updating the URL so the config is completely sharable.

Instrument SEP24 with logging

Use the new logview component to instrument the sep24 functionality to replace the demo client

Deposit and withdraw functionality should be instrumented using the new logview component. We can use the loggers functionality to add logs for any network calls, instructions, or errors needed to illustrate to a client exactly what's happening during a deposit or withdrawal.

Logger methods can be found here and can be accessed from any method in the wallet component via this.logger. Logs will show up in the log view component that can be opened in the UI with the "Show Logs" button.

Tutorial link in readme.md is broken

Here's the current link, not sure where it should go: https://github.com/tyvdh/tutorials-build-a-stellar-wallet

Replace TESTNET and MAINNET raw strings with constants

'https://horizon-testnet.stellar.org' 'https://horizon.stellar.org'
should be replaced with global constants TESTNET_URI and MANNET_URI.

Clean up UI

Clean up UI so it looks nice as a wallet and as a replacement to the demo client

The SEP-8 approval server should be able to revise transaction payments for edge cases

Summary

The SEP-8 approval server should be able to receive a transaction and sandwich its payments with AllowTrust operations.

Given the ticket #120 was already implemented, we should focus on sandwiching operations for edge cases. Some cases I can think of:

• If the provided transaction contains offer(s) with assets issued by the distribution account we should reject it informing the client this approval server doesn't support offers yet.
• If the provided transaction contains multiple operations we should be able to sandwich the necessary payments while maintaining the remaining operations and their order.
• If after sandwiching the necessary payments we notice the amount of operations in the transaction overcomes the limit of 100 operations per transaction we should reject it on the spot informing the client the resulting number of operations was too large.

Toml File

We should update the toml file approval_criteria with the new rules if needed.

Properly determine if an asset is regulated

Add SEP31 support

What problem does your feature solve?

Adds a SEP31 demo.

What would you like to see?

A button "Send to Bank" which makes a transfer to a bank account via SEP31 using the testanchor.

What alternatives are there?

• https://sep31-demo-client.netlify.app/

Implement the claimable balance support in our demo client/wallet

What problem does your feature solve?

In order to leverage the new Protocol 14/15 feature claimable balances we need wallets to query for accounts that have claimable balances to claim.

What would you like to see?

Notify Wallet users/accounts when a claimable balance is available for them to claim.

The SEP-8 approval server should identify "Rejected" transactions

Sumary

The SEP-8 approval server should identify "Rejected" transactions.

Request

According with SEP-8 the request format expected by the approval server should look like:

POST /tx_approve

Request:

{
  "tx": "AAAAAHAHhQtYBh5F2zA6..." // the transaction XDR
}

Response:

{
  "status": "rejected",
  "error": "The destination account is blocked." // the error message
}

Criteria

I could think of the following criteria to reject a transaction (there could be more):

• if no transaction is submitted, respond with {"status":"rejected", "error":"Missing parameter \"tx\""}
• if can't parse XDR respond with {"status":"rejected", "error":"Invalid parameter \"tx\""}
• is the transaction sourceAccount the same as the server distribution account? If so, reject with {"status":"rejected", "error":"The source account is invalid."}
• are there any operations where the sourceAccount is the server distribution account? If that operation is not of the type AllowTrust then respond with {"status":"rejected", "error":"There is one or more unauthorized operations in the provided transaction"}
• If all of that pass we can respond with {"status":"rejected", "error":"Not implemented."} for now.

Toml File

We should remember to update the toml file with the SEP-8 fields, something in the format:

[[CURRENCIES]]
code="GOAT"
issuer="GD5T6IPRNCKFOHQWT264YPKOZAWUMMZOLZBJ6BNQMUGPWGRLBK3U7ZNP"
regulated=true
approval_server="https://goat.io/tx_approve"
approval_criteria="The goat approval server will ensure that transactions are compliant with NFO regulation"

Our server is deployed in https://regulated-assets-approval-server.dev.stellar.org/health

The SEP-8 approval server should be able to evaluate a transaction to "Pending"

Summary

The SEP-8 approval server should be able to receive a transaction and return a pending state in case the payment amount is greater than 1000.

This value is totally arbitrary but it would be a simple way to implement one of the SEP-8 states.

Request

According with SEP-8 the request format expected by the approval server should look like:

POST /tx_approve

Request:

{
  "tx": "AAAAAHAHhQtYBh5F2zA6..." // the transaction XDR
}

Response:

{
  "status": "pending",
  "timeout": 60000,
  "message": "Further verifications are required due to..."
}

For more info please refer to https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0008.md#pending

Toml File

We should update the toml file approval_criteria explaining the criteria for marking a transaction as "pending" and not revise it.

Remove postMessage callback, support /transaction polling

We should poll the anchor's /transaction(s) endpoint instead of waiting for them to send a callback

related to stellar/integration-meta#258

Feature Request: support SEP-8 in the Demo Wallet

What problem does your feature solve?

We plan on using this demo wallet to validate the POC of SEP-8. We can also use the code in the demo wallet as a reference implementation.

What would you like to see?

After the SEP-8 support is added to the wallet SDK, we can integrate the wallet SDK into the demo wallet.

What alternatives are there?

N/A.

Add Mainnet Support

The old demo client can run everything on mainnet, we should offer the same functionality on the demo wallet.

This should simply involve making the NETWORK_PASSPHRASE used configurable, with some kind of toggle button for switching between testnet and mainnet.

The only challenge I see with this issue is this project's use of Friendbot for createAccount(). We may have to remove the Create Account button if mainnet is selected.

Add SEP-30 Support

What problem does your feature solve?

Make it possible to compose SEP-30 integrations with other SEP integrations in the demo client. Keep the demo clients contained in one place.

What would you like to see?

The functionality of the existing standalone SEP-30 demo client incorporated into the demo client. For example:

• A form that supports registering an account with one or more recoverysigners (SEP-30).
• A form for configuring those recoverysigners and their corresponding webauth (SEP-10) servers.
• A form for recovering an account with one or more recoverysigners.

What alternatives are there?

• https://github.com/stellar/recoverysigner-demo-client

cc @stellar/nebula

Make Demo Wallet more portable

Currently its not easy to "linkify" and send others SEP scenarios
We need new query params to make this possible

Some ideas for query params

• "asset_code"
• "domain"
• "add_trust"
• "CB" or "ClaimableBalance"

SEP-31 allow users to provide memos or customer IDs

@quietbits commented on Thu Mar 25 2021

Allow users to provide memos or customer IDs so they can do SEP-31 sends between customers that already exist on the anchor's service.

Add common footer with a Github icon and link to this repo

What problem does your feature solve?

Better visibility to code and a way for users to provide feedback, log bugs, and submit changes themselves.

What would you like to see?

A footer added to the mainpage with the Github icon and link to the Issues or Main page of this repo

What alternatives are there?

We can keep the announcement banner at the top of the page for a bit but other than that there isn't an easy way to discover this repo.

Integrate w/ SEP-8 server for "Revised" transactions

Feature Request: Tutorial Wallet vs Demo Wallet

Hi friends, just opening a thread here to discuss the issue and resolution with where this wallet started and where it is now.

Originally this repo was created as a companion repo for the "Building Apps" tutorial: https://developers.stellar.org/docs/building-apps

Since then it has been adapted and utilized for far more than that however those tutorials all still point to this repo along with several other external articles and references.

Both use cases are obviously viable and necessary however considering the public nature of the tutorial my recommendation is to clone this repo into a new project and rename this repo stellar-reference-wallet and keep the stellar-demo-wallet name for the cloned tutorial wallet. This will allow all the links to not be broken (I hope) while keeping all the history, tickets, etc on this repo under a new name.

Thoughts?

cc: @JakeUrban @lydiat @Zagan202 @leighmcculloch

Feature Request: Claim Balances Button

What problem does your feature solve?

Give users the ability to claim any outstanding claimable balances.

What would you like to see?

• Ability to claim claimable balances

• Easy to follow UX

  • Surface what balances could be claimed
  • Display what conditions (predicates) are required to claim said balances if any
  • Sign to confirm claim.

• Deprecate Show Claimable Balance Details in favor of Claim Available Balances

  • Nice to have: Show Claim Available Balances only when a user has balances available

Standardize TOML and home domain per-asset

Right now the Wallet component has a not-very-useful homeDomain attribute and toml attribute. The wallet was built with the assumption that you'd only have one anchor's assets in your wallet.

Change the structure of the wallet to store:

• assets
  • homeDomain
  • toml contents

Then, take all occurrences of TOML usage and rewrite it to use these Wallet props. Also, remove any place where an error is thrown due to the Stellar account in question not having the home domain attribute set.

Integrate w/ SEP-8 server for "Pending" transactions

Discuss and implement Log View

This demo wallet is good for showing examples of how to do things, and it would be nice to do something similar to the various demo clients we have where we show introspected information about what is happening over time

Remove "regulated asset" code

Rip out any code that currently makes the way regulated assets work on the wallet.

Integrate w/ SEP-8 server for "Rejected" transactions

Add the ability to send someone a logged in wallet link

In the SEP24 demo clients, we have the ability to send a link with all the config values set up, so anyone can click a link to run AnchorX's SEP24 implementation in a single click.

The demo wallet doesn't have this concept of a 'configuration', instead we use the actual set of balances to allow deposit or withdraw. So rather than adding the home domain of your anchor, you just add a trustline to your currency and then you can deposit or withdraw from there.

I think we can get the same benefits by creating a way to send a link with a stellar private key in the URL so someone can say "Here is a wallet with our token in it, you can try out withdraw by just pressing the button"

Refactor Wallet's account attribute

• rename StellarAccount interface to AccountState

• rename Balance interface to Asset

  • Pull the properties below into "Asset"

  homeDomain?: string
  toml?: any

  • Deprecate interface WalletAssetDetails, @ Prop() assets @ Prop() balance

    // export interface WalletAssetDetails {
    //   homeDomain?: string
    //   toml?: any
    // }
    ...
    // @Prop() assets: Map<string, WalletAssetDetails> = new Map()
    // @Prop() balance: Map<string, Balance> = new Map()

• Update AccountState interface to include assets: Map<string, Asset>

  interface AccountState {
    publicKey: string
    secretKey: string
    response?: ServerApi.AccountRecord
    claimableBalances?: ServerApi.ClaimableBalanceRecord[]
    assets: Map<string, Asset>
  }

• Rename Asset interface's state property to response

  interface AccountState {
    ...
    response?: ServerApi.AccountRecord

• Refactor code leverage the AccountState

  • Code that calls(writes or reads) the wallet obj's assets prop or balance will instead call AccountState.Asset

• Ensure we're saving wallet's AccountState to local storage.

• Deprecate balance keystore

Feature Request: Add SEP-12 support

What problem does your feature solve?

Given the challenges some wallet developers have encountered implementing SEP-12, creating our own end-to-end test integration would help us see where the pain points are and provide developers insight as they developer their own solutions.

What would you like to see?

Provide a way for wallet developers to test wallet implementation against anchor test servers or aPolaris test server.

What alternatives are there?

None at the moment. If SEP-12 isn't used very much, or is not a priority SEP for use, perhaps we don't need this feature.

Feature Request: Stellar exchange usage in the sample demo wallet

What problem does your feature solve?

Asset exchange feature

What would you like to see?

I want to transfer TypeA asset from my side and destination account get it in the form of TypeB asset.

What alternatives are there?

Cancel prompts gracefully

Feature Request: Include `claimable_balance_supported` param to deposit POST req

What problem does your feature solve?

During the intermediate phases updating wallets and anchors to support claimable balances we need a feature flag in order to
make clear which wallets have migrated to use this new feature.

This feature flag will be a new request parameter for POST TRANSFER_SERVER_SEP0024/transactions/deposit/interactive named claimable_balance_supported

What would you like to see?

Name	Type	Description
claimable_balance_supported	boolean	(optional) True if submitting transactions as a claimable balance is accepted, false otherwise.

TypeError & Uncaught

What version are you using?

"name": "stellar-demo-wallet",
"version": "0.0.47",
"devDependencies": {
"@stencil/core": "^2.3.0",
"@stencil/postcss": "^2.0.0",
"@stencil/sass": "^1.3.2",
"@types/autoprefixer": "^9.7.2",
"@types/jest": "26.0.15",
"@types/node": "^14.14.20",
"@types/puppeteer": "5.4.0",

js-xdr@^1.2.0

What did you do?

1. . Cloned repo to admin user in Gitbash terminal from with in VSC (tried outside VSC got the same issues). Yarn install, Yarn start and Yarn build.
   Yarn start only as dist & www folders all ready built (trying yarn build after yarn start will fail build as duplication dist folder. Nuking dist on yarn build will finish rebuild). Viewed localhost3333 to find emulator?? clear & toggle logs buttons present; toggle log worked fine. Nothing else present (No other button). Checked chrome developer tools console output of errors.

1). These are the Error I get:

TypeError: Failed to resolve module specifier "sodium-native". Relative references must start with either "/", "./", or "../".underified console error @ (index-9c8102b3.js:1939)

//* Terminal report - Warn
('sodium-native' is imported by ./node_module/stellar-base/lib/signing.js, could not be resolved - treating as external dependency).*//

Bundling Warning Unresolved_import
'sodium-native' is import by sodium-native?commonjs-external, but could not be resolved - treating it as an externa

Uncaught (in promise) Error: Constructor for "stellar-wallet#undefined" was not found
at initializeComponen @ index-9c8102b3.js:1939

//* Uncaught possibly due below promise in loader.tsx from line 15, VSC states:
Expected 1 argument but got 0 did you forget to include 'void' in your type argument to 'promise' lib.es2015.promise.d.ts(33,34): An argument for 'value' was not provided. If I but a number in the concatenation i.e resolve(0). the state goes way but issue must remain as uncaught.

 componentWillLoad() {
    return new Promise((resolve) => {
      if (!this.chances.length) this.generateChances(9)
  
    if (!this.interval)
        this.interval = setInterval(() => this.getChance(), 100)

      resolve()  

*//

What did you expect to see?

Any example of the demo wallet of the demo wallet was what I expected to see:
https://stellar-demo-wallet.now.sh/

What did you see instead?

The left side of the screen was blank:

GCAOGN...3WEQ6I

Copy Address
Copy Secret
XLM:
10000.0000000
Send

• Trust AssetUpdate AccountSign Out

Show Account Details

Did not display.

Hope that's helpful, spent some time trying to find a solution before submitting this.

Make configurable

This demo wallet was originally designed as if it was going to be a real wallet. It doesn't provide easy configuration menus that make life much easier for developers building Stellar services and using this application to test.

Furthermore, it is not possible to send a fellow dev a link that recreates the configuration state I had locally.

What we'll do:

• Provide a Config menu that updates the URL on change
• If not used, the demo wallet will present a prompt asking for the asset code and either the home domain or issuer address

Add Unit Tests

SEP-31 add support to select customer types

@quietbits commented on Tue Apr 20 2021

Currently, we are selecting the first customer type. We need to add a way for a user to select one from all available options. More details in this PR comment.

Deleted all the branches!

There were a bunch of branches that our Build Apps tutorial was pointing to.
Why were they removed and please add them back ASAP!!!

https://developers.stellar.org/docs/building-apps/

This repo isn't just a reference implementation, it was first and still is a tutorial resource.

Might be worth splitting it but until we've done that please keep the branches that the tutorial is pointing to.

cc:
@JakeUrban
@Zagan202
@lydiat