One last thought. Perhaps this is end game.
In a client app, when I add a relay as write, perhaps it sends a payment to that relay for 10MB. Then as you use data, maybe there is a way to monitor usage and pay for more - app automated (with budget) or with approval.
In a way, it could all be automated. Relays get paid as people add and use them, you pay more based on usage. You get redundancy controls. You drop a write relay and at some point your events get turned over.
That's exactly why I want to test this approach. If there's a way for users to monitor their usage and for payment to be automated when they need more storage, the whole process can be seamless. I think this may take some time, but I can see it happening in the future.
In theory, I could monitor their usage and create some kind of automation whereby, if users don't have enough storage, they would receive an alert in their DMs along with a payment link.
I have one working we relay which is using this exact model but it's just for testing right now.
I think the full solution should not trust relays about how much they are storing, and include a proof of storage/retrievability/data check.
I imagine clients can even keep a Merkel or some hash, and even store it as an event, linked to that relay. And a nonce check or similar can help a relay prove they are least storing those event ids. Maybe a way to expand to covering whole event too, without the client storing all the data.
One edge case is what if someone broadcasts your event. Who pays? And can someone broadcasting events on mass trigger relays to ask for more money from the pubkey, who didn’t broadcast or publish.
