We're having a hard time finding a clean solution for this problem. It seems like any direction we choose in has significant trade-offs. Would love to share more info and get feedback from the community on the approach we're thinking of using.
@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
@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