Thanks for a thorough overview and plan! Some comments:
RLNaaS…does have a number of risks
Minor note, but I think a major risk of this approach is that it changes the topology around which we’ve designed protocols by forcing all publishers to an RLN-controlled shard to become lightpush clients only, without also contributing as relay nodes.
RLN for end users…this would involve more UX/UI work
Is this necessarily the case? If we deploy paymasters or a stealth commitment scheme in the interim, I imagine it would be possible to hide the entire RLN membership registration and distribution mechanism from end users.
I have reviewed how breaking changes on Communities are easier to handle…Which is not the case for breaking changes of 1:1 chats.
Wouldn’t it be possible to follow a similar approach to your Communities suggestion for 1:1 chats that will minimise the impact of the change in the same way? RLN-controlled chats can be rolled out as a new type of DoS-protected chat only available to users that have updated the app. It would be logically & visually separate from your “legacy chats”. Even for communities, every community member would need to update to the latest app version to participate in the new RLN-controlled communities, so I don’t see that much of a difference.
That said, deciding whether communities or 1:1 chats gets migrated to RLN first ultimately depends on Status’s priorities. Since we already have a solution for Communities that provide decent levels of DoS protection and scalability (assuming statically-sharded communities), my inclination is to stick with the current roadmap of providing minimum viable scalability/DoS protection for 1:1 chats with RLN first.