You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently you can only set different amounts for different endpoints, but this means that all requests to one endpoint cost the same.
This can be improved upon, for example when there's a translation API, a per-character-billing would be the most dynamic billing possible.
This could be achieved by having a new set of middleware factory functions, which don't take wall.InvoiceOptions as parameter, but a func (req http.Request) (int64, string), which can determine the cost according to the amount of characters (or whatever) in the request body or query params etc.
So not just the amount, but also the memo could be dynamic.
Attention though: Currently it's possible (and nice, and common in other LN paywall projects) to first send a request only to the URI, without body and without query params.
In order to prevent the client from cheating (send request with view characters first, then one with many more after the payment), something must be done like: Cache the price of the invoice after the first request, then recalculate the price after the second request, make sure the amounts match.
Currently you can only set different amounts for different endpoints, but this means that all requests to one endpoint cost the same.
This can be improved upon, for example when there's a translation API, a per-character-billing would be the most dynamic billing possible.
This could be achieved by having a new set of middleware factory functions, which don't take
wall.InvoiceOptions
as parameter, but afunc (req http.Request) (int64, string)
, which can determine the cost according to the amount of characters (or whatever) in the request body or query params etc.So not just the amount, but also the memo could be dynamic.
Attention though: Currently it's possible (and nice, and common in other LN paywall projects) to first send a request only to the URI, without body and without query params.
In order to prevent the client from cheating (send request with view characters first, then one with many more after the payment), something must be done like: Cache the price of the invoice after the first request, then recalculate the price after the second request, make sure the amounts match.
This also requires #16 to be fixed first.
The text was updated successfully, but these errors were encountered: