I'm very hopeful this reverse engineering effort will enable the creation of a tool to export my conversations (WhatsApp can do email export, which let's be real, doesn't cut it for most cases).<p>A point to those that support migrating to alternatives such as Signal. Signal is good, but far from great for a single reason: you need a phone number. This is very bad in necsec and reliability terms, my case:<p>Reliability: like more and more people, I travel all the time between countries and live out of Airbnbs. Hence my pre-paid phone numbers changes very regularly. If I lose my phone, I lose the phone number, I also lose my Whatsapp/Signal key associated with my phone number.<p>Netsec: A phone number is associated with your physical identity, you might not care, but more and more people do care about this stuff. Yes there are ways around that, but nothing straightforward and actually practical.<p>I'm patiently, but eagerly, looking forward to status.im .
I see a lot of "just use X instead."<p>Unfortunately, unlike the old chat protocols, switching to any other platform means convincing your contacts to use a new platform. They like you and all, but that means they also have to use a special app just to talk with you now.
Wow that's impressive. But I would imagine WhatsApp/Facebook can just change their protocol at any time since it is easy to redeploy a new version of the WhatsApp Web client, thus breaking any 3p clients built on the original protocol. That would require yet another reverse engineering effort that can take a while. And by the time its reverse engineered again, they can yet again change the protocol. So the only reliable way to create 3p clients would be if WhatsApp itself publicly publishes its protocol.
Curious to know why they chose to require python in addition to node, wouldn't node with npmjs/yarn be sufficient and require less setup? Does python/pip provide any benefits here?
Wouldn't it be better to simply start convincing your friends to use something more open, where you have choice of the client?
It feels like solving the problem from the wrong angle…
Impressive work.<p>Obviously, WhatsApp/Facebook would want to avoid a bunch of third party apps connecting to their service. How long until they make changes to make this more difficult/impossible?
FWIW Repos like these that reverse engineer a proprietary API that post stuff on GitHub are usually taken down with a DMCA enforcement. The same thing happened multiple times when folks reverse engineered and documented the Snapchat API. <a href="https://news.ycombinator.com/item?id=6083812" rel="nofollow">https://news.ycombinator.com/item?id=6083812</a>
From the GitHub readme:<p>> <i>An UI that is not that technical, but rather starts to emulate the actual WhatsApp Web UI.</i><p>No, no, no. This trend of 'Phone UI' chat interfaces on desktop/laptop screens needs to stop. If you are going to all this effort to reverse engineer the protocol, at least make your front end customisable or at the very least IRCish in style.
Many of the vendors we partner with (tourism industry) live in countries where the main communication channel is WhatsApp. There's a lot of communication we want to automate in the near future—eagerly looking forward to seeing this progress!
Were you inspired by this repository <a href="https://github.com/mukulhase/WebWhatsAPI" rel="nofollow">https://github.com/mukulhase/WebWhatsAPI</a>?<p>Do you need a phone running to use this project?
I'm wondering how they actually reverse engineered WhatsApp in the first place. Is there a specific type of software that does this or was it just built from scratch using already available information?
A pidgin plugin would be nice.
Oh there seems to be one already - <a href="https://github.com/davidgfnet/whatsapp-purple/" rel="nofollow">https://github.com/davidgfnet/whatsapp-purple/</a>
Noob question: Is traffic going through the websocket-servers properly end-to-end encrypted? That's what always held me back about using Whatsapp Web