DEV Community: Aniket Ambore

Tutorial: How to Develop a Nostr Wallet Connect Mobile App Using Flutter and NWC

Aniket Ambore — Sun, 23 Jun 2024 11:30:22 +0000

Hello everyone! My name is Aniket (aka Anipy) and in this tutorial, I'm going to show you how to develop a Nostr Wallet Connect mobile app using Flutter and the NWC Dart package. Before we dive into the tutorial, it's important to familiarize yourself with the NIP47 protocol to better understand Nostr Wallet Connect.

In brief, Nostr Wallet Connect (NWC) is a protocol that allows applications to access a remote Lightning wallet. Imagine you’ve developed a simple multiplayer game like tic-tac-toe. Your game works great, but you want to add real-world rewards using satoshis (sats). One way to achieve this is by using Nostr Wallet Connect.

With NWC, users can connect their remote Lightning wallets to your app. Now, your tic-tac-toe game can interact with these wallets. Once the connection is established, your game can request payments from the user’s Lightning wallet.

Here’s a practical example: before starting a game, both players agree that the loser will pay an LN invoice to the winner. At the end of the game, your app will automatically create an LN invoice for the winner’s connected wallet and pay it from the loser’s connected wallet. This rewarding mechanism is made possible by NWC.

NWC allows users to connect their remote Lightning wallets to your app easily, ensuring their wallets are available when needed. If a user ever wants to disable this connection, they can simply disconnect it.

Let's get started on building this exciting functionality into your Flutter app!

Getting Started

Before we dive into coding, let's start by grabbing the "starter" project for this tutorial. Open your terminal and run the following command:

git clone -b starter --single-branch https://github.com/aniketambore/nostr_pay

This command will clone the starter project, saving you time and allowing you to focus on the exciting parts of this tutorial.

Feeling the excitement? Great! Now, fire up your favorite code editor, whether it’s VS Code or Android Studio.

You may see some errors in the starter project initially. To fix this, head over to the pubspec.yaml file and locate the # TODO: Add NWC package here comment. Replace it with the following:

dependencies:
  nwc: ^1.0.1

Next, run flutter pub get to set things up, and then launch the app. At this stage, it’s a straightforward UI project, but we’ll soon infuse it with some Nostr Wallet Connect magic.

Project Files

The starter project includes several files to help you out. Let’s take a brief tour of these files to understand their purpose before we dive into developing the Nostr Wallet Connect functionality.

Assets folder

Inside the assets directory, you'll find icons, images, and lottie files that will be used to build this app.

Folder structure

In the lib directory, you'll notice various folders, each serving a specific purpose:

State Management (BLoC)

In lib/bloc, you'll find files for state and credentials management. We’ll discuss these further in the article.

Component Library Folder

The lib/component_library contains all the reusable UI components that might be used across different screens.

Handlers

The lib/handlers directory currently contains the PaymentResultHandler, which listens to a stream and performs navigation actions based on the received payment results.

Models

In lib/models, you’ll find the model objects used in our app, defining how data is structured and managed.

Routes

The lib/routes directory contains all the screens and dialogs displayed in the app.

Services

The lib/services directory includes services like:

Device: Provides methods to copy text to the clipboard and share text using the device's functionality.
Keychain: Provides methods to securely store, retrieve, and delete key-value pairs in secure storage.

App Libraries

The starter project comes with a set of useful libraries listed in pubspec.yaml:

dependencies:
  nwc: ^1.0.1
  flutter_bloc: ^8.1.5
  flutter_secure_storage: ^4.2.1
  flutter_svg: ^2.0.10+1
  hydrated_bloc: ^9.1.5
  connectivity_plus: ^6.0.3
  path: ^1.9.0
  path_provider: ^2.1.3
  rxdart: ^0.27.7
  flutter_fgbg: ^0.3.0
  intl: ^0.19.0
  qr_flutter: ^4.1.0
  share_plus: ^9.0.0
  toastification: ^2.0.0
  bolt11_decoder: ^1.0.2
  auto_size_text: ^3.0.0
  lottie: ^3.1.2
  flutter:
    sdk: flutter

Here's what they help you to do:

nwc: Simplifies the integration of Nostr Wallet Connect by providing methods for handling NWC-related functionalities.
flutter_bloc: Implements the BLoC (Business Logic Component) design pattern for state management, separating presentation and business logic.
flutter_secure_storage: Securely stores key-value pairs, useful for sensitive data.
flutter_svg: Renders SVG images.
hydrated_bloc: Enhances flutter_bloc by persisting state to disk and restoring it.
connectivity_plus: Checks network connectivity status.
path: Provides utilities for working with file and directory paths.
path_provider: Helps access the file system path on the device.
rxdart: Extends Dart's Streams with reactive programming.
flutter_fgbg: Detects when the app moves between the foreground and background.
intl: Supports internationalization and localization.
qr_flutter: Generates QR codes.
share_plus: Provides functionality for sharing content.
toastification: Shows customizable toast notifications.
bolt11_decoder: Decodes Bolt11 payment invoices used in the Lightning Network.
auto_size_text: Automatically resizes text to fit within its bounds.
lottie: Renders lottie animations.

NWC Initialization

Let's start with initializing the NWC class. Open the main.dart file and locate // TODO: Import nwc package. Replace it with:

import 'package:nwc/nwc.dart';

Next, find // TODO: Initialize Nostr Wallet Connect class and replace it along with the nwc variable with:

final nwc = NWC();

Now, open the lib/bloc/nwc_account/nwc_account_cubit.dart file, import the NWC package, and locate // TODO: Instance of the Nostr Wallet Connect class. Replace it and the _nwc variable with:

final NWC _nwc;

Next, locate // TODO: Change balance controller and stream type to Get_Balance_Result and replace it and the _walletBalanceController and walletBalanceStream variables with:

final BehaviorSubject<Get_Balance_Result?> _walletBalanceController = BehaviorSubject<Get_Balance_Result?>();

Stream<Get_Balance_Result?> get walletBalanceStream => _walletBalanceController.stream;

Monitoring Changes

We initialized the wallet balance controller and stream types in the previous step. Now, let's use the walletBalanceStream to monitor changes in the wallet balance by working on the _watchAccountChanges() method.

Locate // TODO: Update the types to match the actual data type and replace it with:

return Rx.combineLatest<Get_Balance_Result?, NWCAccountState>([walletBalanceStream], (values) {
  ...

In the above code:

Rx.combineLatest: Emits the latest values from the walletBalanceStream whenever it emits a new value.

Next, locate // TODO: Check if wallet balance result is not null and replace it with:

if (values.first != null) {
  // TODO: Assemble and return a new NWCAccountState based on the latest balance result
}

In the above code:

values: Holds the latest values from the combined streams, where values.first corresponds to the latest value from walletBalanceStream.
We're checking if the first value (representing the latest balance result) is not null.

Now, update the state by locating // TODO: Assemble and return a new NWCAccountState based on the latest balance result and replacing it with:

return assembleNWCAccountState(
  values.first!.balance,
  values.first!.maxAmount ?? 0,
  state,
) ?? state;

In the above code:

assembleNWCAccountState: A helper function (located in lib/bloc/nwc_account/nwc_account_state.dart) that constructs a new NWCAccountState object using the provided balance, maxAmount, and the current state.

With this, we have completed the _watchAccountChanges method, which combines the latest values from the walletBalanceStream to monitor changes in the wallet balance. When the balance changes, it constructs a new state using assembleNWCAccountState and emits this new state. If the balance is null or no change occurs, it returns the current state, ensuring the app’s state is always up-to-date with the latest balance information.

Inside the Constructor

The NWCAccountCubit constructor initializes the state, sets up listeners, and performs initial actions. Let's work on that in this section.

Locate // TODO: Listen to account changes and emit updated state and replace it with:

// 1
_watchAccountChanges().listen((acc) {
  debugPrint('State changed: $acc');
  // 2
  emit(acc);
});

In the above code:

_watchAccountChanges().listen((acc) {...}): Sets up a listener for the stream returned by _watchAccountChanges(). Whenever a new state (acc) is emitted by the stream, the callback is executed.
emit(acc);: Emits the new state, updating the state of the Cubit.

Next, locate // TODO: Disable unnecessary logs from the logger utils and replace it with:

_nwc.loggerUtils.disableLogs();

Here, we’re disabling logging from the NWC utility to reduce log noise in the production environment, although you can keep it if desired.

Next, locate // TODO: Connect if the current state type is not none and replace it with:

if (state.type != NWCConnectTypes.none) connect();

Here, we check if a NWC wallet is already initialized. If it is, we connect to it; otherwise, we do not.

Connect

Until now, we haven't talked much about NWC, focusing instead on streams and listeners. Let's now discuss the connect method. First, look at the parameters:

Future connect({
  String? connectionURI,
  bool restored = false,
  NWCConnectTypes? type,
}) async {
  ....
}

connectionURI: A string representing the URI used to establish the connection between the remote lightning wallet and our app.
restored: A boolean flag indicating whether the connection is being restored.
type: An optional parameter of type NWCConnectTypes (an enum) specifying the type of connection. It has three values: none, nwc, and alby.
- none: No wallet is connected to the app.
- nwc: A wallet is connected, where the user manually copies and pastes the connection URI from the remote lightning wallet into the app.
- alby: The Alby wallet is connected. (This article does not cover the Alby wallet connection.)

Now, locate // TODO: Parse the Nostr Connect URI and replace it with:

final parsedUri = _nwc.nip47.parseNostrConnectUri(connectionURI);

This uses the parseNostrConnectUri(connectionURI) method to parse the connection URI entered by the user, extracting components such as secret, pubkey, relay, and lud16. We will discuss connectionURI more in the following sections.

Next, locate // TODO: Derive the public key from the parsed URI secret and replace it with:

final myPubkey = _nwc.keysService.derivePublicKey(privateKey: parsedUri.secret);

Here, we use the derivePublicKey(privateKey: parsedUri.secret) method to derive the public key (myPubkey) from the parsed secret (parsedUri.secret).

Next, locate // TODO: Store the secret using the credentials manager and replace it with:

await _credentialsManager.storeSecret(secret: parsedUri.secret);

This uses the _credentialsManager.storeSecret(secret: parsedUri.secret) method to securely store the parsed secret (private key) using the credentials manager (_credentialsManager).

Next, locate // TODO: Emit the new state with the updated properties and replace it with:

emit(state.copyWith(
  type: type,
  walletPubkey: parsedUri.pubkey,
  myPubkey: myPubkey,
  relay: parsedUri.relay,
  lud16: parsedUri.lud16,
));

This emits a new state using emit(state.copyWith(...)), updating the type, walletPubkey, myPubkey, relay, and lud16 based on the parsed URI components.

So the connect method parses the URI to extract necessary parameters, derives the public key from the secret, securely stores the secret, updates the state with connection details, and initialize the connection to enable ongoing communication and synchronization.

Initializing Relay and Handling Events

Let's move on to the _initializeConnection() method. First, locate // TODO: Initialize the relays service with the relay URL and replace it with:

await _nwc.relaysService.init(relaysUrl: [state.relay]);

This initializes the relaysService provided by _nwc with the relay URL obtained from the current state, preparing the NWC to communicate with the specified relay.

Next, locate // TODO: Create a subscription filter for events and replace it with:

final subToFilter = Request(
  filters: [
    Filter(
      kinds: const [23195],
      authors: [state.walletPubkey],
      since: DateTime.now(),
    )
  ],
);

This creates a request object with a filter specifying the types of events (kinds) and authors (authors) to subscribe to. It filters events of kind 23195, the response event kind in the protocol, authored by the current wallet public key (state.walletPubkey).

Next, locate // TODO: Start the events subscription using the relays service and replace it with:

final nostrStream = _nwc.relaysService.startEventsSubscription(
  request: subToFilter,
  onEose: (relay, eose) =>
    debugPrint('subscriptionId: ${eose.subscriptionId}, relay: $relay'),
);

This initiates a subscription (startEventsSubscription) to the Nostr relay service (_nwc.relaysService) based on the defined filter request. It listens for specific events matching the filter criteria (Filter).

Next, locate // TODO: Restore the secret from the credentials manager and replace it with:

final secret = await _credentialsManager.restoreSecret();

This restores the secret (private key) associated with the wallet from the credentials manager. This secret is necessary for decrypting incoming event content.

Next, locate // TODO: Listen to the nostr stream for events and replace it with:

nostrStream.stream.listen((Event event) {
  // TODO: Event handling logic
});

This sets up a listener on the nostrStream.stream to listen for incoming events (Event objects) from the Nostr relay service. It executes the provided callback whenever a new event is received.

Next, replace // TODO: Event handling logic with:

// 1
if (event.kind == 23195 && event.content != null) {
  // 2
  final decryptedContent = _nwc.nip04.decrypt(
    secret,
    state.walletPubkey,
    event.content!,
  );

  // 3
  final content = _nwc.nip47.parseResponseResult(decryptedContent);

  // 4
  if (content.resultType == NWCResultType.get_balance) {
    // TODO: Handle get_balance result
  } else if (content.resultType == NWCResultType.make_invoice) {
    // TODO: Handle make_invoice result
  } else if (content.resultType == NWCResultType.pay_invoice) {
    // TODO: Handle pay_invoice result
  } else if (content.resultType == NWCResultType.lookup_invoice) {
    // TODO: Handle lookup_invoice result
  } else if (content.resultType == NWCResultType.error) {
    // TODO: Handle error result
  }
}

In this code:

We first check if the event that we received has the kind equal to 23195 (the response event kind) and ensure the content is not null.
As defined in Nip47, the content of requests and responses is encrypted with NIP04. Therefore, we decrypt the content of the incoming event with the retrieved secret and the wallet public key.
We parse the decrypted content to determine the type of result (NWCResultType) contained in the event.
Finally, we handle different types of results (get_balance, make_invoice, pay_invoice, lookup_invoice, error) and update the state accordingly.

Up to this point, we have set up subscriptions to receive specific events, decrypt incoming event content, handle different types of results (such as balance updates, invoice creation or payment, lookup results, and errors), and update the app state accordingly. We will cover event handling in the following section.

Publishing Events to Relays

We'll now work on the _sentToRelay method, which is responsible for encrypting a given message, creating an event, and sending it to the Nostr relay. Let's break down each part of this method.

First, locate // TODO: Restore the secret from the credentials manager and replace it with:

final secret = await _credentialsManager.restoreSecret();

We've covered this in previous sections, so you already understand its purpose.

Next, locate // TODO: Encrypt the message using NIP04 and replace it with:

final content = _nwc.nip04.encrypt(
  secret,
  state.walletPubkey,
  jsonEncode(message),
);

This encrypts the message content using the NIP04 encryption method provided. It uses the retrieved secret (private key) and the wallet public key to encrypt the JSON-encoded message.

Next, locate // TODO: Create an event request with the encrypted content and replace it with:

final request = Event.fromPartialData(
  kind: 23194,
  content: content,
  tags: [
    ['p', state.walletPubkey]
  ],
  createdAt: DateTime.now(),
  keyPairs: KeyPairs(private: secret),
);

This constructs an Event object (request) using the encrypted content. It assigns a kind (23194 for a request, as defined in the NIP47 protocol), attaches tags (like ['p', state.walletPubkey]), specifies the creation time (DateTime.now()), and includes the KeyPairs for encryption (with the private key).

Finally, locate // TODO: Send the event to relays with a timeout and replace it with:

await _nwc.relaysService.sendEventToRelays(
  request,
  timeout: const Duration(seconds: 3),
);

This sends the constructed request (Event object) to the Nostr relays.

So the _sentToRelay method encapsulates the process of encrypting a message, constructing an Event request object with encrypted content, and sending it to the Nostr relays through the NWC. This functionality is crucial for interacting securely with the Nostr network, facilitating actions like making payments, creating invoices, and receiving updates, while maintaining the privacy and integrity of the transmitted data.

Connecting a Lightning Wallet

Let's run the project and connect a Lightning wallet. After the splash screen, you'll see a screen where the user needs to paste the connection URI of the Lightning wallet. This screen is located in lib/routes/initial_walkthrough/initial_walkthrough_page.dart. Open it and follow these steps:

Locate // TODO: Access NWCAccountCubit instance from context and replace it with:

final cubit = context.read<NWCAccountCubit>();

This retrieves the NWCAccountCubit instance using context.read.

Next, locate // TODO: Call the connect method on NWCAccountCubit and replace it with:

await cubit.connect(
  connectionURI: connectionURI,
  type: NWCConnectTypes.nwc,
);

Here, we're calling cubit.connect to initiate the connection process to the user's remote Lightning wallet using the provided connectionURI and passing the type as NWCConnectTypes.nwc.

Finally, locate // TODO: Replace the current route with the home screen and replace it with:

navigator.pushReplacementNamed('/');

If the connection is successful (no exceptions thrown), it navigates to the '/' route, typically replacing the current route with a new one, which is the home page.

Obtaining the Connection URI

To get the connection URI, use Lightning wallets that support NWC, such as Mutiny and Alby. For this article, we'll use Alby.

Go to NWC by Alby.
Log in with your Alby account.
Click on "Connect app" and enter "NWC Test" as the name (you can use any name).
Optionally, set a "Monthly budget"; we'll keep it at 100k sats.

5.Click "Next" and then "Copy pairing secret".

The connection URI will look something like this:

nostr+walletconnect://69effe7b49a6dd5cf525bd0905917a5005ffe480b58eeb8e861418cf3ae760d9?relay=wss://relay.getalby.com/v1&secret=f488038d4e52a63e8e6f29a0be46e683c4e08b7550c2d76be9712b7da149a05a&lud16=aniketamborebitcoindev@getalby.com

Understanding the Connection URI

The connection URI generated by the wallet service consists of the following components:

Protocol: The URI begins with nostr+walletconnect://, indicating the use of the Nostr Wallet Connect protocol.
Base Path (Hex-encoded Pubkey): This uniquely identifies the user's wallet within the protocol. It's crucial for establishing a secure connection.
Query String Parameters:
- relay: This parameter is required and specifies the URL of the relay where the wallet service is connected and will listen for events. Multiple relays can be listed.
- secret: Also required, this is a randomly generated 32-byte hex encoded string. It's used by the client to sign events and encrypt payloads when communicating with the wallet service.
- lud16: While optional, it's recommended as a Lightning address that clients can use to automatically set up the lud16 field.

To proceed, let's hot restart your app. Paste the connection URI into the input field and click "Connect".

After connecting, you may notice your balance displayed as 0 sats on the home page, as we haven't yet retrieved it from the wallet. Let's move on to retrieving the balance in the next step.

Command: get_balance

To get the correct balance of the wallet, go to lib/bloc/nwc_account/nwc_account_cubit.dart. Locate // TODO: Define a message to request balance and replace it with:

final balanceMessage = {"method": "get_balance"};

This is one of the wallet commands defined in NIP47 for getting the current balance of the user's wallet.

Next, locate // TODO: Call the _sentToRelay function to send the balance message and replace it with:

await _sentToRelay(balanceMessage);

Here, we're calling the _sentToRelay method with balanceMessage as the parameter.

We are now publishing a request event to the relay with the command get_balance. When our wallet service receives this event, it will publish the result or response for us. To handle this, locate // TODO: Handle get_balance result inside the _initializeConnection() method and replace it with:

if (content.resultType == NWCResultType.get_balance) {
  final balanceResult = content.result as Get_Balance_Result;
  _walletBalanceController.add(balanceResult);
  debugPrint('balance: ${balanceResult.balance}');
}

In the above:

When the resultType is get_balance, it casts content.result to Get_Balance_Result.
It then adds balanceResult to _walletBalanceController, which is used to stream wallet balance changes.

Now, simply hot restart the application, and you will see the current balance of your Lightning wallet on the home screen.

Formatting and Refreshing

Let's format the balance shown on the home screen and add a method to refresh it. Go to lib/routes/home/home_page.dart. Locate // TODO: Read NWCAccountCubit instance from context and replace it with:

final accountCubit = context.read<NWCAccountCubit>();

Next, locate // TODO: Call the refresh method on accountCubit to refresh data and replace it with:

await accountCubit.refresh();

The refresh() method simply calls the sync method inside NWCAccountCubit.

Next, locate // TODO: Format the balance using the formatBalance method on accountCubit and replace it with:

'${accountCubit.formatBalance(state.balance)} sats',

This method formats the balance.

Now, hot reload the app, and you will see the changes made to the balance on the home screen. You can also pull to refresh the balance of the wallet.

Next, we'll implement the make_invoice functionality.

Command: make_invoice

Let's head over to lib/bloc/nwc_account/nwc_account_cubit.dart and take a look at the makeInvoice method which is responsible for creating a new invoice. It takes an amount in satoshis and an optional description as parameters.

Locate // TODO: Construct the request object for making an invoice and replace it with:

final req = {
  "method": "make_invoice",
  "params": {
    "amount": amountInSats * 1000, // value in msats
    "description": desc, // invoice's description, optional
  }
};

Here, req constructs the make_invoice command defined in NIP47:

amount: The amount in millisatoshis (msats). It converts the provided amount in satoshis to msats by multiplying by 1000.
description: Optional description for the invoice.

Next, locate // TODO: Send the request to the relay using _sentToRelay and replace it with:

await _sentToRelay(req);

This sends the constructed request to the relays using the _sentToRelay method.

Now, locate // TODO: Handle make_invoice result inside the _initializeConnection() method and replace it with:

else if (content.resultType == NWCResultType.make_invoice) {
  final invoiceResult = content.result as Make_Invoice_Result;
  debugPrint('invoice: ${invoiceResult.invoice}');
  emit(
    state.copyWith(
      resultType: NWCResultType.make_invoice,
      makeInvoiceResult: invoiceResult,
    ),
  );
}

Here:

When resultType is make_invoice, it casts content.result to Make_Invoice_Result.
It emits a new state with makeInvoiceResult to notify listeners about the newly created invoice.

Now, head over to lib/routes/create_invoice/create_invoice_page.dart and look at the _createInvoice() method, responsible for initiating the invoice creation process in NWCAccountCubit.

Locate // TODO: Access NWCAccountCubit instance from context and replace it with:

final cubit = context.read<NWCAccountCubit>();

This retrieves the NWCAccountCubit instance.

Next, locate // TODO: Call the makeInvoice method on NWCAccountCubit and replace it with:

await cubit.makeInvoice(
  amountInSats: int.parse(_amountController.text),
  description: _descriptionController.text,
);

Here, makeInvoice is called on the cubit with the parsed amount and description from user inputs.

In the CreateInvoicePage, when the user clicks on "Create Invoice" and supplies the amount and description, the makeInvoice method is invoked. The response handling is done through a listener.

Now, let's move on to handling the response and errors.

Listener in `create_invoice_page.dart`

The listener reacts to state changes in NWCAccountCubit, specifically handling the results of making an invoice or encountering an error.

Locate // TODO: Handle the case when the result type is 'make_invoice' and the makeInvoiceResult is not null and replace it with:

// 1
if (resultType != null &&
    resultType == NWCResultType.make_invoice &&
    state.makeInvoiceResult != null) {
  // 2
  final navigator = Navigator.of(context);
  navigator.popUntil((route) => route.settings.name == "/");

  // 3
  // Navigate to InvoiceQrPage with the makeInvoiceResult.
  navigator.push(
    MaterialPageRoute(
      builder: (context) => InvoiceQrPage(
        makeInvoiceResult: state.makeInvoiceResult!,
      ),
    ),
  );
}

In the above code:

It checks if resultType is make_invoice and makeInvoiceResult is not null.
If conditions are met, it pops routes until the root ("/") route (home screen).
Then, it pushes a new route to display InvoiceQrPage, passing makeInvoiceResult to it.

Next, locate // TODO: Handle the case when the result type is 'error' and the nwcErrorResponse is not null and replace it with:

// 1
else if (resultType == NWCResultType.error &&
    state.nwcErrorResponse != null) {
  // 2
  final errorMessage = state.nwcErrorResponse!.errorMessage;
  // 3
  showToast(
    context,
    title: errorMessage,
    type: ToastificationType.error,
  );
}

Here:

It checks if resultType is error and nwcErrorResponse is not null.
If conditions are met, it extracts the error message from nwcErrorResponse.
Displays the error message as a toast notification using showToast.

Handling Errors in `NWCAccountCubit`

We need to handle error results in NWCAccountCubit. Head over to lib/bloc/nwc_account/nwc_account_cubit.dart and locate // TODO: Handle error result and replace it with:

else if (content.resultType == NWCResultType.error) {
  final error = content.result as NWC_Error_Result;
  debugPrint('error message: ${error.errorMessage}');
  emit(
    state.copyWith(
      resultType: NWCResultType.error,
      nwcErrorResponse: error,
    ),
  );
}

Here:

When resultType is error, it casts content.result to NWC_Error_Result.
Emits a new state with nwcErrorResponse to notify listeners about the encountered error.

Now, hot restart the app. On the home page, click on "Receive", enter the amount and description, and click "Create Invoice".

After the invoice is generated, you will see the InvoiceQrPage.

Currently, if someone pays this invoice, nothing happens. To handle this, we'll look into the lookup_invoice command next.

Command: lookup_invoice

Let's head back to lib/bloc/nwc_account/nwc_account_cubit.dart and look at the lookupInvoice method responsible for sending a request to check the status of a specific invoice.

Locate // TODO: Construct the message to lookup the invoice and replace it with:

final message = {
  "method": "lookup_invoice",
  "params": {
    "invoice": invoice,
  }
};

Here, message constructs the lookup_invoice command as defined in NIP47:

The params key contains a map with the invoice to be looked up.

Next, locate // TODO: Send the lookup request to the relay using _sentToRelay and replace it with:

await _sentToRelay(message);

This sends the constructed request to the relays using the _sentToRelay method.

Now, locate // TODO: Handle lookup_invoice result inside the _initializeConnection() method and replace it with:

else if (content.resultType == NWCResultType.lookup_invoice) {
  // 1
  final result = content.result as Lookup_Invoice_Result;

  // 2
  emit(
    state.copyWith(
      resultType: NWCResultType.lookup_invoice,
      lookupInvoiceResult: result,
    ),
  );
}

Here:

When resultType is lookup_invoice, it casts content.result to Lookup_Invoice_Result.
Emits a new state with updated lookupInvoiceResult to notify listeners about the invoice status.

Next, head over to lib/routes/invoice_qr/invoice_qr_page.dart. This page displays a QR code for the generated invoice and periodically checks if the invoice has been paid.

Inside `_startPolling()` method

Locate // TODO: Access NWCAccountCubit instance from context and replace it with:

final cubit = context.read<NWCAccountCubit>();

This retrieves the NWCAccountCubit instance.

Next, locate // TODO: Call the lookupInvoice method on NWCAccountCubit with the invoice ID and replace it with:

await cubit.lookupInvoice(widget.makeInvoiceResult.invoice);

Here, lookupInvoice is called on the cubit with the invoice ID from widget.makeInvoiceResult.

Listener in `invoice_qr_page.dart`

The listener listens for changes in NWCAccountCubit state and reacts based on the type of result received.

Locate // TODO: Handle the case when the result type is 'lookup_invoice' and the result is not null and replace it with:

// 1
if (resultType == NWCResultType.lookup_invoice && result != null) {
  // 2
  final isPaid = result.settledAt != null ? true : false;
  if (isPaid) {
    // 3
    final navigator = Navigator.of(context);
    navigator.popUntil((route) => route.settings.name == "/");
    navigator.push(
      MaterialPageRoute(
        builder: (_) => const SuccessPage(
          title: 'Payment Received Successfully',
          description:
              'Congratulations! You have successfully received sats from the sender.',
        ),
      ),
    );
  }
}

Here:

It checks if resultType is lookup_invoice and result is not null.
Checks if settledAt field in the result is not null, indicating that the invoice has been paid.
If paid, pops routes until root ("/") route and navigates to SuccessPage with a success message.

Next, locate // TODO: Handle the case when the result type is 'error' and the nwcErrorResponse is not null and replace it with:

// 1
else if (resultType == NWCResultType.error &&
    state.nwcErrorResponse != null) {
  final errorMessage = state.nwcErrorResponse!.errorMessage;
  // 2
  showToast(
    context,
    title: errorMessage,
    type: ToastificationType.error,
  );
}

Here:

It checks if resultType is error and nwcErrorResponse is not null.
If conditions are met, it shows a toast notification with the error message.

That completes the lookup_invoice command implementation. Now, hot restart the app, create an invoice, and try paying it. You'll see the lookup_invoice command in action, navigating to the SuccessPage upon successful payment.

We've covered get_balance, make_invoice, and lookup_invoice. Let's proceed to the final command of this article: pay_invoice.

Command: pay_invoice

For the final command, head over to lib/bloc/nwc_account/nwc_account_cubit.dart and look at the payInvoice method which is responsible for paying a specific invoice provided by the user.

Locate // TODO: Construct the message to pay the invoice and replace it with:

final message = {
  "method": "pay_invoice",
  "params": {
    "invoice": invoice,
  }
};

Here, message constructs the pay_invoice command as defined in NIP47:

The params key contains a map with the invoice to be paid.

Next, locate // TODO: Send the payment request to the relay using _sentToRelay and replace it with:

await _sentToRelay(message);

This sends the constructed request to the relays using the _sentToRelay method.

Now, locate // TODO: Handle pay_invoice result inside the _initializeConnection() method and replace it with:

else if (content.resultType == NWCResultType.pay_invoice) {
  // 1
  final invoiceResult = content.result as Pay_Invoice_Result;
  // 2
  _paymentResultStreamController.add(
    NWCPaymentResult(
      resultType: NWCResultType.pay_invoice,
      payInvoiceResult: invoiceResult,
    ),
  );
  // 3
  emit(
    state.copyWith(
      resultType: NWCResultType.pay_invoice,
      payInvoiceResult: invoiceResult,
    ),
  );
}

Here:

When resultType is pay_invoice, it casts content.result to Pay_Invoice_Result.
Adds a new payment result to _paymentResultStreamController to stream to listeners.
Emits a new state with updated payInvoiceResult to reflect the payment operation.

Now, let's integrate this into the UI flow for paying an invoice.

`PaymentRequestDialog` in `payment_dialogs/payment_request_dialog.dart`

This dialog handles the confirmation of paying an invoice after decoding it. Locate // TODO: Call the payInvoice method on accountCubit with the invoice bolt11 and replace it with:

paymentFunc: () => accountCubit.payInvoice(widget.invoice.bolt11),

Here:

payInvoice method is called on accountCubit with the bolt11 invoice string from widget.invoice.

Using `payInvoice` in UI Flow

From the home screen, when the user clicks on "Send", they are taken to the PayInvoicePage. After pasting the invoice there and clicking on "Pay Invoice" button, the invoice is decoded, and a confirmation dialog (PaymentRequestDialog) is shown to the user.

If the user clicks "Yes" in the PaymentRequestDialog, the payInvoice method we just implemented is called to initiate the payment process.

Testing the Flow

Hot restart the app. Click on "Send" on the home page, paste an invoice from a different wallet, and click "Pay Invoice".

In the PaymentRequestDialog, click "Yes".

You'll see a ProcessingPaymentDialog and after that, a success screen if the payment is successful.

This completes the integration of the pay_invoice command. Now you have a complete flow for creating, receiving, and paying invoices using the NWCAccountCubit and handling the respective results and errors.

Conclusion

As we come to the end of our journey exploring Nostr wallet connect, I want to express my heartfelt thanks to the developers and the vibrant community driving innovations in Nostr, NWC, and the Lightning Network space. Your dedication and expertise have made it straightforward for developers like me to integrate Lightning Network capabilities into our apps.

As we continue to explore Lightning Network features in our apps, remember that this technology marks just the beginning of a transformative era in Bitcoin's scalability.

If you have any questions or wish to share your experiences, please feel free to reach out to me on Twitter, Nostr, or LinkedIn.

Thank you for joining me on this journey. ⚡🌊

Clipboard Monitoring for Bitcoin Addresses in Flutter

Aniket Ambore — Sun, 31 Dec 2023 13:00:25 +0000

Introduction

Hello, and welcome to this tutorial article! In this article, I'll guide you through the process of implementing clipboard monitoring in a Flutter app. You'll learn how to watch the device clipboard and take actions based on the clipboard data.

Use Case

Have you ever wondered how Bitcoin wallets detect copied addresses and prompt you when you open another wallet? We'll be implementing exactly that functionality in this article.

This is what you'll learn to implement in this article.

Getting Started

Let's begin!

First, create a new Flutter project:

flutter create watching_clipboard_demo

After creating the project, open the pubspec.yaml file and add the following dependencies:

dependencies:
  flutter:
    sdk: flutter
  clipboard_watcher: ^0.2.0
  rxdart: ^0.27.7
  shared_preferences: ^2.2.2

Here's what each dependency helps you with:

clipboard_watcher: A Flutter plugin for listening to clipboard changes. Useful for detecting changes in the clipboard.
rxdart: RxDart is a reactive functional programming library for Dart. It provides a set of reactive extensions for Dart streams.
shared_preferences: Shared Preferences plugin for Flutter, providing a persistent key-value store for simple data storage.

After adding the dependencies, run flutter pub get to fetch them.

Clipboard Manager Implementation:

Now, let's create a new file inside the lib folder named clipboard_manager.dart and add the following code:

import 'package:clipboard_watcher/clipboard_watcher.dart';
import 'package:flutter/services.dart';
import 'package:rxdart/rxdart.dart';
import 'package:shared_preferences/shared_preferences.dart';

// 1
class ClipboardManager extends ClipboardListener {
  // 2
  String? _lastFromAppClip;

  // 3
  static const String LAST_CLIPPING_PREFERENCES_KEY = "lastClipping";
  static const String LAST_FROM_APP_CLIPPING_PREFERENCES_KEY =
      "lastFromAppClipping";

  // 4
  final _clipboardController = BehaviorSubject<String>();
  Stream<String> get clipboardStream => _clipboardController.stream
      .where((content) => content != _lastFromAppClip);

  ClipboardManager() {
    print('[+] Initiating ClipboardManager');

    // 5
    var sharedPreferences = SharedPreferences.getInstance();

    // 6
    sharedPreferences.then((preferences) {
      // 7
      _lastFromAppClip =
          preferences.getString(LAST_FROM_APP_CLIPPING_PREFERENCES_KEY);
      // 8
      _clipboardController
          .add(preferences.getString(LAST_CLIPPING_PREFERENCES_KEY) ?? "");
      print("[+] Last clipping: $_lastFromAppClip");
      // 9
      fetchClipboard(preferences);
    });
    // 10
    clipboardWatcher.addListener(this);
    // 11
    clipboardWatcher.start();
  }

  void fetchClipboard(SharedPreferences preferences) {
    // TODO: Implement fetchClipboard
  }

  Future<void> setClipboardText(String text) async {
    // TODO: Implement setClipboardText
  }

  // 12
  @override
  void onClipboardChanged() {
    print("[+] Clipboard changed");
    // 13
    SharedPreferences.getInstance().then((preferences) {
      fetchClipboard(preferences);
    });
  }
}

In this code, we're performing the following steps:

The ClipboardManager class extends ClipboardListener to capture clipboard change events.
_lastFromAppClip stores the last clipboard content copied from inside our app.
Keys used for storing and retrieving clipboard content in SharedPreferences.
Controller for managing clipboard content stream.

Inside the ClipboardManager constructor, we're:

Retriving the SharedPreferences instance.
Handling the SharedPreferences instance when available.
Retrieving the last clipboard content copied from inside the app.
Adding the last clipboard content to the stream.
Fetch the clipboard content.
Adding ClipboardListener to detect clipboard changes.
Starting to listen for clipboard changes.
Overriding onClipboardChanged method to handle clipboard change events.
Getting the SharedPreferences instance and fetching clipboard content.

One thing I want you to understand is the approach behind _lastFromAppClip, LAST_CLIPPING_PREFERENCES_KEY, and LAST_FROM_APP_CLIPPING_PREFERENCES_KEY. When the user copies a bitcoin address from inside our app (referred to as "from app clipping"), we don't want to show the Clipboard dialog because that content is copied within the app. Displaying the dialog for content copied within the app is considered a bug.

That's why in the clipboardStream, we're discarding all elements that are not equal to the content copied within the app (_lastFromAppClip).

Let's move on to implement fetchClipboard method by locating // TODO: Implement fetchClipboard and replacing it with the following code as:

  void fetchClipboard(SharedPreferences preferences) {
    print("[+] Fetching clipboard");
    // 1
    Clipboard.getData('text/plain').then((clipboardData) {
      // 2
      final text = clipboardData?.text;
      print('[+] Clipboard text: $text');
      // 3
      if (text != null) {
        // 4
        _clipboardController.add(text);
        // 5
        preferences.setString(LAST_CLIPPING_PREFERENCES_KEY, text);
      }
    });
  }

The above method retrieves the current content of the clipboard using the Clipboard.getData method from the flutter/services.dart package. If the clipboard contains text data, it is added to the _clipboardController stream and stored in SharedPreferences for future reference. Here we're:

Using the Clipboard.getData method to retrieve clipboard data of type 'text/plain'.
Extracting the text content from the clipboard data.
Checking if the text content is not null.
Adding the text content to the _clipboardController stream.
Storing the text content in SharedPreferences under the specified key.

Main App Implementation

Now, let's move on to the main.dart file and replace the default counter app Flutter example with the following code:

import 'package:flutter/material.dart';
import 'package:watching_clipboard_demo/clipboard_manager.dart';

void main() {
  WidgetsFlutterBinding.ensureInitialized();

  // 1
  final clipboardManager = ClipboardManager();
  runApp(
    MaterialApp(
      home: ClipboardWatcherApp(
        clipboardManager: clipboardManager,
      ),
    ),
  );
}

class ClipboardWatcherApp extends StatefulWidget {
  const ClipboardWatcherApp({
    super.key,
    required this.clipboardManager,
  });
  final ClipboardManager clipboardManager;

  @override
  State<ClipboardWatcherApp> createState() => _ClipboardWatcherAppState();
}

class _ClipboardWatcherAppState extends State<ClipboardWatcherApp> {
  // 2
  String copiedBitcoinAddress = '';

  @override
  void initState() {
    super.initState();
    // 3
    _startClipboardWatching();
  }

  // 4
  void _startClipboardWatching() {
    // TODO: Implement _startClipboardWatching
  }

  // 5
  bool isBitcoinAddress(String address) {
    // TODO: Implement isBitcoinAddress
    // This method should perform Bitcoin address validation.
    // Return true if the address is a valid Bitcoin address, false otherwise.
    return true;
  }

  // 6
  void _showBitcoinAddressDialog(String bitcoinAddress) {
    showDialog(
      context: context,
      builder: (BuildContext context) {
        return AlertDialog(
          title: const Text("Clipboard"),
          content: const Text(
              "You have a Bitcoin address on your clipboard. Would you like to use it for a transaction?"),
          actions: [
            TextButton(
              onPressed: () {
                Navigator.of(context).pop();
              },
              child: const Text("Cancel"),
            ),
            TextButton(
              onPressed: () {
                setState(() => copiedBitcoinAddress = bitcoinAddress);
                Navigator.of(context).pop(); // Close the dialog
              },
              child: const Text("Continue"),
            ),
          ],
        );
      },
    );
  }

  @override
  Widget build(BuildContext context) {
    // 7
    return Scaffold(
      body: Center(
        child: Container(
          padding: const EdgeInsets.all(16),
          child: Column(
            mainAxisAlignment: MainAxisAlignment.center,
            children: [
              const Icon(
                Icons.currency_bitcoin_outlined,
                size: 100,
              ),
              Text(
                copiedBitcoinAddress,
                style: const TextStyle(
                  fontSize: 18,
                  fontWeight: FontWeight.w600,
                ),
              ),
            ],
          ),
        ),
      ),
    );
  }
}

In this code:

We initialize ClipboardManager to listen for clipboard changes.
A variable to store the last copied Bitcoin address.
We start watching the clipboard when the app starts.
A method to start watching the clipboard for Bitcoin addresses.
A method to check if the given string is a Bitcoin address.
A method to show a dialog when a Bitcoin address is detected in the clipboard.
We build the main screen with a Bitcoin icon and the copied Bitcoin address.

Now, let's run the app and observe the simple screen with the Bitcoin icon in the center.

Address Validation

Now, let's implement the isBitcoinAddress method in main.dart by locating // TODO: Implement isBitcoinAddress and replace it with the following code:

  bool isBitcoinAddress(String address) {
    // Implement your Bitcoin address validation logic here
    // Check if the provided address matches the Bitcoin address pattern
    return address.startsWith('bc1');
  }

In this isBitcoinAddress method, I'm checking if the address starts with bc1 to determine if it's in segwit or bech32 address format. However, you can use appropriate regex or a Bitcoin package for a more comprehensive validation based on your specific requirements.

Clipboard Watching

Next, let's implement the _startClipboardWatching method by locating // TODO: Implement _startClipboardWatching and replacing it with the following code:

  void _startClipboardWatching() {
    print("[+] _watchingIncoming");

    // 1
    widget.clipboardManager.clipboardStream.distinct().skip(1).listen((data) {
      // 2
      if (isBitcoinAddress(data)) {
        // 3
        _showBitcoinAddressDialog(data);
      }
    });
  }

The _startClipboardWatching method starts watching the clipboard for Bitcoin addresses. Here's a breakdown:

Subscribe to the clipboard stream provided by the ClipboardManager.
- Use distinct() to filter out consecutive identical clipboard content.
- Use skip(1) to skip the initial content when the app starts.
- Use listen() to react to changes in the clipboard content.
Checking if the clipboard content is a Bitcoin address.
If it is a Bitcoin address, show a dialog to the user.

You maybe thinking why I used skip(1) here?

Well, the purpose of skip(1) operator is used to skip the initial value emitted by the clipboard stream when the app starts. And the reason of using skip(1) is because when the app initializes, the clipboard may already contain some content. If the app doesn't skip the initial value, it might trigger unnecessary actions based on the current clipboard content at the app's launch. By using skip(1), we ensure that the app only react to changes in the clipboard content after the app has started.

Great! With this, we're almost done. Now, run the app again. Copy a Bitcoin address from another app, then open the app. You will see the dialog as shown below:

Click on "Continue" in the dialog, and the main screen will update accordingly:

Homework and Conclusion

Fantastic! Everything is in place. The only thing left is the setClipboardText method of ClipboardManager, and that is your homework. Try to implement it. Additionally, create a simple widget on the main screen displaying a hardcoded Bitcoin address and a copy button. Clicking on the copy button should copy the Bitcoin address to the clipboard. If the dialog is shown, your implementation is incorrect. If the dialog is not shown, everything is right.

The homework solution will be available on the GitHub repo of this article here.

If you have questions or want to connect and share your experiences, feel free to reach out to me on Twitter, Nostr, or LinkedIn.

Thank you for joining me. ⚡🌊

Tutorial: How to develop a Non-Custodial Bitcoin Lightning Wallet using Flutter and LDK?

Aniket Ambore — Sun, 15 Oct 2023 15:24:00 +0000

Hello everyone! My name is Aniket (aka Anipy) and in this tutorial, I'm going to show you how to create your very own Non-Custodial Bitcoin Lightning wallet using Flutter and the Lightning Development Kit (LDK). It all began for me when I finished reading "Mastering the Lightning Network" book. As a little side project, I decided to develop a non-custodial Bitcoin Lightning wallet, and here's what I've learned and developed along the way.

In this tutorial, I'll share my experiences and provide answers to some of the questions and challenges I encountered while developing the wallet. I received plenty of help from the friendly LDK team developers on their Discord channel, and I'll do my best to explain everything in a straightforward manner. Just a heads up, we won't be diving too deep into UI development or Flutter here; our main focus will be on implementing a Lightning wallet in Flutter with LDK.

If you're already familiar with the Lightning Network, Lightning nodes, and Lightning wallets, feel free to jump right into the "Getting Started" section below. For those of you looking for a quick refresher or wanting to explore this fascinating technology from the ground up, read on for a brief overview.

What is Lightning Network?

Let's discuss the Lightning Network in simple terms. It's like a protocol built on top of Bitcoin that makes transactions faster, more private, and scalable.

In 2015, Joseph Poon and Thaddeus Dryja proposed the Lightning Network to address Bitcoin's scalability issue.

Think of the Lightning Network as a helpful tool that acts as a second layer technology by enabling off-chain transactions, it reduces the load on the main bitcoin blockchain and allow faster and more cost-effective microtransactions.

Users initially load Bitcoin onto the Lightning Network. They settle on-chain only when they open or close channels (we'll cover this shortly). After that, payments within an open channel can be almost instant, without requiring confirmation from Bitcoin blocks.

The Lightning Network has some cool features:

Payments on the Lightning Network do not require waiting for block confirmations.
Lightning Network payments are transmitted between pairs of nodes, offering enhanced privacy compared to on-chain transactions.
Unlike Bitcoin network transactions, Lightning Network payments do not need permanent storage, reducing resource usage and cost.
Nodes involved in routing payments are aware only of their predecessor and successor in the payment route.
The Lightning Network utilizes real bitcoin, maintaining user custody and full control over funds.

So, remember that the Lightning Network is not a separate token or coin; it's built on top of Bitcoin. In the next section we'll talk about Lightning node.

What is Lightning Node?

The Lightning Network operates through software apps that implement the Lightning Network protocol and most of these apps follow common standards outlined in the BOLTs specification.

A Lightning Network node (LN node) is a piece of software with these key characteristics:

It serves as a wallet for payments on both the Lightning and Bitcoin network.
It communicates directly with other nodes, forming the network through peer-to-peer connections.
It needs access to the Bitcoin blockchain for payment security.

Users have the highest level of control when they run their own Bitcoin node and Lightning node. However, Lightning nodes can also use a lightweight Bitcoin client to interact with the Bitcoin blockchain.

Now in the next section let's talk about Lightning wallet.

What is Lightning Wallet?

The term "Lightning wallet" can be a bit unclear because it can refer to a combination of various components with some user interface. The most common components found in Lightning wallet software include:

A keystore that holds secrets, such as wallet mnemonic.
An LN node (Lightning node) that communicates on the peer-to-peer network, as we discussed earlier.
A Bitcoin node that stores blockchain data and communicates with other Bitcoin nodes
A database that maps out nodes and channels announced on the Lightning Network.
A channel manager that can open and close LN channels
A close-up system that can find a path of connected channels from payment source to payment destination.

A Lightning wallet may contain all of these functions, acting as a "full" wallet, with no reliance on any third-party services. Or one or more of these components may rely (partially or entirely) on third-party services that mediate those functions.

A key distinction (pun intended) is whether the keystore function is internal or outsourced. In blockchains, control of keys determines custody of funds, as memorialized by the phrase "your keys, your coins; not your keys, not your coins".

Custodial wallets outsource key management, while noncustodial wallets put you in control of your own keys.

The wallet you'll learn to create in this tutorial is a noncustodial wallet. This means the user of our wallet will have full control over their keys.

The term "noncustodial wallet" implies that the keystore is local and under the user's control. However, some of the other wallet components may or may not rely on trusted third parties.

Remember that, control over keys is a critical consideration when choosing a Lightning wallet.

Now that you understand the Lightning Network and its key parts, let's jump in and start making your very own Lightning wallet. Get ready for an exciting journey!

Getting started

Before we get our hands dirty with code, let's kick things off by grabbing the "starter" project for this tutorial. Just copy and paste the following command into your terminal:

git clone -b starter --single-branch https://github.com/aniketambore/bijli_ln_wallet

This command will get you the "starter" project in no time and will save your time.

Feeling the excitement? Great! Now, fire up your favorite code editor, whether it's VS Code or Android Studio. After that, run flutter pub get to set things up, and then launch the app. Right now, it's a straightforward UI project, but we'll soon weave in some Lightning Network magic.

Project files

There are some files in the starter project to help you out. Before you learn how to develop a non-custodial bitcoin lightning wallet, take a look at them.

Assets folder

Inside the assets directory, you'll find images that will be used to build your app.

Folder Structure

In the lib directory, you'll notice various folders, each serving a specific purpose:

Component Library Folder

lib/component_library contains all the UI components that either are, or have the potential to be, reused across different screens.

Domain Models Folder

lib/domain_models contains all the model objects used in our app. These models define how data is structured and managed within the app.

Features Folder

lib/features contains the core functionality of the app, following a package-by-feature approach. It's where the magic happens.

I consider a feature to be either:

A screen
A dialog that excutes I/O calls. The lib/features/send_offchain_dialog falls into this category.

Wallet Repository Folder

lib/wallet_repository is where the communication with the LDK (Lightning Development Kit) Node Flutter plugin happens. This repository coordinates data from different sources and keeps things running smoothly.

App libraries

The starter project comes with a set of useful libraries listed in pubspec.yaml:

dependencies:
  ...
  bitcoin_ui_kit:
    git:
      url: https://github.com/aniketambore/bitcoinuikit-flutter.git
      ref: alternative-implementation
  bitcoin_icons: ^0.0.4
  ldk_node: ^0.1.2
  bolt11_decoder: ^1.0.2
  bip39: ^1.0.6
  flutter_secure_storage: ^9.0.0
  path_provider: ^2.0.12
  qr_flutter: ^4.1.0
  share_plus: ^7.1.0
  another_flushbar: ^1.12.30
  floating_action_bubble: ^1.1.4
  equatable: ^2.0.5
  auto_size_text: ^3.0.0
  routemaster: ^1.0.1
  flutter_bloc: ^8.1.3
  confetti: ^0.7.0
  rxdart: ^0.27.7

Here's what they help you to do:

bitcoin_ui_kit: This package offers helpful widgets and themes following the Bitcoin design guide. It's like a design toolbox,
bitcoin_icons: Use this package to easily access the collections of Bitcoin icons for your app.
ldk_node: This package provides a simple interface for setting up and running a Lightning node with an integrated on-chain wallet.
bolt11_decoder: Use this package to decode BOLT11 invoices.
bip39: This package helps generate new mnemonic phrases. It's like a phrase generator.
flutter_secure_storage: This package ensures secure storage capabilities for your app. It's your secret vault for mnemonic.
path_provider: This package helps you access the file system path on the device.
qr_flutter: This package enables you to generate QR codes within your app.
share_plus: This package allows easy sharing of content from our app.
another_flushbar: This package provides customizable and user-friendly notifications.
floating_action_bubble: This package helps us to create floating action buttons with a bubble effect.
equatable: This package simplifies equality comparisons for our Dart classes.
auto_size_text: This package automatically adjusts the text size to fit the available space.
routemaster: This package offers a flexible routing system.
flutter_bloc: This package is used to implement the BLoC (Business Logic Component) design pattern in our app.
confetti: This package adds confetti animations to our app.
rxdart: This package extends the capabilities of Dart's Streams with reactive programming.

Wallet Initialization

In this step, we'll set up our wallet, starting with some crucial configurations. Open lib/wallet_repository/src/wallet_repository.dart and follow these instructions:

Import the Necessary Packages

Locate // TODO: Add imports here and replace it with the following code:

import 'package:ldk_node/ldk_node.dart' as ldk;
import 'package:bip39/bip39.dart' as bip39;
import 'package:path_provider/path_provider.dart';

Here we're importing the ldk_node plugin and bip39 and path_provider package, giving alias "ldk" and "bip39" is for easier reference in your code.

Initialize Wallet Configuration

Move on to // TODO: Initialize variables here and replace it with the following code:

  // 1
  static const LDK_NODE_DIR = "LDK_NODE";
  // 2
  static const esploraURL = "https://mempool.space/testnet/api";
  // 3
  static const network = ldk.Network.Testnet;
  // 4
  late ldk.Node ldkNode;

Here we're defining configuration variables for LDK:

LDK_NODE_DIR: Defines the directory where your LDK node's data will be stored.
esploraURL: This URL points to a Bitcoin testnet server (specifically, mempool.space) used for indexing blockchain data quickly.
network: Indicates that the network being used is the Bitcoin testnet. Options avialable are [Bitcoin, Testnet, Signet, Regtest]
ldkNode: The ldkNode variable will hold the instance of the LDK node that will be set up below for interacting with the Lightning Network.

Generate a New Mnemonic

Locate // TODO: Implement method to generate a new mnemonic and replace it with the following code:

  String _generateMnemonic() {
    // 1
    final mnemonic = bip39.generateMnemonic();
    // 2
    return mnemonic;
  }

In the above code, we're:

Generating a new mnemonic using the bip39 package.
Returning the generated mnemonic for wallet setup.

Create or Recover a Wallet

Now, locate // TODO: Implement method to create or recover a wallet and replace it with the following code:

  Future<String> createOrRecoverWallet({String? recoveryMnemonic}) async {
    // 1
    final mnemonic = recoveryMnemonic ?? _generateMnemonic();
    // 2
    final directory = await getApplicationDocumentsDirectory();
    // 3
    final storagePath = "${directory.path}/$LDK_NODE_DIR";
    // 4
    final builder = ldk.Builder()
        .setEntropyBip39Mnemonic(mnemonic: ldk.Mnemonic(mnemonic))
        .setNetwork(network)
        .setStorageDirPath(storagePath)
        .setEsploraServer(esploraServerUrl: WalletRepository.esploraURL);
    // 5
    ldkNode = await builder.build();
    // 6
    await ldkNode.start();
    // 7
    await _secureStorage.upsertWalletMnemonic(
      mnemonic: mnemonic,
    );
    // 8
    return mnemonic;
  }

In this section, you are:

Deciding whether to create a new wallet or recover an existing one.
Getting the application's document directory for data storage.
Defining the storage path for the LDK node's data.
Setting up the LDK node with the specified configuration using the builder.
Building the LDK node based on the provided configuration.
Starting the LDK node for network interaction.
Securely storing the mnemonic for future use.
Returning the mnemonic, which is essential for wallet management.

Retrieve Wallet Information

Now, let's locate // TODO: Implement method to retrieve wallet mnemonic from storage and replace it with this code:

  Future<String?> getWalletMnemonic() {
    return _secureStorage.getWalletMnemonic();
  }

Here we're retrieving the wallet's mnemonic from secure storage and returning it.

Get Lightning Node ID

Now, let's locate // TODO: Implement method to retrieve Lightning node ID and replace it with this code:

  Future<String> getNodeId() async {
    final id = await ldkNode.nodeId();
    return id.internal;
  }

Here, you're retrieving your wallet LDK node's ID and returning it as a string.

Now, in the _getWalletInformation() method locate // TODO: Retrieve our own node ID and replace it with the following code:

String nodeId = await getNodeId();

In the Wallet object, replace nodeId: 'dummy_node_id' with nodeId: nodeId, esploraUrl: 'dummy_esplora_url' with esploraUrl: esploraURL, and network: 'dummy_network' with network: network.name.

Let's test the app! If it's already running, perform a hot reload and click the "Create Wallet" button.

Now, you'll be on the home screen. To view your mnemonic and node ID, click the popup menu button in the app's toolbar and select "Wallet Info."

The Wallet Information screen will appear, displaying your wallet information. Click on "Display Mnemonic" and a dialog will pop up, revealing your wallet mnemonic as:

In the next section, we'll focus on implementing Bitcoin on-chain functionality in our app.

On-Chain Functionality

In this section we'll implement some essential functions for on-chain Bitcoin transactions. Let's dive into it:

Retrieve On-Chain Address

To get your Bitcoin on-chain address, locate // TODO: Implement method to retrieve on-chain address and replace it with the following code:

  Future<String> getOnChainAddress() async {
    final ldk.Address address = await ldkNode.newOnchainAddress();
    return address.internal;
  }

The getOnChainAddress method requests a new Bitcoin on-chain address from the LDK Node and returns it as a string. This address is crucial for receiving on-chain Bitcoin transactions.

Retrieve On-Chain Balance

Next, replace // TODO: Implement method to retrieve on-chain balance with this code:

  Future<int> getOnChainBalance() async {
    // 1
    await ldkNode.syncWallets();
    // 2
    final balance = await ldkNode.totalOnchainBalanceSats();
    return balance;
  }

In this code, we're performing the following steps:

Synchronizing the wallet to ensure up-to-date balance information.
Retrieving and returning the total Bitcoin on-chain balance in sats. This balance represents the amount of Bitcoin you have in your on-chain wallet.

Now, In the _getWalletInformation() method locate // TODO: Retrieve on-chain balance and address information and replace it with the following code:

    int onChainBalanceSats = await getOnChainBalance();
    String onChainAddress = await getOnChainAddress();

This code retrieves both the on-chain balance and address, ensuring that your wallet's information is up to date.

In the Wallet object replace onChainBalanceSats: 0 with onChainBalanceSats: onChainBalanceSats and onChainAddress: 'dummy_address' with onChainAddress: onChainAddress.

Once you've made these updates, perform a hot reload of your app. Afterward, click the refresh icon on the home screen, situated in the row with the balance view.

After the refresh is complete, you'll see your Bitcoin on-chain address displayed, replacing 'dummy_address'. The QR code will also be encoded with this Bitcoin on-chain address.

Now, let's proceed to send some testnet Bitcoin (tBTC) to that address.

You can get some tBTC to play with from a testnet bitcoin faucet, which gives out free tBTC on demand. Here are a few testnet faucets to get you started:

So here with testnet bitcoin, we're not risking real funds. So it's good!

Now, let's implement the functionality to send on-chain Bitcoin.

Send On-Chain Bitcoin

Locate // TODO: Implement method to send funds to an on-chain address and replace it with the following code:

  Future<String> sendToOnchainAddress({
    required String address,
    required int amountSats,
  }) async {
    // 1
    final addr = ldk.Address(internal: address);
    // 2
    final txid = await ldkNode.sendToOnchainAddress(
      address: addr,
      amountSats: amountSats,
    );
    print('[WalletRepository] Send On-Chain Txid: ${txid.internal}');
    // 3
    return txid.internal;
  }

In the code above, you're doing the following:

Creating an Address object with the provided recipient's on-chain Bitcoin address.
Initiating an on-chain transaction to send the specified amount of sats to the address.
Returning the transaction ID (txid) for reference.

Now, perform a hot reload of your app, navigate to the Payments tab on the home screen, click the floating action button, and choose 'SEND TO BTC ADDRESS' Enter the recipient's on-chain Bitcoin address and the amount in sats.

Add testnet bitcoin on-chain address in their, if you don't have any bitcoin testnet address just do one thing, send me some tBTC here tb1qyvp29ysl00rqrayyh633fgmdqsqsucwtnaw9n5 🙃. Also specify the amount that you want to send in sats. Click on submit.

After the payment is successful, you'll see a success indicator screen, and the transaction ID (txid) will be displayed on the console. You can copy this txid and paste it into a block explorer like https://mempool.space/testnet to view your transaction details.

One thing to note is that the current LDK Node Flutter plugin does not provide functionality for:

Retrieving Bitcoin on-chain transaction information. (Issue: https://github.com/LtbLightning/ldk-node-flutter/issues/23)
Setting a custom fee rate in the sendToOnchainAddress method. (Issue: https://github.com/LtbLightning/ldk-node-flutter/issues/24)

I'll update this section once these issues are resolved. In the next section, we'll dive into setting up payment channels 🚀

Opening Payment Channel

Let's kick things off by understanding what a payment channel is, but don't worry; we'll keep it simple. In simple terms, a payment channel is like a financial relationship between two Lightning nodes. It's established by funding a 2-of-2 multisignature address from the two channel partners.

So, payment channels are built on top of 2-of-2 multisignature addresses.

In summary, a multisignature address is where bitcoin is locked so that it requires multiple signatures to unlock and spend. In a 2-of-2 multisignature address, as used in the Lightning Network, there are two participating signers and both need to sign to spend the funds.

To open a payment channel, we first need to establish a connection with another node. To do that, we require a "Node Identifier" for that node. A Node Identifier typically looks like "NODEID@Address:Port"

The NODEID is a unique identifier for a specific node, often presented in hexadecimal encoding.
The Address:Port is a network address identifier where the node can be reached. This can be in various formats, like TCP/IP (IPv4 or IPv6 address with a TCP port number) or TCP/Tor (a Tor "onion" address with a TCP port number).

For example, the Node Identifier for the PLEBNET.DEV testnet lightning node looks like this: 03ba00a57cec1cef4873065ad54d0912696274cc53155b29a3b1256720e33a0943@24.199.122.244:19735. You can often find the identifier encoded in a QR code for easy scanning and connecting.

Keep in mind that to open a payment channel, you need the Node Identifier, which includes nodeId, address/host, and port. Also, you need to specify the channel amount, which is the total channel capacity.

Here's a pro tip: You can choose to push/send an amount to your channel partner during channel funding. This helps balance the channel right from the start and allows you to receive payments right away. But be careful when setting this value because it essentially sends money to your channel partner.

So before constructing the payment channel we must first be connected with our channel peer to which we want to open a payment channel with. The good news is, LDK offers a convenient method called connectOpenChannel to connect to a node and open a new channel. It also handles disconnects and reconnections automatically.

Let's get our hands dirty by implementing the method to open a Lightning payment channel. Find the // TODO: Implement method to open a Lightning payment channel and replace it with this code:

  Future<void> openPaymentChannel({
    required String nodeId,
    required String host,
    required int port,
    required int amountSat,
    int? pushToCounterpartySat,
  }) async {
    await ldkNode.connectOpenChannel(
      netaddress: ldk.NetAddress.iPv4(
        addr: host,
        port: port,
      ),
      nodeId: ldk.PublicKey(internal: nodeId),
      channelAmountSats: amountSat,
      announceChannel: true,
      pushToCounterpartyMsat: (pushToCounterpartySat != null)
          ? satoshisToMilliSatoshis(pushToCounterpartySat)
          : 0,
    );
  }

This openPaymentChannel method lets you establish a payment channel with a specific node, connect to it, and optionally announce the channel to the network. You can also specify an optional amount to push to your channel partner.

But that's not all. We also need a way to list all the payment channels we've opened. Replace // TODO: Implement method to list Lightning payment channels with this code:

  Future<List<ldk.ChannelDetails>> listPaymentChannels() async {
    final channels = await ldkNode.listChannels();
    return channels;
  }

This listPaymentChannels method is used to retrieve and return a list of payment channels associated with your wallet.

And, we're not done yet! To keep you in the loop, let's implement getting the list of connected peers. Replace // TODO: Implement method to list Lightning peers with this code:

  Future<List<ldk.PeerDetails>> listPeers() async {
    final peers = await ldkNode.listPeers();
    return peers;
  }

The listPeers method fetches and returns a list of peer details, representing the peers connected on the Lightning Network to our node.

Finally, let's implement getting all the transaction information by replacing // TODO: Implement method to list Lightning transactions with the following code:

  Future<List<ldk.PaymentDetails>> listTransactions() async {
    // 1
    final paymentDetails = <ldk.PaymentDetails>[];
    // 2
    final payments = await ldkNode.listPayments();
    // 3
    for (var e in payments) {
      if (e.status == ldk.PaymentStatus.Succeeded) {
        paymentDetails.add(e);
      }
    }
    // 4
    return paymentDetails;
  }

In the code above, we're doing the following:

Initializing a list to store payment details.
Retrieving a list of all payments made through your wallet.
Filtering and adding successful payments to the list of payment details.
Returning the list of successful payment details.

Now, head over to the _getWalletInformation() method and replace // TODO: Retrieve lists of payment channels, peers, and payment details with this code:

    List<ldk.ChannelDetails> paymentChannelsList = await listPaymentChannels();
    List<ldk.PeerDetails> peersList = await listPeers();
    List<ldk.PaymentDetails> paymentList = await listTransactions();

Next, locate // TODO: Initialize variables to hold various wallet information and replace it with the following:

    int inboundCapacitySats = 0;
    int outboundCapacitySats = 0;
    String? bolt11Invoice;

Next, locate // TODO: Calculate inbound and outbound channel capacities and replace it with this:

    for (var channel in paymentChannelsList) {
      inboundCapacitySats +=
          milliSatoshisToSatoshis(channel.inboundCapacityMsat);
      outboundCapacitySats +=
          milliSatoshisToSatoshis(channel.outboundCapacityMsat);
    }

In the Wallet object, replace inboundCapacitySats: 0 with inboundCapacitySats: inboundCapacitySats, outboundCapacitySats: 0 with outboundCapacitySats: outboundCapacitySats, paymentChannelsList: const [] with paymentChannelsList: paymentChannelsList, peersList: const [] with peersList: peersList and paymentsList: const [] with paymentsList: paymentList.

Now, perform a hot reload of your app and run it. Refresh the app by clicking the refresh icon on home screen. To open a payment channel, follow these steps:

Go to the "Channels" tab.
Click on the floating action button and select "ENTER A NODE URI" to open the OpenChannelScreen.
Enter the node ID, address, port, amount, and counterparty amount.
Click "submit."

So, we'll be opening a payment channel with the PLEBNET.DEV testnet Lightning node using its node identifier: "03ba00a57cec1cef4873065ad54d0912696274cc53155b29a3b1256720e33a0943@24.199.122.244:19735".

If everything goes as planned, you'll see a success screen.

Clicking "okay" will take you back to the home screen, where you can see that you now have an open channel with 100,000 sats of capacity, 49,000 sats outbound capacity, and 49,000 sats inbound capacity. The rest is the Bitcoin on-chain fees for opening a payment channel by funding a 2-of-2 multisignature address, which is recorded on the Bitcoin blockchain.

Now, let's refresh the wallet, and you'll see the status of your channel. You may need to wait a bit for the funding transaction to be recorded on the Bitcoin blockchain, similar to waiting for confirmations when acquiring Bitcoin from a faucet.

To check if our channel is ready for action, look at the icon next to the list tile, showing the number of confirmations needed for the channel to be usable.

If you see a circle checkmark icon, that means your channel with the PLEBNET.DEV testnet Lightning node is open, funded, and ready for action!

Also, to take a look at your connected node peers. To do that, click on the pop-up menu button in the app bar, then click "Wallet Info" and select "List Channel Peers." This will display a dialog with all the connected peers to our node.

Creating BOLT11 Invoice

Most payments on the Lightning Network start with an invoice, generated by the recipient of the payment.

An invoice is a simple payment instruction containing information such as a unique payment identifier (payment hash), amount, and optional text description.

The payment hash is the most important part of the invoice, allowing the payment to travel across multiple channels atomically.

Invoices are typically communicated "out of band," using methods like QR codes, email, or text messages. It would be cool to integrate a peer-to-peer messaging feature using Nostr, but for now, let's stick to creating an invoice.

Now, find // TODO: Implement method to create a BOLT11 invoice and replace it with the following code:

  Future<String> createInvoice({
    required int amountSat,
    String? description,
  }) async {
    // 1
    final invoice = await ldkNode.receivePayment(
      amountMsat: amountSat * 1000,
      // 2
      description: (description != null && description.trim().isNotEmpty)
          ? description
          : 'Bijli Invoice',
      // 3
      expirySecs: 10000,
    );
    // 4
    return invoice.internal;
  }

Here's the breakdown of what this code does:

Create an invoice to receive a payment with the specified amount.
Set the invoice description or use a default if not provided.
Set the expiration time for the invoice (in seconds).
Return the internal representation of the created invoice as a string.

LDK also provides an option for creating a zero-sats invoice. This type of invoice is used when you want to request and receive a payment without specifying the amount; the sender determines the amount. To implement this, locate // TODO: Implement method to create a zero-sat BOLT11 invoice and replace it with this code:

  Future<String> createZeroSatInvoice({String? description}) async {
    // 1
    final invoice = await ldkNode.receiveVariableAmountPayment(
      nodeId: await ldkNode.nodeId(),
      // 2
      description: (description != null && description.trim().isNotEmpty)
          ? description
          : 'Bijli Invoice',
      // 3
      expirySecs: 10000,
    );
    // 4
    return invoice.internal;
  }

In this code:

Created a zero-sat invoice to receive a variable amount payment
Set the invoice description or use a default if not provided.
Set the expiration time for the invoice (in seconds).
Return the internal representation of the created invoice as a string.

Moving on to the _getWalletInformation() method, locate // TODO: If there are inbound capacity, create a zero-satoshis invoice (BOLT11 format). and replace it with:

    if (inboundCapacitySats != 0) {
      bolt11Invoice = await createZeroSatInvoice();
    }

Just a quick note: inboundCapacitySats is the amount that you're allowed to receive on the Lightning Network. If you don't have any inbound capacity, you can't receive on Lightning. To balance inbound and outbound capacity, nodes should open channels to others and encourage others to open channels to their node.

When we opened a payment channel in the section we opened the payment channel with capacity of 100,000 sats and we had also pushed 50,000 sats to our channel partner, which means we've inbound capacity of 50,000 sats and outbound capacity of 50,000 sats. Therefore we can receive upto 50,000 sats and can send upto 50,000 sats on lightning.

Now, in the Wallet object, replace bolt11Invoice: 'dummy_invoice' with bolt11Invoice: bolt11Invoice.

Give your app a hot reload and click on the refresh icon on the home screen. Then head to the "Receive" tab and click on child the "LIGHTNING" tab.

The invoice displayed there is a zero-sats invoice with a default description. If you want to customize this invoice, click on the "EDIT REQUEST" button, and a dialog will pop up. Enter the description and the amount in sats.

Now, give it a go by paying this invoice with a different Lightning testnet wallet. You can download the Eclair Mobile Testnet wallet from the Play Store, for example. In Eclair, grab some tBTC from a faucet, open a payment channel with the same PLEBNET.DEV testnet Lightning node, and then try to pay this invoice from the Eclair wallet.

Once the payment goes through in Eclair, click on the refresh icon in "Bijli," and when the refreshing is complete, switch to the "Payments" tab. You'll see a ListTile with payment information, which means you successfully received sats on Lightning! ⚡

This is where the Lightning Network shines, enabling quick and hassle-free payments without the need to wait for confirmations. Now, let's move on to learning how to pay a BOLT11 invoice.

Paying an invoice

In the previous section, we learned how to create an invoice and paid it from an external wallet. Now, it's time to pay an invoice from our wallet that was generated by the Eclair wallet.

Locate // TODO: Implement method to send an off-chain Lightning payment and replace it with the following code:

  Future<ldk.PaymentStatus> sendOffChainPayment({
    required String bolt11Invoice,
  }) async {
    // 1
    final paymentHash = await ldkNode.sendPayment(
      invoice: ldk.Bolt11Invoice(
        internal: bolt11Invoice,
      ),
    );
    // 2
    final result = await ldkNode.payment(paymentHash: paymentHash);
    // 3
    return result!.status;
  }

Here's what this code does:

It sends a Bitcoin Lightning payment using the specified BOLT11 invoice.
It retrieves the payment details using the payment hash.
It returns the status of the payment, indicating whether it was successful, pending, or failed.

Now, perform a hot reload of your app. In the "Payments" tab, click on the floating action button, then select "PASTE AN INVOICE". This will open the SendOffChainScreen. Paste the invoice generated by the Eclair wallet.

Click "continue," and you'll see a dialog displaying the invoice details, including the requested amount and description.

Click "Approve" in the dialog, and when the payment is successful, you'll see the "Success Indicator" screen.

Click "okay" on the success screen, and you'll return to the home screen. Check the transaction information in the "Payments" tab.

That's how you pay an invoice and manage your Lightning wallet with ease. Enjoy the power of Lightning Network! ⚡

Payment Delivery

To make a payment on the Lightning Network, the recipient must first create an invoice to receive the payment. This invoice encodes essential information, including a unique payment identifier (payment hash), the payment amount, and an optional text description.

The payment hash within the invoice plays a crucial role by enabling the payment to be routed across multiple channels. This means that payments can be made even when there's no direct payment channel between the sender and the recipient.

In our example, we don't have a direct payment channel with the Eclair Lightning wallet. However, we do share a payment channel with the PLEBNET.DEV Lightning node. The Eclair wallet also has a payment channel with the same PLEBNET.DEV Lightning node. Therefore, when we send or receive funds to and from the Eclair wallet, we're effectively routing our payment through the PLEBNET.DEV Lightning node.

So far, we've covered sending and receiving on-chain transactions, opening payment channels, and sending and receiving funds on the Lightning Network. In the next section, we'll explore how to close a payment channel.

Closing a payment channel

In the Lightning Network, closing a payment channel may come with on-chain transaction fees. Therefore, it's generally advisable to keep channels open for as long as possible. Rebalancing the channel allows for continued use and an unlimited number of payments.

However, there are situations where closing a channel is necessary. This can include reducing the balance for security reasons or when the channel partner becomes unresponsive.

To implement channel closing in our wallet, locate // TODO: Implement method to close a Lightning payment channel and replace it with the following code:

  Future<void> closePaymentChannel({
    required ldk.ChannelId channelId,
    required ldk.PublicKey nodeId,
  }) async {
    await ldkNode.closeChannel(
      channelId: channelId,
      counterpartyNodeId: nodeId,
    );
  }

The closePaymentChannel method is used to close a payment channel with the specified channel ID and counterparty node ID.

Now, just perform a hot reload of the app. Go to the "Channels" tab, and click on "CLOSE" on the channel's ListTile. A dialog will pop up for confirmation. Click "YES" there, and when the channel is closed, you'll see the success screen displaying the channel ID that was closed.

Closing a payment channel can be a necessary step in managing your Lightning Network wallet and ensuring the security and flexibility of your funds.

Node and Channel Backups

As we continue our journey, it's important to note that we don't currently have a channel backup mechanism in place. All the data related to node and channel states are stored locally in the storagePath as defined in the createOrRecoverWallet method.

This is actually a very important consideration when running a Lightning node, is the issue of backups. Unlike a Bitcoin wallet, where a BIP-39 mnemonic phrase and BIP-32 can recover the entire state of the wallet. However, in Lightning, things are a bit more complex.

Lightning wallets do use a BIP-39 mnemonic phrase for on-chain wallet backup, but this phrase alone is not sufficient to restore a Lightning node. Channels, which are a fundamental part of the Lightning Network, are constructed in a way that the mnemonic phrase can't fully restore a Lightning node.

And also, when it comes to channel state backups, there's no standardized approach that every Lightning wallet follows. Some wallets store channel states on Google Drive, some on their own remote servers, and others store them locally on the user's device. Each of these practices carries the risk of data loss and data inconsistency risks.

So there is no consistent backup mechanism across different Lightning node and wallet implementations. Hence, you should not store large amounts in a Lightning wallet. Large amounts should be kept in a cold wallet that is not online and can only transact on-chain.

It's crucial to keep this in mind to ensure the safety and security of your funds when operating on the Lightning Network.

Incoming Channel Opening Requests Struggle

During the development of this project, I encountered a significant challenge related to incoming channel opening requests. I initially struggled while attempting to build the node in the createOrRecoverWallet method, particularly when using the .setListeningAddress method on ldk.Builder(). To enable incoming channel opening requests, it's essential to set the listening address by specifying the IP address and listening port for the node, allowing it to listen for incoming channel requests.

However, after extensive efforts and seeking guidance in the LDK Discord channel, I learned that running a node configured to listen for incoming connections is not a viable approach for mobile phones.

Setting the IP address to the mobile device's IPv4 public address, which essentially corresponds to the ISP's address, presents challenges. This IP address is not stable, and many mobile providers place end devices behind NAT (Network Address Translation), further complicating the situation.

In the words of @tnull, "if you don't want to go out of your way to implement hole punching or similar, I'd generally recommend disabling the listening port on mobile devices and relying on outbound connections only."

You can find the complete communication on this topic here(https://discord.com/channels/915026692102316113/978829624635195422/1155768160197279744), where @tnull provided a detailed explanation of this issue.

Also, benthecarman suggested that the "best approach is probably just not calling setListeningAddress." This is the approach I followed in the createOrRecoverWallet method.

For these reasons, we cannot have incoming channel opening requests on mobile devices. It's crucial to be aware of these limitations and work within the constraints of the mobile environment when developing Lightning Network applications.

Conclusion

As we wrap up this journey into the fascinating world of the Lightning Network, I want to express my deep thanks to the amazing team working on the LDK node project and all the dedicated developers who have contributed to the development of BDK and LDK. Your hard work not only opens new doors but also supports developers like me who are diving into the potential of this incredible technology.

The Lightning Network isn't just a technological advance; it's a game-changer that promises faster, cheaper, and more efficient Bitcoin transactions. It unlocks countless possibilities, from tiny payments to decentralized finance and beyond.

But remember, this is just the start. The Lightning Network is a vast and exciting world with endless opportunities. I encourage all readers to keep learning and explore further. Embrace this technology, experiment with it, and let your imagination run wild. The Lightning Network is a wave of innovation, and you have the chance to ride it.

If you have questions or want to connect and share your experiences, feel free to reach out to me on Twitter, Nostr, or LinkedIn.

Thank you for joining me on this journey. ⚡🌊

DEV Community: Aniket Ambore

Tutorial: How to Develop a Nostr Wallet Connect Mobile App Using Flutter and NWC

Getting Started

Project Files

Assets folder

Folder structure

State Management (BLoC)

Component Library Folder

Handlers

Models

Routes

Services

App Libraries

NWC Initialization

Monitoring Changes

Inside the Constructor

Connect

Initializing Relay and Handling Events

Publishing Events to Relays

Connecting a Lightning Wallet

Obtaining the Connection URI

Understanding the Connection URI

Command: get_balance

Formatting and Refreshing

Command: make_invoice

Listener in create_invoice_page.dart

Handling Errors in NWCAccountCubit

Command: lookup_invoice

Inside _startPolling() method

Listener in invoice_qr_page.dart

Command: pay_invoice

PaymentRequestDialog in payment_dialogs/payment_request_dialog.dart

Using payInvoice in UI Flow

Testing the Flow

Conclusion

Clipboard Monitoring for Bitcoin Addresses in Flutter

Introduction

Use Case

Getting Started

Clipboard Manager Implementation:

Main App Implementation

Address Validation

Clipboard Watching

Homework and Conclusion

Tutorial: How to develop a Non-Custodial Bitcoin Lightning Wallet using Flutter and LDK?

What is Lightning Network?

What is Lightning Node?

What is Lightning Wallet?

Getting started

Project files

Assets folder

Folder Structure

Component Library Folder

Domain Models Folder

Features Folder

Wallet Repository Folder

App libraries

Wallet Initialization

Import the Necessary Packages

Initialize Wallet Configuration

Generate a New Mnemonic

Create or Recover a Wallet

Retrieve Wallet Information

Get Lightning Node ID

On-Chain Functionality

Retrieve On-Chain Address

Retrieve On-Chain Balance

Send On-Chain Bitcoin

Opening Payment Channel

Creating BOLT11 Invoice

Paying an invoice

Payment Delivery

Closing a payment channel

Node and Channel Backups

Incoming Channel Opening Requests Struggle

Conclusion

Listener in `create_invoice_page.dart`

Handling Errors in `NWCAccountCubit`

Inside `_startPolling()` method

Listener in `invoice_qr_page.dart`

`PaymentRequestDialog` in `payment_dialogs/payment_request_dialog.dart`

Using `payInvoice` in UI Flow