Glad to see the topic of #ssb-metadata #privacy resurfacing.
I recently became a user+pub singleton with a onion-service.
I agree with @andrestaltz when he says:
I believe we should start de-emphasizing pubs
and I imagine users being their own pubs should be the goal as far as sync-over-internet goes (while also heavily improving the UX for alternative sync methods like #sneakernet, bluetooth, wifi, etc.)
I don't yet have deep knowledge of how #ssb's gossiping works, but it seems to me that the main technical reasons pubs-that-are-not-users exist are:
- NAT traversal (users can't connect directly to each other)
- stable addressability (users have dynamic IP so keeping a list of peer IP addresses doesn't work)
Even if all users had stable public IP addresses (which would solve those two connectivity problems), they'd still be leaking metadata to their ISP and anyone on route, plus to each other (I might not want everyone I follow/friend to know my IP.)
Onion services solves both of those connectivity problems, giving users a stable (albeit cryptic) .onion
address they can pass around, and doing itself NAT traversal under the covers via #tor rendezvous points.
On top of that, it plugs the metadata hole. This is already supported, but it takes having your own tor daemon running, setting up your onion service by hand, and configuring sbot to use it. I think it could be the default, by having #sbot package its own Tor daemon, like #ricochet does. That edges us much closer towards true peer-to-peer while radically improving privacy.
About group private messages, I think a useful distinction can be made between group chat and group feed. It would be the difference between a Signal/WhatsApp/Messenger group and a Facebook Group.
SSB seems better fit towards the group feed model, because of its log-based permanence.
For the group chat use case, as others like @rabble are starting to think about it, I would recommend integrating something like #openprivacy's cwtch.im, which is being designed specifically for the group-based, asynchronous, metadata resistant use case ("distributed #signal").
I think metadata should be front and center in the design of peer-to-peer systems, because as people start connecting directly to one another, they end up leaking a lot more to a lot more untrusted actors than when previously "laundering" their connection graph through something like a (trusted) Signal server. And I think #onion-services provide unmatched security to build on top of.