There is now a new parameter for the "search/byterm" endpoint called "valueonly". If this parameter is present then the search will only return feeds that have a value block:
https://api.podcastindex.org/api/1.0/search/byterm?q=agenda&pretty&valueonly
This fits the existing scheme better for this endpoint and avoids the annoying unary params.
@dellagustin @martin Open to anything on that front. Maybe valueType=* ?
@dellagustin @martin Or valueType=any?
@dave @dellagustin I like the name "valueType" - Would "any" not just be the same as omitting it? (I guess it's fine enough to have a default value for it)
@martin @dellagustin Omitting the parameter altogether, or do you mean just leaving it blank, like "valueType="?
@dave @dellagustin I meant omitting the parameter all together. I am unsure if there is a "standard" for "all" or "any" in web-apis, I think I have always gone with "all" myself, but I think that's more habit than anything else.
@martin @dellagustin Omitting it altogether would be a normal search that includes everything in the index. I think valueType=all would be good. That would give you only feeds that have some sort of value block attached, but without limiting it to lightning or hive, etc.
@dave @dellagustin Ah yes, logical fallacy there for me. I agree that "all" should return all feeds that have a value block no matter the "method". However, then I think it would make sense in the result to indicate what kind of monetization/payment type it supports (can it be multiple?).
@martin @dellagustin Good call on that.
@dave @martin @dellagustin is lightning explicitly mentioned in the rss value block? I seem to remember only seeing keysend
@brianoflondon @martin @dellagustin It's specified as a possible "type" in the <podcast:value> element. I don't think there is any language around it though.
@dave One quick feedback to that, is that I would try to avoid abbreviations.
Maybe "onlyValue=lightning" instead?