really ?
https://www.wired.com/2016/07/secret-conversations-end-end-encryption-facebook-messenger-arrived

Now we only have to promote metadata privacy.

I have some ideas about how we could make ssb quite ssb quite metadata private. private messages and secret-handshake have already been designed wtih metadata privacy in mind.

• implement group private messages, and then shift most messages (especially follow, like, etc) into that format

when replicating, avoid advertising your follows:

Instead of requesting pubkeys, request hmac(pubkey, session_secret},
then if you won't know that I know pubkey unless you already know it.

We'd have to overhaul the way common messages work to make this happen.
it might also be a good idea to use hash(pubkey) as the id, instead of pubkey. Then you can mention someone without actually revealing their pubkey - thus, we could use pubkey as a capability, to access that feed.

The balancing act is that sometimes you want some things to be public.

@lilaL public unecrypted messages are ... public, so you can see all mentions, when they happened etc. It's secure in that you can be sure a signed messaged came from a particular person (or rather their computer), and you'll know if someone steals their key and posts things because the system doesn't support forking an identity.

with encrytped messages, you can't see who they're addressed to, you can only try and decrypt it with your key, and if that works, it was for you!
This is an advantage over e.g. encrytped email.
You can still see when people message relatively, but with enough private messages going on things get harder

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.