LNFly is a bit different, it's a one-shot prompt that really gets you to focus on the idea and rules of the app you're trying to make. This is really another layer of abstraction on top of a high level programming language. Here's the current prompt for the lottery game:

Make a bitcoin lightning lottery app called "blotto" where you can buy lottery tickets for 210 sats each. Each time someone pays, the timer until a winning ticket will be called increases by 10 minutes.

When requesting to buy a ticket, the backend should generate an invoice using NWC. Once it is paid by the user (with bitcoin connect)

the frontend should do a call to the backend to verify the invoice was paid, and if so the ticket should be displayed to the user and give them a way to download the ticket. The filename of the ticket should be "BLOTTO_<game ID>_<public ID>.txt" and the contents should be the hidden ID.

Make sure the current buy button is replaced by a download ticket button (which should have a different color and should flash until the user clicks it). Once they have downloaded the ticket, there should be a secondary button below: "buy another ticket".

The backend MUST verify the payment was made by lookup up the invoice, before returning the ticket to the user.

If less than two tickets have been purchased, the timer should not start.

Each ticket should have a public ID (a simple sequential ID starting at 1) and a hidden ID (a long random string) that the user can use to redeem the winnings.

The winnings should be the rounded down value of the total number of tickets * the ticket price * 0.95.

The countdown timer should show on the main page.

When someone is on the page, every 10 seconds it should poll an endpoint to check the timer. On the page it show show a smooth countdown.

There should also on the page show the number of PAID tickets purchased and the prize pool (calculated from PAID tickets only)

If anyone buys a ticket, there should be a "timeout increased!" animated text which will be shown to anyone currently viewing (not just the user who bought the ticket).

The tickets and end date should be saved on the backend.

Once the endpoint to check the countdown timer is called and the countdown is finished, show the winning ticket (public ID) and allow users to attach their ticket file they previously downloaded (using an input field) and their lightning address to claim the prize.

If the prize is not claimed within 24 hours, the game should be reset. Also show a countdown of time to claim the prize.

If the ID matches, the backend must use Nostr Wallet Connect to pay the prize to the provided lightning address (using lightning tools to fetch an invoice) and then reset the game.

There should be a way to view previous games: (Date ended, Tickets sold + Prize pool in sats + winning ticket public ID + whether the ticket was claimed or not)

Style the game with a fun, lightning lottery theme. Make sure the content is vertically centered if it doesn't full the entire height of the screen.

New version here: https://lnfly.albylabs.com/api/apps/60/view also with a claim countdown of 24 hours

New version here: https://lnfly.albylabs.com/api/apps/60/view also with a claim countdown of 24 hours

Looks like someone didn't claim their prize yet

The promise with Firebase Studio (and Also Replit) is great because you can build a full-stack application and deploy it without a local development setup.

I tried it a few days ago but was pretty disappointed. It cannot do external requests to get up-to-date information and was working with super-outdated packages.

Currently it does not compare at all to Cursor/Cline/Roo Code etc. Hopefully it gets better because this really makes it easier for people to get started building apps.

That's right. But the custodial users need to know that the credit balance cannot be spent like normal sats can.

Hmm, to me this looks like the connection to the relay was dropping and not re-connecting properly, and from the log requests were published when the relay was not connected, and also it was waiting for a response after a relay disconnection. is this possible? @ek

Did you manually update? v1.11.2 was just released on github, but that does not mean your hub was immediately updated. But the update should not have broken old connections.

Hi, you can go to the node page -> channels and click "Open Channel" then click advanced. Look for LNServer_Wave which is a cheaper LSP.

Or you can disconnect from getalby.com/node and then move your sats elsewhere if you would not like to switch to a self-custodial wallet.

Nice guide! soon we will make this easier, with the ability to top up isolated app balances from within Alby Hub, and also to generate basic lightning addresses for isolated apps. That way, when you onboard someone they do not have to immediately sign up for an Alby Account.

NWC is actually a big part of Alby Hub, not just for the self-custodial aspect but the idea of seamlessly connecting your node to all your apps you use. "Bring your own wallet" to many apps, similar to the "Bring your own client" idea we see in Nostr and Podcasting.

We are seeing a trend over time that more and more apps are integrating lightning, and rather than having separate inbuilt wallets per app, we see the ability for apps to seamlessly connect to your wallet as a superpower.

Soon Alby Hub will show more stats about usage across apps - for example in the transaction list you can already see what apps make what payments. Alby Hub will really show what is possible with open source programmable money.

@bumi worked on this for Phoenixd (https://github.com/getAlby/hub/blob/master/scripts/linux-x86_64/phoenixd/README.md) and there is also a dedicated Alby Hub Phoenixd for Umbrel. For LND, this is already the case for Umbrel and Start9 and is the default install. Start9 will also support picking between LND and LDK at startup without having to configure anything else.

But yes, we would recommend the default backend (LDK) for most people unless they already have a lightning node.

I guess it's the 354 sats channel reserve for Megalith channels. You can see it on the "Node" page inside Alby Hub.

1.7 has been released now with the Friends & Family app, so do try it when you get the chance! it'll be even easier as the Alby Go mobile app becomes generally available, as this is the simplest wallet interface to use as an onboarded family member or friend.

Hi, to answer some of your questions:

Thanks very much!

For the logs, you'd have to change the log level. This will be difficult currently in Alby Cloud, but if you run Alby Hub self-hosted you can change the LDK_LOG_LEVEL environment variable (e.g. LDK_LOG_LEVEL=1 to enable trace logs).

I really appreciate that, thanks.

What do you mean by the wallet being locked? this does not sound good!

In this case, due to such a rapid jump in fees, there was a big difference between fee estimates for different block confirmation targets, and different node implementations used different confirmation targets for the fees.

We have a workaround in place for Alby Hub as we run a blended fee estimator, so this particular force close issue will not happen again.

I don't believe it's a channel size issue, and Alby Hub users have full control over their channel management. You can open channels with whoever you want. If you decide to buy a channel with an LSP, then yes we help users there to make things simple to get started.

Also, if you don't use the wallet any more and have no channels, you can import the seed into Sparrow wallet and send the sats out from there (only recommended if you are not actively using Alby Hub)

Sorry about this. The withdraw function a bit broken (it didn't set aside enough fees to pay the onchain transaction) and will be fixed in 1.6.0 (released on github) which should also go out to Alby Cloud in the next few days.