I’ll go with my recommendations but Prem and Tanya may differ in opinion, I invite them to share their thoughts below.
Authorization Abstraction
Design and implement Auth. for every light protocols. We need a system that is agnostic to the Auth. method used. We have been focusing on payment but it’s a sub-category of Auth, we also want the ability to provide the service for free or gate it with ZK proofs.
The first Auth. method implemented should be “free for all” the second Sergey’s POC TXs verification.
We also need to answer questions like
Do we need to modify the light protocols?
Are light protocols too different to use the same abstraction?
What is the cost of adding this abstraction?
How does it mesh with the DOS protection mechanism already in place?
Probabilistic micro-payments
Do more technical research and implement it. Seams like we are targeting Status L2 with gasless TX but I’m pretty sure any smart contract platform would work once the technical details are nailed down. Other projects building on Status L2 would also benefit from a micro-payment library.
Micro-payments help us deliver better UX and scalability.
I’m not sure if this classifies as “too different” (research needed) but Lightpush is a one-time service, while eg. Filter is an ongoing subscription, which means that the latter would need to be billed by time (or by number of messages, or my volume of those messages?). This is more complex than a simple Lightpush scheme of “one payment = one message published” (or, a bit more generic, one payment = N messages published".
I agree that micropayments seem the appropriate way to pay for services considering waku service use-cases where there is a constant use of services by a user. Providing service incurs a low cost on service provider per usage(i.e sending lightpush message(s) would be a fraction of cost the service provider had to invest in RLN membership).
But i am not clear on why we need Authorization and if so what would be scope of it.
Are we talking about content-topic(s) level auth or in general auth to use a waku service itself i.e lightpush or store?
If we are talking about auth specific to content-topic(s), then wouldn’t that fall under the scope of application (e.g status)? Apps would already have some sort of an auth list and it would make sense to plug into that rather than building another level of Auth at service layer.
Also i am wondering if it is necessary at this point to design and implement Auth as we want to first build marketplace for waku services. Assuming micro-payments are being implemented for service access (even if we need to provide a free tier - i am assuming it would be possible to do this), what else do we need the auth for? If for preventing spam at service layer, we already have some rate limits implemented per service which should be sufficient to handle this.
Currently services cannot be gate kept there’s no way to prevent edge nodes from connecting. We need to build something to fix this.
Micropayment will be ONE of the auth methods. I argue that FFA should be the first method impl. since the status quo would not change and it’s easy to build.