lightninglabs / lnc-web Goto Github PK

View Code? Open in Web Editor NEW

45.0 45.0 17.0 12.59 MB

Lightning Node Connect npm module for web

Home Page: https://docs.lightning.engineering/lightning-network-tools/lightning-terminal/lnc-npm

TypeScript 62.51% JavaScript 37.49%

bitcoin lightning-network typescript webassembly

lnc-web's People

Contributors

Stargazers

Watchers

Forkers

mdedys 22388o lostintime89 porticoexchange setlife-network adam2k arealayer bumi cawfree hannahmr arealayer kowalewskipawel qpc-github quantum-platinum-cloud kodylow secondl1ght

lnc-web's Issues

Update subscriptions to use snakeCase and decrease request arg conversions

I was attempting to use the closeChannel subscription function and ran into a couple issues. The first issue I fixed in #29 where the subscription calls were throwing an error. After getting it working, I ran into trouble using the closeChannel function. I initially used camelCase for the request fields. This kept throwing an error until I realized that the subscribe functions expect the request to have snake_case field names. I ended up having to use the code below to get it working:

  async closeChannel(chanPointString: string, isForceClose: boolean, satPerVbyte: number): Promise<void> {
    const [funding_txid_str, output_index] = chanPointString.split(':');
    const req = {
      channel_point: { funding_txid_str, output_index },
      force: isForceClose,
      sat_per_vbyte: satPerVbyte,
    };
    this._lnc.lnd.closeChannel(
      req,
      (channelEvent: any) => this.emit('channelClosed', channelEvent),
      (error: Error) => this.emit('transaction', {} as any, error),
    );
  }

This is inconsistent with the normal requests which take in camelCase field names. So I would recommend we switch these to camelCase as well.

I also noticed another quirk in the subscribe flow which can be improved. The current subscription methods accepts the request arg as a plain JS object. It then creates a new GRPC (ex: new LND.CloseChannelRequest()) object from the JS object and passes it along to this._wasm.subscribe(...). The subscribe function then converts the GRPC object back into a plain JS object and then to JSON to give to this.wasm.wasmClientInvokeRPC(). So the data converts like so: JS -> GRPC -> JS -> JSON.

We can simplify the subscription code by skipping the GRPC conversion and just pass along the request from the user to the this._wasm.subscribe(...) function without modification. This would eliminate a bunch of the parsing and conditionals in the subscription funcations such as closeChannel.

Expose session's macaroon and/or full permission list

In an effort to save people's feet from their own guns, we like to make sure they give us minimally permissible credentials to do what they want us to do.

The only API lnc-web exposes for permissions are hasPerms and isReadOnly. If we wanted to make sure a session only allows us to send offchain payments for instance, we'd need to make sure hasPerms returns false for every other possible permission the session could have.

Something like a listPermissions, or macaroon function even, would allow us to more efficiently/effectively do this check.

For reference, our lnd auto-withdrawals using the old fashioned non-TURNed configuration validate the macaroon by decoding it clientside and making sure the ops are strictly limited to either:

the ideal:

const INVOICABLE_MACAROON_OPS = [
  {
    entity: 'invoices',
    actions: [
      'read',
      'write'
    ]
  }
]

the prebaked invoice macaroon:

const INVOICE_MACAROON_OPS = [
  {
    entity: 'address',
    actions: [
      'read',
      'write'
    ]
  },
  {
    entity: 'invoices',
    actions: [
      'read',
      'write'
    ]
  },
  {
    entity: 'onchain',
    actions: [
      'read'
    ]
  }
]

Make connect timeout configurable (or something else)

The package currently waits a hardcoded second for the connection to succeed and when that times out it leaves the connection in an undetermined state. Increasing the timeout could give someone more certainty the connection actually failed.

This might be legacy code considering usage of WithBlock in lightning-node-connect's grpc.DialOptions is listed as a deprecated antipattern.

Anyway, it's hard to determine, as a consumer of connect, how to recover when the function reports a failure.

lnc-web/lib/lnc.ts

Lines 226 to 250 in f65cf92

 // repeatedly check if the connection was successful 

 return new Promise<void>((resolve, reject) => { 

 let counter = 0; 

 const interval = setInterval(() => { 

 counter++; 

 if (this.isConnected) { 

 clearInterval(interval); 

 resolve(); 

 log.info('The WASM client is connected to the server'); 

 // clear the in-memory credentials after connecting if the 

 // credentials are persisted in local storage 

 if (this.credentials.password) { 

 this.credentials.clear(true); 

 } 

 } else if (counter > 20) { 

 clearInterval(interval); 

 reject( 

 new Error( 

 'Failed to connect the WASM client to the proxy server' 

 ) 

 ); 

 } 

 }, 500); 

 });

Add function to clear all stored data

I had keys in localStorage that were no longer valid because I reset my litd regtest node. The connect call was failing even though I provided a new pairing phrase. Took me a minute to figure out that it was because the old keys were being loaded. I had to delete all of the stored state in order to connect. I would suggest we implement a way for users to clear the state in case the data is no longer valid due to changes on the litd side, or maybe they want to connect to a different litd node.

Migrate from using crypto-js to the native browser crypto API

Hello, I received a Critical Severity alert today from the crypto-js NPM package. I am sure you probably did as well, it stated that:

crypto-js PBKDF2 1,000 times weaker than specified in 1993 and 1.3M times weaker than current standard

I don't think lnc-web uses that algorithm but it is still concerning. So I checked out the repository for crypto-js and it seems that it is now deprecated. You can see the notice here: https://github.com/brix/crypto-js#discontinued

Active development of CryptoJS has been discontinued. This library is no longer maintained.

Nowadays, NodeJS and modern browsers have a native Crypto module. The latest version of CryptoJS already uses the native Crypto module for random number generation, since Math.random() is not crypto-safe. Further development of CryptoJS would result in it only being a wrapper of native Crypto. Therefore, development and maintenance has been discontinued, it is time to go for the native crypto module.

I think it would be a good idea for lnc-web to migrate away from this deprecated library ASAP. Even if the cryptography used by lnc-web from the crypto-js module is still considered secure, something as critical to security as this should be using the latest and greatest. The browser native crypto API is pretty good now so I don't think the migration should be too hard, but I haven't taken a full look at how everything works under the hood with lnc-web yet either.

https://developer.mozilla.org/en-US/docs/Web/API/Crypto

Please let me know your thoughts on this, thanks!

LNC gets stuck in an infinite loop if it cannot connect

Hi, Alby allows users to connect to their node through an LNC connector

However, we have some cases where the lightning terminal is not running or not reachable, therefore the connection can never succeed, and we are unable to stop lnc from running even after lnc.disconnect();

Ideally if lnc.disconnect is called() LNC should not repeatedly try to re-connect (especially if it couldn't connect in the first place)

If connect() fails (or lnc.isConnected() returns false), should we still call disconnect()?

This set of logs gets repeated endlessly:

index.js:2 2023-06-13 19:47:07.451 [DBG] MBOX: Client: receive mailbox initialized
index.js:2 2023-06-13 19:47:07.783 [DBG] MBOX: Client: got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}
index.js:2 2023-06-13 19:47:08.815 [DBG] MBOX: Client: Attempting to create send socket/stream
index.js:2 2023-06-13 19:47:09.660 [DBG] MBOX: Client: Connected to send socket/stream
index.js:2 2023-06-13 19:47:10.739 [DBG] MBOX: Client: receive mailbox initialized
index.js:2 2023-06-13 19:47:11.065 [DBG] MBOX: Client: got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}
index.js:2 2023-06-13 19:47:13.687 [DBG] MBOX: Client: got failure on send socket/stream, re-trying: failed to write: WebSocket closed: unclean connection close: status = StatusAbnormalClosure and reason = ""

TypeScript types package?

Hello,

Is there a TS types package that can be used to import LNC types into files?

Thanks

lnc typings: unable to resolve module error

I tried to use typing present in the package but module resolution fails for tests like jest and such

import {
  Invoice,
  Invoice_InvoiceState,
} from "@lightninglabs/lnc-core/dist/types/proto/lnd/lightning";

Cannot find module '@lightninglabs/lnc-core/dist/types/proto/lnd/lightning' from 'src/extension/background-script/connectors/lnc.ts'

Remove dist from repo and automate build on publish

Assess how/when we log to console

Package is being built in development environment

Hey folks, I am experimenting with lnc-web and ran into eval() issues with a web extension. I was running WASM in the wrong script but noticed this package isn't being built in production mode.

mode: process.env.NODE_ENV === 'production' ? 'production' : 'development',

This makes sense but you are not setting NODE_ENV anywhere in the CI pipeline which results in the mode being set to development. This mode results in the following: https://github.com/webpack/webpack/blob/c181294865dca01b28e6e316636fef5f2aad4eb6/lib/config/defaults.js#L155

devtool running in eval mode is not ideal and it is not recommended for production to use false. (https://webpack.js.org/configuration/devtool/#devtool)

Solution:
Change "prepare": "npm run build" --> "prepare": "NODE_ENV=production npm run build",

Can submit a PR unless I am missing something.

Property 'salt' has no initializer and is not definitely assigned in the constructor

I'm not sure why this just started happening to me now but I'm getting this weird TS error about the salt and testChipher fields not being initialized. I had to set the initial values to '' in order to successfully build the module.

ERROR in /Users/jamal/dev/lightninglabs/lnc/lib/index.ts
./lib/index.ts 100:4-8
[tsl] ERROR in /Users/jamal/dev/lightninglabs/lnc/lib/index.ts(100,5)
      TS2564: Property 'salt' has no initializer and is not definitely assigned in the constructor.

ERROR in /Users/jamal/dev/lightninglabs/lnc/lib/index.ts
./lib/index.ts 101:4-14
[tsl] ERROR in /Users/jamal/dev/lightninglabs/lnc/lib/index.ts(101,5)
      TS2564: Property 'testCipher' has no initializer and is not definitely assigned in the constructor.

ERROR in /Users/jamal/dev/lightninglabs/lnc/lib/index.ts
./lib/index.ts 133:68-72
[tsl] ERROR in /Users/jamal/dev/lightninglabs/lnc/lib/index.ts(133,69)
      TS2565: Property 'salt' is used before being assigned.

Fix CORS error on lightning.engineering CDN

When loading the WASM using the default URL of "", it will fail with the error:

16:32:22.625 index.js:2          Access to fetch at 'https://lightning.engineering/lnc-v0.1.10-alpha.wasm' from origin 'http://localhost:3030' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.
16:32:22.625 index.js:2          GET https://lightning.engineering/lnc-v0.1.10-alpha.wasm net::ERR_FAILED 200

We need to figure out how to modify the CORS config on the CloudFlare CDN to get this working.

Failed to connect the WASM client to the proxy server

Hi,

LNC seems to no longer be working: "Failed to connect the WASM client to the proxy server"

2024-05-23 17:01:01.049 [DBG] WASM: WASM client ready for connecting
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:01.604 [DBG] MBOX: (client) Dialing...
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:01.612 [DBG] MBOX: (client) New conn, read_stream=XXXX, write_stream=XXXX
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:01.612 [DBG] MBOX: (client) Attempting to create send socket/stream
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:02.572 [DBG] MBOX: (client) Connected to send socket/stream
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:04.973 [DBG] MBOX: (client) Receive mailbox initialized
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:05.275 [DBG] MBOX: (client) Got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:07.578 [DBG] MBOX: (client) Got failure on send socket/stream, re-trying: failed to write: WebSocket closed: unclean connection close: status = StatusAbnormalClosure and reason = ""
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:08.149 [DBG] MBOX: (client) Receive mailbox initialized
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:08.422 [DBG] MBOX: (client) Got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:09.580 [DBG] MBOX: (client) Attempting to create send socket/stream
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:10.467 [DBG] MBOX: (client) Connected to send socket/stream
Error: Failed to connect the WASM client to the proxy server
    at @lightninglabs_lnc-web.js?v=31fbb923:3932:229
Error: Failed to connect the WASM client to the proxy server
    at @lightninglabs_lnc-web.js?v=31fbb923:3932:229
connect
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:12.792 [DBG] MBOX: (client) Receive mailbox initialized
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:13.089 [DBG] MBOX: (client) Got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:16.102 [DBG] MBOX: (client) Receive mailbox initialized
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:16.409 [DBG] MBOX: (client) Got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:20.262 [DBG] MBOX: (client) Got failure on send socket/stream, re-trying: failed to write: WebSocket closed: unclean connection close: status = StatusAbnormalClosure and reason = ""
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:20.263 [DBG] MBOX: (client) Receive mailbox initialized
lnc-v0.3.1-alpha.wasm:0x20ddf8 2024-05-23 17:01:20.545 [DBG] MBOX: (client) Got failure on receive socket/stream, re-trying: {"code":2,"message":"stream not found","details":[]}

Document second handshake process in README

Need to come up with a digestible explanation for this in the README and perhaps for docs.lightning.engineering too

First connection requires a pairing phrase
Subsequent connections do not require pairing phrase because the keys will be fetched from storage
Password is always needed

cc @Liongrass

Permissions error on some methods

Hey ! Having issue with permissions ?

I did use an Admin session on LIT, some methods are working as intended (like lnc.lnd.lightning.sendPaymentSync) and other not like lnc.lnd.router.sendPaymentV2 or lnc.lnd.signer.signMessage

All of this on my dev setup, bitcoin is on regtest.

Framework: vue3@latest
Bundler: vite@latest
LNC version : 0.1.11-alpha.1
LND version 0.15.0-beta
LIT version 0.7.1-alpha

    await lnc.lnd.router.sendPaymentV2(
      { paymentRequest },
      (event) => console.log(event),
      (error) => console.error(error)
    )

Browser logs

2022-08-25 17:59:34.674 [INF] WASM: Calling 'routerrpc.Router.SendPaymentV2' on RPC with request {"paymentRequest":"lnbcrt1m1p3s08rxpp5p5ccyxfw86ws87cwvvwllq0uyqprvflq3drm3he3cl5lfe823gcsdqaf38zqntpwf4k2arnypzx2ur0wd5hgcqzpgxqzz6rzjqwyq6zjle9mq9myzr4lupcm75f3552qe7xygq6nk7hn57cmqy4w3gqqpjgqqqqgqqqqqqfcsqqqqqqgq9qsp5kjww4wahx6fcqq7qtqx0wwuguxd8n2t9h0g6gfxwvmlzs64cnmyq9qyyssqwem9mkkapvt8cvjwmeum4ee6utt60qvg4hfvqckue6zrmyzypqsnkwxadmysyrfpj4n5qdeau0gj7yarmmwrys84v066va00ldpc0gcqs7r356"} [index.js:2:928](/node_modules/.pnpm/registry.npmjs.org+@[email protected]/node_modules/@lightninglabs/lnc-web/dist/index.js)
Error: rpc error: code = Unknown desc = /routerrpc.Router/SendPaymentV2: unknown permissions required for method
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3428
    valueInvoke index.js:2
    _resume index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:295
    valueCall index.js:2
    _resume index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:295
    valueCall index.js:2
    _resume index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:295
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3384
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3297
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3306
    a2 index.js:2
    promise callback*s2 index.js:2
    a2 index.js:2
    promise callback*s2 index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3244
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3223
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3373
    login index.js:66
    loginWithLnc lightning-node-connect.vue:84
    1 lightning-node-connect.vue:12

Browser logs (lnc.lnd.signer.signMessage)

2022-08-25 18:07:27.999 [INF] WASM: Calling 'signrpc.Signer.SignMessage' on RPC with request {"msg":"dG90bw=="} [index.js:2:928](/node_modules/.pnpm/registry.npmjs.org+@[email protected]/node_modules/@lightninglabs/lnc-web/dist/index.js)
Error: rpc error: code = Unknown desc = /signrpc.Signer/SignMessage: unknown permissions required for method
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3415
    valueInvoke index.js:2
    _resume index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:295
    valueCall index.js:2
    _resume index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:295
    valueCall index.js:2
    _resume index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:295
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3384
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3297
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3306
    a2 index.js:2
    promise callback*s2 index.js:2
    a2 index.js:2
    promise callback*s2 index.js:2
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3244
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3223
    ../../node_modules/.pnpm/registry.npmjs.org+ @lightninglabs_lnc-web.js:3373
    login index.js:66
    loginWithLnc lightning-node-connect.vue:84
    1 lightning-node-connect.vue:12
)

