A topic I'd like to bring up in Saturday's Podcasting 2.0 meeting: what are best practices for handling tiny boost transactions?

For example:

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?

· · Web · 1 · 0 · 0

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.

@mitch @brianoflondon Are you pulling the value blocks from us Mitch? If so, I need to put in some code to normalize all of those to be floats instead of strings.

@dave @brianoflondon we’re pulling from both the RSS and PI, so it depends if Brian is using or not I guess. If not found in the RSS, we query PI for a value tag. (I’m not by the computer to confirm this myself)

@mitch @brianoflondon Ok, I see that we are returning some string values. I'll fix that.

@mitch @dave that feed is manual. I'm keen to know if those float values should be in quotes in the xml or not? My feed is almost unique having a value block which podcastindex reads. That feed does not use podcasterwallet.

@brianoflondon @mitch Yes they need quotes in the xml. All xml attributes must be quoted.

@dave @mitch that’s what I thought there’s no way to indicate they're floats. OK. I'm doing it right.

Sign in to participate in the conversation
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system