pull down to refresh
105 sats \ 2 replies \ @steliosats 29 Jul 2022 freebie \ parent \ on: Geyser campaigns now have lightning addresses and project QR codes bitcoin
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?
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