Thanks for a nice and detailed post @sergei-tikhomirov .
I agree with almost all points, but have few concerns/comments
Wondering if point-2 falls under the scope of point-3 i.e interaction between Waku-based project and its end-users. Because typically in the waku-network light-clients will only be used by applications build on top of Waku.
So, why the segregation of these 2 points?
Do you see any other use-cases where lightClient usage of waku is independent of any project?
This will add a lot of overhead to lightClients, considering they are supposed to be light in nature. Currently, without incentivization it is just a single req-resp protocol to send a message via lightpush. But with this proposed change, in order to send a single message via lightpush a client has to perform almost 3 additional req-resp with various node in the network that will add lot of latency and may deter users from using this service. Instead a bulk payment option would suit better for a lightpush client, where either they pay ahead for a certain rate-limit from the serviceNode. This way for a light-client, the overhead for each message would not be that high in comparison to what they have today. Since waku is not to be used for sending large amounts of data (i.e it is only meant for small messages, this approach would deter usage of Waku) especially by light-clients considering they run on mobile/browser mostly.
I understand your reasoning for not considering bulk payments approach is due to the fact that a server can just vanish after taking payment and hence the client is at loss. In order to mitigate this, can’t we use the escrow model proposed post MVP where payment is held to server until client acknowledges service is provided? I see that this complicates the system little more, but it simplifies the flow for sending a message.
I am assuming for the MVP the payment channel be fixed. It would make the implementation of MVP also simple.
Any steps taken to protect the client since payment for sending a message involve monetary transaction, would be better to have some very simple approach of protecting the client as well.
Haven’t gone throught he post-MVP part of the post yet. Will go through again and reply separately.