How can we improve the connect wallet flow? with Alby or Coinos it's a couple clicks to connect the wallet, with a budget set.

Developers can focus more on their project and less on coding. https://freepilot.albylabs.com/about

You can also have bots working on more than one issue simultaneously.

The tool isn't perfect, but it's great to see an initial implementation and then make minor edits to it.

It also makes you think more and put more effort into writing a good issue description, which can save time when compared to jumping into the code and then realizing later you didn't consider the problem fully.

The idea is that we don't know the cost in advance - and stream micropayments until the job is complete.

This is an alternative to topping up credits (how much? you don't know) and the subscription model.

The Blotto game is over! Winning Ticket: #13876 Winnings: 239812 sats ($262 USD) Total tickets purchased: 10023

Claim your prize within 24 hours at https://lnfly.albylabs.com/api/apps/199/view and click “view previous games”

The Blotto game is over! Winning Ticket: #13876 Winnings: 239812 sats ($262 USD) Total tickets purchased: 10023

Claim your prize within 24 hours at https://lnfly.albylabs.com/api/apps/199/view and click “view previous games”

Nostr punchcard - enter your npub to see your last 12 month's history, similar to Github activity graph, but mobile optimized and for posts, replies and reposts.

could you give more context? is this a sub wallet inside Alby Hub? could you send some additional info to Alby Support (https://support.getalby.com/)

I had to refine the prompt quite a few times. But LNFly generates an application from a single prompt.

What I think is interesting is the prompt is all game rules and almost has no references to things that only programmers would know. I think this is super powerful!

I'd attach it here but I think it's too long - I can't seem to send the reply.

Blotto is not open source. It's prompt is open source (You can find Blotto V2 on https://lnfly.albylabs.com/ and click the "Fork" button), and LNFly is 100% open source (https://github.com/getAlby/lnfly). I didn't make the app backends open source yet - but I probably can do that.

The old version with 198 tickets purchased was here: https://lnfly.albylabs.com/api/apps/60/view

It could have been done that way. But then Blotto would need to store all LN addresses and increases friction to buy tickets

You should be able to say exactly that e.g. “create a messageboard app where users can pay 21 sats to leave a message. The messages should be saved in the backend.”

Did you use Claude Sonnet 4 as the model? This will give the best results.

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