[badsectoracula]

> Because what is the alternative

Wouldn't a better alternative be to design a messenger that complies with GDPR? Simple user accounts that can be deleted at the request of the user, peer-to-peer encryption (and where possible, communication), a "storage cabinet" for each user where encrypted data end in when the user is offline (with an encryption/decryption key that is generated client-side and transmitted while both users communicate) and can easily be deleted and i think this covers most uses.

This is just an idea that i came up with right now, but if you start your design with the goal to store as little data as possible and anything you store needs to be both encrypted and easy to delete, then i believe you can come up with several ideas for most issues.

It also helps to see this as respecting the users' privacy and giving them control, as opposed to a development burden :-P.

[nemothekid]

I don't think you actually answered his point. Sure you could build an IM client that is GDPR compliant, but at what point do the costs become so high that everyone just defaults to using Facebook because (1) they can afford to be compliant and (2) they are trained well enough to not fuck up their encryption.

In other words, are we moving towards a world where unless you are VC backed (Signal, Telegram, Whatsapp, etc) don't bother building an IM client? Also note, I don't think there might be anything wrong with that - if we expect all our communications to be E2E encrypted, maybe Joe Shmoe shouldn't be writing an IM client.

[badsectoracula]

There is an assumption that there is some additional "natural" cost involved because of GDPR, but where does that assumption come from? The cost might currently exist if you are not compliant and you need to convert (or you need to skirt the edge between what is allowed and what not), but if you start with being firmly compliant from the design phase, where does the cost come from?

[tobltobs]

Eg. the DPO.