-
-
Notifications
You must be signed in to change notification settings - Fork 2.6k
feat: libsignal wasm #2067
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
base: master
Are you sure you want to change the base?
feat: libsignal wasm #2067
Conversation
|
Thanks for opening this pull request and contributing to the project! The next step is for the maintainers to review your changes. If everything looks good, it will be approved and merged into the main branch. In the meantime, anyone in the community is encouraged to test this pull request and provide feedback. ✅ How to confirm it worksIf you’ve tested this PR, please comment below with: This helps us speed up the review and merge process. 📦 To test this PR locally:If you encounter any issues or have feedback, feel free to comment as well. |
cc9ae9b to
779ad19
Compare
|
I'm following along and testing it out 🫡🙂 |
- Add WebAssembly version of libsignal - Improve performance with WASM implementation - Update dependencies for libsignal WASM support 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
Testing in scale this week |
…ets#1969 to latest Baileys Applied PRs: - WhiskeySockets#2067: libsignal wasm - WhiskeySockets#2057: emit setting events - WhiskeySockets#1969: improve retry logic Note: PRs WhiskeySockets#1991, WhiskeySockets#1981, WhiskeySockets#1906, WhiskeySockets#1892 have conflicts with latest Baileys version and were skipped. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
Good news: The PR is ready for testing (no need to delete sessions or sender keys anymore, this will be auto migrated, only in case reverting this is necessary) |
… v0.4.0-alpha.3 Updated libsignal WASM implementation with latest whatsapp-rust-bridge version. Changes: - Updated whatsapp-rust-bridge: 0.4.0-alpha.2 → 0.4.0-alpha.3 - Core WASM implementation was already in place from previous PR - Provides 10x faster message encryption/decryption performance Performance benefits: - Native-speed cryptographic operations (WASM) - Efficient group message handling - Better memory management Build and dependencies verified successfully. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
|
I've tested this in a production environment. There are several cases where the bot suddenly stops receiving upsert messages, and it only starts working again after rescan. I'm still monitoring it, but for now that's the main issue I've encountered. |
It's not due to that PR, try implementing that PR and see if it continues: #2070 |
|
It was merged but the purpshell reverted. |
Ah, I see. That was my mistake. another one of my instances running v7.0.0-rc8 had the same issue, so it wasn’t related to this PR. |
|
This implementation is not stable, after testing it, I noticed that Then I continue to keep getting
|
This occurs in a fresh or existing session? Is there any error log that you can share? |
|
I'm getting this error when using an existing (old) session in this pr. The issue disappears when I revert back to v7.0.0-rc6. |
Thank you, I'll check soon |
Occurs only on existing session I'm yet to test on a fresh session |
… v0.4.0-alpha.4 Updated to latest whatsapp-rust-bridge version released 14 minutes ago. Changes: - whatsapp-rust-bridge: 0.4.0-alpha.3 → 0.4.0-alpha.4 Maintains 10x faster WASM-based cryptographic operations. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
we need to handle it differently. |
|
Would love if the logging architecture was implemented the same way |
Related to this @Salientekill (even though this is off topic) check out rc9 |
Ksksksks I answered you discord already (shiroe) |
@jlucaso1 This was the same .unwrap() kind of error that took cloudflare offline, be careful man 😆 |
Yeah hahaha. I've just searched and removed all .unwrap from code |
…session and sender keys)
44400d2 to
7a43cc7
Compare
|
When the coex is added, please let me know so I can test it. |
|
@Santosl2 can you test again? @purpshell review my last commit only, check if makes sense. I don't know if this is related to libsignal wasm only (I have dont change any code with this hosted logic). But I'm forcing since deviceId 99 is reserved to be hosted. CC: @Salientekill |
What exactly is CC? |
i'll test it.. And you're correct, this isn't related to libsignal WASM. Its a hosted bug. Sorry, i reported in the wrong PR |
This is after a long time with bot offline? There is a way to reproduce? |
Hmm i couldn't find a way to simulate this. I simply created a new connection, connected it, and sent a message to a group. All the messages i sent stayed in the "Waiting for message" state (this appears on all devices: ios, android and whatsapp web) |
Yes exactly like that. I tested it on more than 5 instances. All of them, when connected, always get this error when sending messages to groups |



Working branch: WhiskeySockets/whatsapp-rust-bridge#2
Need help to test stability from dm messages (maybe is necessary to start a new session, but the idea is in the future to be 100% retro compatible)
With node 24 I've seen a perfomance in encrypting/sending message 10x faster
before:

after:
