Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Whatsapp service not usable anymore #274

Open
matbgn opened this issue May 10, 2022 · 16 comments
Open

[BUG] Whatsapp service not usable anymore #274

matbgn opened this issue May 10, 2022 · 16 comments
Labels
affects/services Issue or PR related to a notification service. help wanted Extra attention is needed type/bug Something isn't working up for grabs

Comments

@matbgn
Copy link

matbgn commented May 10, 2022

Describe the bug

Regarding the official documentation of the Rhymen/go-whatsapp API

Warning
This package is not being actively maintained currently and will soon be unusuable as WhatsApp updates to multi-device. Please look at tulir/whatsmeow for a Go WhatsApp Web API that is actively maintained and supports WhatsApp multi-device.

And the issues opened on it (Rhymen/go-whatsapp#644 & Rhymen/go-whatsapp#651), it seems that this API is no more usable.

Is there a plan to integrate the one proposed (whatsmeow) into Notify in the future?

@matbgn matbgn added the type/bug Something isn't working label May 10, 2022
@nikoksr
Copy link
Owner

nikoksr commented May 11, 2022

@matbgn thank you very much for the report! And sorry for the inconvenience. I definitely want to keep the WhatsApp service alive, so I or someone else will take care of it as soon as possible.

@nikoksr nikoksr added help wanted Extra attention is needed affects/services Issue or PR related to a notification service. up for grabs labels May 11, 2022
@slowmanchan
Copy link

I can take a crack at it.

@slowmanchan
Copy link

Seems like a DB needs to be hooked up for the new package. A default sqlite implementation is provided. Do we want to go this route or keep lookin?

@matbgn
Copy link
Author

matbgn commented Jun 3, 2022

This is just my personnal opinion, but IF there could be a solution (i.e. with a reasonable amount of research) to avoid an additional SQL DB (even a lite one), I will be more than glad.

@nikoksr
Copy link
Owner

nikoksr commented Oct 21, 2022

@slowmanchan appreciate your efforts and sorry for the late response. This one just kinda got lost in the wild for me.

Just in case that you're still interested in implementing this, I'd prefer the WhatsApp service to have a "bring it yourself" solution for the storage. Meaning, the service should expose a way for the user to set and provide their own storage solution via an interface or object. An additional default and minimalistic in-memory solution would be okay with me, too!

Let me know what you think and if you need any help with this. Sorry again for letting you wait for that long.

nikoksr added a commit that referenced this issue Oct 24, 2022
Package whatsapp is currently a [ NO-OP ] service! We're sorry for the inconveniences.
We're already working on a fix.

Please read this [1] for more. Thanks!

[1]:#274
@matbgn
Copy link
Author

matbgn commented Dec 26, 2022

Hi there!

Any news @slowmanchan?

Il the mean time it seems that there is a new up-to-date library for WhatsApp written in Go:

https://github.com/tulir/whatsmeow

Any of you want to take a look?

@bytesizedwizard
Copy link

@nikoksr Is this being worked on at the moment? If not, I would love to give this a try!

@nikoksr
Copy link
Owner

nikoksr commented Jan 4, 2023

@thedarthcoder appreciate your interest in helping the project! The issue is indeed still free, so if you want to tackle, we all would greatly appreciate that.

Watch out tho, the WhatsApp service is structured differently than most other services. We'll need interfaces etc to allow for user provided storages etc. Please let me know if you need any help.

@nikoksr
Copy link
Owner

nikoksr commented Jan 6, 2023

@thedarthcoder want me to assign you to the issue?

@bytesizedwizard
Copy link

@nikoksr Thanks a lot. It would be great if you could assign me this issue. Would surely love to work on it.

@bytesizedwizard
Copy link

Thanks @nikoksr. An update on this, as @slowmanchan mentioned I think this will indeed need an additional database setup like sqlite. But I'm working to find a generic solution to expose a service where users can specify their own storage solution.

I'm also researching on ways to avoid the db integration entirely or at least make it as minimalistic as possible.

More updates will follow soon. Cheers!

@nikoksr
Copy link
Owner

nikoksr commented Jan 18, 2023

@thedarthcoder that would be amazing. We appreciate it so much. Let me know if there's anything I can do, to help you out.

We have discussed in the past to add a in-memory store as a default solution. I don't like the idea that someone can't just play around with the WhatsApp service, but has to write a store implementation first. If that puts too much on your plate, let me also know and I'll implement it as soon as you got a draft out.

@nikoksr
Copy link
Owner

nikoksr commented Feb 20, 2023

@thedarthcoder hope you're doing well. Anything we can do to push this forward? Any help we can offer you?

@no-1ne
Copy link

no-1ne commented Mar 27, 2023

https://github.com/febriliankr/whatsapp-cloud-api official api has been launched, no more risky reverse engineering business

@matbgn
Copy link
Author

matbgn commented Dec 9, 2023

Friendly reminder @bytesizedwizard but maybe @nikoksr you have read some stuff and maybe have another idea or perspective to address Whatsapp's API?

@ppmdo
Copy link

ppmdo commented Apr 21, 2024

Hi @nikoksr , after looking at the wrapper for the cloud API, it seems this could be simple implement. Here's a basic example implementation I drafted: https://github.com/ppmdo/notify/blob/dev-ppm/service/whatsapp/whatsapp.go.

Is it going in the right direction?

I'm not super familiar with WhatsApp Business, but from the API Docs it seems there are two types of messages: template message and simple text messages. Shall we support both? Or what would be the idea?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
affects/services Issue or PR related to a notification service. help wanted Extra attention is needed type/bug Something isn't working up for grabs
Projects
None yet
Development

No branches or pull requests

6 participants