A topic I'd like to bring up in Saturday's Podcasting 2.0 meeting: what are best practices for handling tiny boost transactions?
You are boosting a value of 100 sats for a podcast. If you're boosting No Agenda, the current splits are:
Which adds up to 101, so the values would end up being split as:
Since we can't send a fraction of a sat, what should we do with the remainders?
Also, should we even send a micro-transaction below 10 sats?
@brianoflondon I think the problem we are running into makes a case for the type of transaction service you're proposing.
@mitch Podfriend evens it out and "Robin hoods" from the share that will get most sats.
But in the future I could imagine that I will save up the transactions until a certain minimum instead.
But as you say there's some drawbacks with every solution.
@martin yeah I think the robinhood method is a reasonable way to address the problem.
We could of course carry values over as remainders...but that introduces complexity into the UX for rendering the remainder information to the user. People will see transaction receipts that don't add up to 100, and then receipts that suddenly do add up to 100 or more, and they'll wonder why.
@mitch I set my new node up at home and put it in my feed.
I can't get a single sat to arrive by listening to my own show. Very hard to know why.
I think the rounding problem is also very real and minute by minute streaming is not going to be practical.
@brianoflondon yeah rounding has been a real doozy for us.
Minute by minute does not seem to be much trouble for us because we are batching transactions and sending them every 10 minutes.
The only reason why we're not saving Boost remainders and batching them later is because there will be an expectation by the user that a boost will be sent immediately. If we start carrying over remainders, that info has to be communicated to the user somehow, and it seems like a headache over micro-payments
The values that sit in our streaming transaction queue that don't add up to 10 sats per address just sit there until they reach 10 sats. This queue is cleared on app close and launch, so it's a clean slate every app launch. Not a perfect solution, but for now we'd rather send too few payments than surprise the user with them.
@brianoflondon is this your RSS feed? I was going to try sending a boost to you, but don't see a <podcast:value> tag in the feed.
@brianoflondon just sent a boost to your experimental feed. It appears it succeeded?
There was an issue I had to debug though. The split value in your valueRecipients was a string value ("70.00"), and our logic was setup to handle it as a number, resulting in NAN when attempting to calculate with the split value. I've updated our logic to assume the split will be a number OR a string, and to run parseFloat on it in case it's a string. Maybe that is the problem other players are having?
@mitch I see it! Interesting. The spec says split is a float so that's what is there though I'm a bit unsure of quotes or not in xml.
Intended for all stake holders of podcasting who are interested in improving the eco system