Right now, the Github button calls a Javascript function to open a new tab to a URL. Instead, we should make the button an HTML tag so the user can see where the link goes when they hover over it.

• Show helpful instructions on adding a new device if the user doesn't have any yet instead of showing an empty list and info placeholder
• Reduce size of device name for selected device

We want customers to know that LightningVend is backing the device they're using. Let's think of a way we can do this that is subtle and unintrusive but still easy to find. We could incorporate the LightningVend name/logo into the screensaver, or perhaps add an info button to the UI that shows a QR code to https://lightningvend.com/.

We should have a screen saver that explains how to use the machine.

If a device boots while offline, it should still successfully display the UI

There are a few things that need to be touched up on the admin login page

• Fix the circular progress component that shows on initial page load. It's small and uncentered.
• Users currently sign in by signing a message using their lightning node. Under the hood, the unsigned auth message is a JWT containing an expiration timestamp. Right now, if the message expires the user can still paste a signed message in and attempt to sign in, but it will silently fail. We should make it clear when the message has expired, prevent the user from attempting to use it (i.e. maybe make it un-copyable) and add a button to refresh the unsigned auth message.
• We should add an info button that provides more info on how to login, showing step-by-step instructions for using Thunderhub or Ride The Lightning
• Toy around with the placement of the login box. It might look nicer if it's vertically centered.
• Show 'Copied to Clipboard' message when copying unsigned auth message

Currently the only ways we can update device inventory through the admin UI is by either appending a new InventoryItem to the end of the inventory list, or deleting an InventoryItem in the list. A user would expect to be able to:

• Edit an existing item
• Rearrange items (drag-and-drop?)

We should add support for this in the UI and also split updateDeviceInventory up into separate CRUD methods.

Needs this so the system knows where it is starting from.

Background

Under the hood, we're using LNBits for all payment handling. LightningVend users won't be interacting with LNBits directly, so we want to leverage the tools and primitives provided by LNBits to create a clean and intuitive interface for LightningVend users.

Constraints

We have desired behavior that will constrain our design:

• Payment splitting - This is an important aspect of fund management, so we should design around this feature from LNBits.
• Immutable payment split to LightningVend - Every device should have a fixed percentage of gross profit go to a single LNBits wallet that is owned by LightningVend. This percentage split should be immutable to the device owner.
• Per-device splitting - Users will likely want to be able to control payment splits by device (as opposed to by admin/user). This means we should have one LNBits wallet backing each device.

How wallets should work

A wallet can be thought of as a payment bucket. It belongs to a LightningVend admin and can be shared with other admins to add a payment split from their devices. A wallet should map to an LNBits wallet under the hood. Each device can have a list of wallets that each have a percentage set that defines how incoming payments for that device are split among wallets. We can use the payment splitting API to split the payments accordingly.

A wallet can be represented using the following proto:

message Wallet {
  // The resource name of the wallet.
  // Format: users/{user}/wallets/{wallet}
  string name = 1;

  // The display name of the wallet.
  string display_name = 2;
}

We can calculate a user's total amount of funds by iterating over all of their wallets and devices and summing up the total amount of sats.

TODO - Finish writing the description and fleshing out the design for this.

Questions we still need to answer:

• Do we want multiple wallets per device that can each be owned by a different user and take a different split (or flat amount per payment)?
• Should we have a default wallet per user based on login method? For example, the LN node for LN users, or a Zap wallet for Nostr users.
• How do we prevent wallets from silently being deleted for users who don't own the device? Is this a problem worth addressing?

This will hopefully encourage more user engagement by calling the user to action

• Finalize Arduino code
• Put label with link to Arduino code on the Arduino board inside

Currently we're storing all data (user and device data) in-memory, which means that any backend software update will wipe everything. Persisting data is MongoDB strikes a good balance between scalability, flexibility, and ease of developer use. We will need the following collections:

users: Contains all User proto resource instances

devices: Contains all Device proto resource instances

deviceEvents: Contains all unacked server-to-device events

We will also want to persist add_index and settle_index values to ensure that no invoice events from the underlying LND instance are missed from our SubscribeInvoices call during server interruption/disconnection/restart.

Allow users to login with their Nostr account instead of their lightning node. This would open up the potential user base since not many people run their own lightning nodes.

Nostr login could be done by allowing the user to paste in their public key and a relay address they're connected to, then sending a private single-use login code as a direct message to that user through the specified relay.

We should also be able to send funds to the user as a private zap. But we don't need to address that in this issue. If it's not addressed, let's make a separate issue to circle back on that feature.

Caught the error:

in.b40a5844b93c48eab63c.js:102 TypeError: t.nullCommands is not iterable
at main.b40a5844b93c48eab63c.js:102:537692
at main.b40a5844b93c48eab63c.js:102:498367
at ol (main.b40a5844b93c48eab63c.js:102:343103)
at ku (main.b40a5844b93c48eab63c.js:102:363225)
at main.b40a5844b93c48eab63c.js:102:359829
at S (main.b40a5844b93c48eab63c.js:102:468927)
at MessagePort.R (main.b40a5844b93c48eab63c.js:102:469459)
fs @ main.b40a5844b93c48eab63c.js:102
(anonymous) @ main.b40a5844b93c48eab63c.js:102
Fi @ main.b40a5844b93c48eab63c.js:102
xl @ main.b40a5844b93c48eab63c.js:102
wl @ main.b40a5844b93c48eab63c.js:102
bl @ main.b40a5844b93c48eab63c.js:102
(anonymous) @ main.b40a5844b93c48eab63c.js:102
Su @ main.b40a5844b93c48eab63c.js:102
uu @ main.b40a5844b93c48eab63c.js:102
Uo @ main.b40a5844b93c48eab63c.js:102
ku @ main.b40a5844b93c48eab63c.js:102
(anonymous) @ main.b40a5844b93c48eab63c.js:102
S @ main.b40a5844b93c48eab63c.js:102
R @ main.b40a5844b93c48eab63c.js:102
main.b40a5844b93c48eab63c.js:102 React Router caught the following error during render TypeError: t.nullCommands is not iterable
at main.b40a5844b93c48eab63c.js:102:537692
at main.b40a5844b93c48eab63c.js:102:498367
at ol (main.b40a5844b93c48eab63c.js:102:343103)
at ku (main.b40a5844b93c48eab63c.js:102:363225)
at main.b40a5844b93c48eab63c.js:102:359829
at S (main.b40a5844b93c48eab63c.js:102:468927)
at MessagePort.R (main.b40a5844b93c48eab63c.js:102:469459) {componentStack: '\n at https://lightningvend.com/main.b40a5844b93…vend.com/main.b40a5844b93c48eab63c.js:102:137466)'}
c

We're using Socket.IO for server/client bidirectional communication. Currently we're using untyped sockets, but the library supports Typescript typing for sockets.

Currently execution commands are only saved to DB for claimed devices, but there's no reason they can't be stored before being claimed. That would allow for devices that are claimed while offline to show commands right away in the admin UI.

Background and Justification

We already implemented client-to-server at-least-once delivery here. Doing the same for server-to-client messages is a bit more complicated since the server needs to store message acks somehow. We don't need to ensure at-least-once for admin server-to-client messages since the user can simply refresh the page, but it's important for device server-to-client messages.

Why is this so important?

Devices receive server-to-client messages when invoices are paid. At-most-once delivery can lead to the server attempting to tell a device to vend a product but the event getting lost in transmission, leading to a payment never resulting in a product vend. At-least-once delivery ensures that server knows when a client has vended a product. Similar reasoning follows for other device messages.

Relevant Info

• See Socket.IO's page on delivery guarantees for examples for implementing at-least-once message delivery.
• See AIP #162. We should add a revision_id to the Device proto.
• Each server-to-client message should be idempotent (since we're implementing at-least-once, not exactly-once) for the client.

Additional Work

Whenever a device is updated through the admin UI, we should relay when a modification to a device has been acknowledged by the device back to the admin UI. If the device relay fails (i.e. the device update isn't acked by the device), maybe we can display a retry button that, even if the write successfully persisted to the DB, re-sends a socket message to the device.

The landing page has a few minor things that should be tweaked

• There are features listed that don't exist yet. We should make it clear what's ready to use and what isn't. Perhaps we should move unfinished work to a 'coming soon' section.
• Add a brief description of payment splitting and the custody model we will use. We will receive funds to our managed node for incoming payments, but users can perform manual withdrawals to any Bitcoin address/Lightning invoice, or setup automatic withdrawals to any Lightning node with AMP support. Also mention that this is to ensure ease of use and high uptime since connecting your own Lightning node can be tricky. It also allows us to take a hosting fee and provide features such as payment splitting.
• On certain devices (confirmed on iPhone/Chrome), content appears below the center of the screen.
• On the top slide, we should add a downward facing arrow icon button to make it clear that the user can scroll down. Perhaps a list of dots with a highlighted one at the bottom of each slide to indicate what slide the user is on and how many there are in total.
• Mention that the project is 100% open source, and link to the Github repo.
• Remove "Lightning Network" from "The Bitcoin Lightning Network solution for vending machines" on the top slide.
• Change slide-in animation speed. This is referring to how each element slides in slightly after the one above it. Currently, each element on a slide has a fixed delay based on the element above it. For slides with many elements, this can lead to a long total animation time. Instead, we should dynamically set the delay so that slides with many items have a quicker delay than slides with few items.

Add arrows to show more content is below if they don't click on the Get Started button

The "Get Started" button on the landing page brings you to admin login right away, which is a bit confusing because a button like that typically will lead to a tutorial or detailed explanation of the product. Let’s make this button lead to a page like that, and add a normal "Login" button on the top right corner of the landing page.

We can likely reuse the component for admin auth message expiration. It could also be nice to add a refresh button to fetch a new invoice. If we do that, we might as well do it for admin auth messages too.

It could also be a better user experience if the screensaver doesn't come back until the displayed invoice expires.