STORY
🍴PPPs: Week 6 - ForkableRecipe.com
AUTHOR
JeffJeff
Joined 2022.09.20
PROJECT
Forkable RecipeForkable Recipe
DATE
VOTES
sats
COMMENTS

🍴PPPs: Week 6 - ForkableRecipe.com

Plans 📆

  • Iterate on security/implementation/withdrawal of money-related stuff

    • It's not as smooth as I'd like yet, and I need to learn about state of LN transactions better

  • Load 70+ recipes into the site

  • Prepare GTM

  • Bootstrap Hello-World of an Object Oriented API

Progress ✅

  • ✅ As planned - Got basic withdrawal interface setup.

    • Bonus - Users can request a withdrawal, if and only if they have a lightning address populated in their profile.

    • Bonus - Got basic withdrawal interface setup. Users can request a withdrawal, if and only if they have a lightning address populated in their profile.

    • ❌ - Automated withdrawals aren't turned on, they are in a wizard-of-oz setup. I'm going to manually trigger the first handful, maybe for the first few weeks, because I don't yet feel comfortable with my knowledge of prevailing attack vectors.

  • ✅ As planned - Expanded out the recipe parser, fixed some bugs. It now parses cookware, and source (this is a response to user-feedback!), as both are more important to users than I expected.

  • ✅ As planned - Setup "Cookbook" and "Cook" views for non-technologists to use the site. It's basically just a trimmed down interface, excludes all technical details.

  • Bonus - Sent a PR to the Ligess lightning address project, as a token of appreciation.

  • Bonus - Expanded on lots of the docs. This is early prep for content to help with GTM.

Problems / Questions ✋

Q1 - I felt I needed to confirm, and possibly only show, users their "Settled" payments. Is there a reference somewhere that shows the lifecycle of other states? Is this Settled term, an LND-only thing? Or is there error codes? I picked it up from the response from polling my node for status. Are their definitive failure modes?

Q2 - Because I was designing, learning, and building in parallel I ended up with a table called invoices and outflows. There are a few identifiers, hashes, and secrets, associated with transactions visible in LND hub. Are their any that I should intentionally avoid storing in my app's db? Are their any that I should, that might not be intuitive? Eg. should I keep the full BOLT11 in my app's DB? Am I creating a security risk if I store the secret? I'm assuming I would be, so I'm not, but wondering if I will kick myself later for some reason because I won't be able to reconcile my node against my app or handle problems reported by users.

Q3 - Does anybody have guidance around what might be helpful to expose to users, related to LN? If I was using Layer-1, I would obviously show the relevant to/from addresses, maybe fees too, probably hide everything else or link out to a block explorer. But it's all new for lightning to me. Should I just leave the technical parts abstracted?

  • TODO: Go look closely at other apps and wallets experimenting in the system.

Q4 - Are most app-devs putting LNBits between their lightning nodes and their app? I didn't. Did I screw myself somehow, by re-inventing a bunch of CRUD that will be hard to maintain or have bugs?

Links 🔗

  • Cookbook Mode - Example: https://forkablerecipe.com/jeffrey/book

    • Accessible from the book-icon on a user's profile page

    • Notice the single lightning button, direct to that user.

  • Cook Mode - Example: https://forkablerecipe.com/jeffrey/berry-smoothie/cook/branch/main/recipe.cook

    • Accessible from drilling into any recipe from the cook-book mode (see above) or by changing src to cook in the URL on any .cook file (for any branch/tag ... just like github).

    • Notice the single lightning button, only direct to that recipe.

  • New view (logged in users only): The Money-Tab in User Settings, with balance, inflows (with recipe-attribution), outflows, and request to withdraw.

  • Expanded Docs