Day 3 of the Chaincode Labs Lightning Residency

Building Lightning into Bitrefill

Justin Camarena

Effective Lightning Node Management

Alex Bosworth

Channel Management

Payment Routing on Public Channels.

Building Zap — a look under the hood

Jack Mallers

  • Allow a team to move faster
  • Only write code once for iOS/Android
  • Improve upon the developer experience
  • Highly ambitious, immature and moves fast. Building on LN is already very fast moving, find a stable base for your UI.
  • Still requires native development (native modules), not 100% portable cross-platform.
  • Performance and app size not as good as native.
  • Attracting contributors is difficult.
  • Flowtype
  • Eslint
  • Stylelint
  • Prettier
  • Coveralls
  • Storybook: designs should be separate from app runtime, faster iteration
  • Github
  • Travis
  • AppVeyor
  • Electron-Builder
  • GoReleaser
  • Electron + React
  • Local LND with neutrino + remote node + BTCPay
  • Write code once for all platforms
  • Strong community support
  • More favorable and flexible for designers
  • Reusable components for potential/future web apps
  • gRPC
  • REST
  • Continually track HEAD
  • Manage our own LND fork
  • Ability to bundle pre-built binaries with our codebase (developers don’t need to set it up themselves)
  • Ability to bundle binaries with experimental features enabled that are not available in released binaries.
  • Ability to bundle binaries with new / upcoming / unmerged PR’s
  • BTCD
  • LND
  • Docker
  • Kubernetes
  • Google Cloud
  • All infrastructure components versioned and deployable with a single command
  • Responsive design
  • Touch and mouse support
  • Multi-touch “pinch” / “zoom” gestures
  • Fixed pricing of 1 sat per pixel
  • No limit on pixels drawn
  • No “owning” pixels
  1. Welcome screen
  2. Avoid cluttering the UI.
  3. Minimum 3 clicks for invoice, look for shortcuts!
  4. Reactive.
  5. Reduce barriers of entry, no account creation, no extensions
  6. 16 colors to keep things simple and minimize image size
  7. Could add animations and sound effects to make it even better
  • Lightning node: access the LN
  • Backend server: handle business logic and expose socket API
  • Database: store settings, orders, and base64 png representation of canvas
  • Web server: serve client applications
  1. Visit draw and submit
  2. Request is sent to backend server.
  3. New order is received, validated, invoice is created and order is saved in database
  4. Receive a payment request and node info
  5. Route to node?
  6. Yes Pay
  7. No Open channel and wait
  8. Get payment notification and see result
  9. Payment received, fetch order with payment request, update canvas
  • Encoding pixels to PNG
  • Prune old orders, delete non-paid invoices that have expired
  • Request limit API: rate limit by IP address
  • Word of mouth
  • SBC lightning node
  • Eclair wallet was helpful
  • Testnet to prototype
  • Daily database backups
  • Websockets to create a reactive experience
  • Docker
  • Community of developers helped
  • Telegram group devolved into trashtalking and altcoin shilling. Have to moderate communication channels.
  • Saving image to database, would’ve been better to save canvas as an image in S3 to save bandwidth
  • Missing message broker and payment watcher. A message broker is needed if the API is scaled to multiple instances so that client <-> backend messages can be routed properly. A payment watcher is needed to process the payment only once.
  1. Iterate on your initial ideas
  2. Keep it usable
  3. Keep it simple
  4. Deploy early
  5. Collaborate
  7. Have fun!



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store