Is it possible to use lnc-web inside a Service Worker?

My use-case would be to use subscribeInvoices inside the worker to show Notifications to the user when they receive a new invoice. I have read that placing Notification functionality inside the Service Worker might be good so that the Notifications are shown even when the web app is not visible.

Make disconnect async

wasmClientDisconnect takes a function that's called when the disconnect has concluded, but lnc-web doesn't use it.

As a result, consumers end up needing to do something like this:

          lnc.disconnect()
          logger.info('disconnecting after:', `payment_hash=${hash}`)
          // wait for lnc to disconnect before releasing the mutex
          await new Promise((resolve, reject) => {
            let counter = 0
            const interval = setInterval(() => {
              if (lnc.isConnected) {
                if (counter++ > 100) {
                  logger.error('failed to disconnect from lnc')
                  clearInterval(interval)
                  reject(new Error('failed to disconnect from lnc'))
                }
                return
              }
              clearInterval(interval)
              resolve()
            })
          }, 50)

Happy to create a PR myself to the effect of

async disconnect() {
        return await new Promise(resolve => this.wasm.wasmClientDisconnect(resolve);
}

... if it makes sense

Error when calling connect after calling run

If you call lnc.run() first then call lnc.connct(), the following error will be displayed in the console:

10:26:52.606 index.js:2 wasm [info] downloaded WASM file +0ms
10:26:52.625 index.js:2 2022-06-13 10:26:52.624 [DBG] WASM: WASM client ready for connecting
10:26:55.648 index.js:2 panic: JavaScript error: undefined is not a constructor [recovered]
10:26:55.648 index.js:2 	panic: JavaScript error: undefined is not a constructor
10:26:55.648 index.js:2 
10:26:55.648 index.js:2 goroutine 9 [running]:
10:26:55.649 index.js:2 syscall/js.Value.New({{}, 0x7ff800040000000c, 0x183a038}, {0x189d6e0, 0x1, 0x1})
10:26:55.649 index.js:2 	syscall/js/js.go:438 +0xe
10:26:55.649 index.js:2 syscall.Write(0x1, {0x1b215c0, 0x40, 0x40})
10:26:55.649 index.js:2 	syscall/fs_js.go:420 +0x8
10:26:55.650 index.js:2 internal/poll.ignoringEINTRIO(...)
10:26:55.650 index.js:2 	internal/poll/fd_unix.go:582
10:26:55.650 index.js:2 internal/poll.(*FD).Write(0x1838120, {0x1b215c0, 0x40, 0x40})
10:26:55.650 index.js:2 	internal/poll/fd_unix.go:275 +0x4e
10:26:55.650 index.js:2 os.(*File).write(...)
10:26:55.650 index.js:2 	os/file_posix.go:49
10:26:55.651 index.js:2 os.(*File).Write(0x180c020, {0x1b215c0, 0x40, 0x40})
10:26:55.651 index.js:2 	os/file.go:176 +0x10
10:26:55.651 index.js:2 fmt.Fprintf({0x593b60, 0x180c020}, {0x365fa8, 0x12}, {0x1855900, 0x1, 0x1})
10:26:55.651 index.js:2 	fmt/print.go:205 +0x8
10:26:55.651 index.js:2 fmt.Printf(...)
10:26:55.651 index.js:2 	fmt/print.go:213
10:26:55.651 index.js:2 main.main.func1()
10:26:55.652 index.js:2 	github.com/lightninglabs/lightning-node-connect/cmd/wasm-client/main.go:62 +0x6
10:26:55.652 index.js:2 panic({0x32e320, 0x1bd2880})
10:26:55.652 index.js:2 	runtime/panic.go:1038 +0x29
10:26:55.652 index.js:2 syscall/js.Value.New({{}, 0x7ff800040000000c, 0x183a038}, {0x1855be8, 0x1, 0x1})
10:26:55.652 index.js:2 	syscall/js/js.go:438 +0xe
10:26:55.652 index.js:2 syscall.Write(0x1, {0x18604e0, 0x35, 0x60})
10:26:55.652 index.js:2 	syscall/fs_js.go:420 +0x8
10:26:55.653 index.js:2 internal/poll.ignoringEINTRIO(...)
10:26:55.653 index.js:2 	internal/poll/fd_unix.go:582
10:26:55.653 index.js:2 internal/poll.(*FD).Write(0x1838120, {0x18604e0, 0x35, 0x60})
10:26:55.653 index.js:2 	internal/poll/fd_unix.go:275 +0x4e
10:26:55.654 index.js:2 os.(*File).write(...)
10:26:55.654 index.js:2 	os/file_posix.go:49
10:26:55.654 index.js:2 os.(*File).Write(0x180c020, {0x18604e0, 0x35, 0x60})
10:26:55.654 index.js:2 	os/file.go:176 +0x10
10:26:55.654 index.js:2 fmt.Fprintf({0x593b60, 0x180c020}, {0x3774c6, 0x1e}, {0x1855e08, 0x1, 0x1})
10:26:55.654 index.js:2 	fmt/print.go:205 +0x8
10:26:55.654 index.js:2 fmt.Printf(...)
10:26:55.655 index.js:2 	fmt/print.go:213
10:26:55.655 index.js:2 main.exit({0x58c960, 0x1bd2860})
10:26:55.655 index.js:2 	github.com/lightninglabs/lightning-node-connect/cmd/wasm-client/main.go:388 +0x7
10:26:55.655 index.js:2 main.main()
10:26:55.655 index.js:2 	github.com/lightninglabs/lightning-node-connect/cmd/wasm-client/main.go:83 +0x1a

It looks like we call run again in connect. We should check if the WASM has been run already before calling again.

[lnc-web] Store pairing phrase in local storage for backwards compatibility

LNC Presentation for Hackathon

Putting together a presentation for the Bolt.fun hackathon on why LNC is useful and how to use it.

On methods that return a stream - `onError` throws an error when the stream ends

I discovered this when using the sendPaymentV2 method. I use the onMessage and onError streams that are returned. When the stream ends (the payment being sent has the 'SUCCEEDED' status), onError throws an error called EOF. I am assuming this means 'End-of-file' https://en.wikipedia.org/wiki/End-of-file.

I am able to escape this by checking for if (error.message === 'EOF') but it would be nice if this didn't happen. I don't think a stream being terminated should be treated as an error.

In situations where you want to alert the user of an error ex. with an Alert or Toast, you will always have to escape this normal ending of stream condition.

I have only tested this with sendPaymentV2 so it may only be an issue with this method, but I am guessing it may affect other ones as well.

Better error handling when loaded in server

In frameworks like NextJS, components are server side rendered by default unless specified. This causes issues with this lib and causes it to throw a self is not defined error which isn't very informative of why it's failing.

It would be nice if this scenario could be handled internally in the lib and return an accurate error of the reason for failing.

Multiple ways to subscribe to streaming RPCs

I just had a realization about how the streaming RPC calls are implemented, which I think should be improved. In the current code, there are two ways implemented to subscribe to events through lnc-web:

Call the streaming RPC directly via swapClient.monitor(req, callback, errCallback)
Call loop.connectStreams() to subscribe followed by loop.on('status', callback) to provide the callback

Do you think we should remove one of these way to subscribe since it's a bit redundant and may cause confusion for users?

My suggestion would be to remove the second method because we would need to subscribe to all streams available when calling connectStreams. This is not a big issue for Loop which only has one streaming RPC. But for LND, there are many. Currently in LndApi.connectStreams, we only subscribe to three RPCs, but this makes it impossible for the user to receive subscribeChannelBackups events using this method. In order to make this possible, we would need to subscribe to all LND streaming RPCs when connectStreams is called. This would make the browser receive all of the events, even the ones that the user has no interest in. Another downside to this approach is that you cannot subscribe to the one-off streaming RPCs like closeChannel and subscribeSingleInvoice via connectStreams because they require parameters to be supplied.

What do you think about how to handle these subscriptions?

	// repeatedly check if the connection was successful
	return new Promise<void>((resolve, reject) => {
	let counter = 0;
	const interval = setInterval(() => {
	counter++;
	if (this.isConnected) {
	clearInterval(interval);
	resolve();
	log.info('The WASM client is connected to the server');

	// clear the in-memory credentials after connecting if the
	// credentials are persisted in local storage
	if (this.credentials.password) {
	this.credentials.clear(true);
	}
	} else if (counter > 20) {
	clearInterval(interval);
	reject(
	new Error(
	'Failed to connect the WASM client to the proxy server'
	)
	);
	}
	}, 500);
	});