pull down to refresh
0 sats \ 3 replies \ @k00b 29 Jul 2022 \ parent \ on: Geyser campaigns now have lightning addresses and project QR codes bitcoin
The hard part of this is that every tip on LN address forwarding post would effectively be a withdrawal from the user tipping.
- Who pays for the fees on a 1 sat tip when every tip requires routing? It shouldn't be the tipper. If it's not the tipper, then forwarding can't occur in realtime and the sats have to buffer on SN until the post receives enough sats to pay for its own fees. How big should be buffer be before it sends? 10 sats? 100 sats?
- What if the buffer never fills?
- What if the withdrawal fails? Where should those sats go?
hey @k00b, it's Stelios from Geyser. Implementing this would be a challenge for sure but also really cool! A buffer makes sense and you raise good questions. Initially the buffer could be low-ish for the proof of concept (like 100 sats).
If we assume both ends (geyser and SN) are custodial at first, then the buffer should fill up eventually (and likely fast). If one (or both) ends are non-custodial then the buffer may be slower to fill and it gets more challenging.
Another question is: what if 10 users contribute to that buffer before it fills?
Then there's a single lightning transaction but we want to show all 10 users that contributed in the Geyser activity feed. So we need to pass some additional information alongside the transaction as well.
We could use the TLV field for that. Eventually maybe we can come up with a standard that facilitates inter-operability between all V4V platforms rather than just SN <> Geyser. What are your thoughts on this?
reply
Embedding metadata seems downstream of simply figuring out how to make it work though. I also wouldn't want to doxx every user that tipped a story, so not something I'd implement. I'd only want to send, if anything, the nym of the user who decided to forward their tips.
As for getting something working, it sounds like we need a buffer at the very least, which I don't currently have logic for and will be difficult to get right.
reply
Metadata comes second for sure. Making inter-operability between lightning services work is the key part.
Bringing SN and Geyser together can also serve as a blueprint for others. How do we make an implementation that works both for SN and everyone else? Can we abstract it into something re-usable? Will be giving this a thought...
reply