pull down to refresh

Thanks k00b, good questions.
LN as transport is something I'm exploring. I want to use it as much as possible, but I think for some use cases I might have to use it only for signalling and transfer actual data over something else, like a websocket.
On the one hand, it has some interesting benefits, like:
  • you only need a pubkey to contact someone (they could change IPs, switch over to tor and back, etc -- still reachable via same pubkey)
  • "data bound to payment" = cost of sending = native spam prevention
  • "data bound to payment" = receiving data implies receiving a payment = economic incentive to offer services (for which the inbound messages can be "requests for service")
On the other hand, limitations:
  • latency: you can't quite "stream data" over LN (maybe not yet? or maybe its not necessary, a side-channel can be used for low-latency requirements?)
  • bandwidth: same as above
  • payloads are persisted (indefinitely?) as invoice metadata in the LND DB = could eventually clog the DB
  • makes one-to-many scenarios harder to implement (a chat group where each message = N payments, one to every other group participant, makes no sense)
  • same for many-to-many
Will probably end up using it as a hybrid (transport in some cases, signalling in others).
Don't think this can help much with decentralizing SN though.