I spent 2 weeks evaluating peer-to-peer protocols for my app.
There are many promising solutions suitable for different use cases.
I likely misunderstood something and welcome corrections!
I've worked with p2p stuff quite a bit, mostly around the network connections part of it and I I feel obligated to issue a warning -- on the "Peer-to-peer architecture research" post, you said:
* it will be PWA ( it will be a web site )
* phone as primary data storage site
AFAIK this doesn't really work because:
* limited data capacity of browsers (unless app is text-only)
* extremely low availability/"reachability" of web browsers
IMO you should plan to store the data on a server as the primary storage site.
Ultimately I think this "no permanent storage on server" goal inevitably leads to either "each user has a backblaze account and uploads their e2e encrypted data to an object storage bucket"
Or
"Each user runs their own server"
I think the issue of users not having data autonomy is easier to tackle as a social problem than as a technical problem. Even the best possible technical solutions still kinda need autonomous hosting.
Not to mention, I think the social solution just feels better anyways.
I would worry about users "missing" each other and never being able to get a copy of whatever data from each other.
I would expect users would read silence as "this app doesn't work" or "no one likes me", not as.. *takes deep breath*...
> "oh, I must have missed that message because the senders client / senders friends clients were never connected at the same time as mine, and my client was never connected during the servers retention period after it was sent"
Ultimately I think the server retention period will have to be cranked really high to make the app usable and prevent missed messages.. And there's really no limit to "how high".
So at that point, the situation ends up looking rather silly, the server is going to be the primary data store whether we like it or not, simply because its the one that folks can connect to.