Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Expose SubscribePresence (contact online) + decrypt edited messages (new text arrives encrypted)

Đang mở
  • Có gì không ổn?
#146 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 5 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
48/100
Loại issue
Tính năng
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
go
Lĩnh vực
api, backend

Hướng nghiên cứu

Bắt đầu trong pkg/whatsmeow/service/whatsmeow.go, xem xét đường dẫn webhook Presence hiện có và khối giải mã poll-vote, sau đó kiểm tra pkg/message/service/message_service.go để hiểu lý do của ChatPresence. Thêm route đăng ký Presence theo phạm vi instance và giải mã các tin nhắn đã chỉnh sửa bằng dữ liệu sự kiện hiện có. Hoàn thành khi các đăng ký Presence tạo ra webhook và webhook của tin nhắn đã chỉnh sửa hiển thị plaintext mới.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Summary

Two whatsmeow capabilities are effectively present in the codebase but not surfaced to API consumers, so CRMs built on top of Evolution Go can't reach feature parity with the Baileys-based Evolution API for them:

  1. Contact presence ("online" / last-seen) — there is no way to SubscribePresence, so events.Presence never fires.
  2. Edited messages arrive encrypted and undecrypted — the new text is delivered as a raw secretEncryptedMessage envelope, so consumers can't read what the message was edited to.

Both are small, additive changes. Happy to open a PR for either/both if the approach looks right to you.

1. Expose SubscribePresence → enables contact "online"/last-seen

whatsmeow only emits events.Presence for JIDs you've explicitly subscribed to via Client.SubscribePresence(ctx, jid). A grep of the repo shows SubscribePresence is never called, and there's no route to trigger it. The rest of the plumbing already exists:

  • the Presence event dispatcher → webhook ({event:"Presence", state, data:{From, Unavailable, LastSeen}}) is already implemented in pkg/whatsmeow/service/whatsmeow.go;
  • the PRESENCE subscription filter already exists.

Request: a new instance-scoped route, e.g. POST /user/presence/subscribe with body { "number": "5521..." } (nice-to-have: also accept { "numbers": [...] } for batching the top N conversations of an inbox):

  • normalize to a canonical JID (same helper used by /message/presence);
  • send our own presence first — client.SendPresence(types.PresenceAvailable) — since whatsmeow only receives presence updates after you've broadcast your own (same rationale already noted in pkg/message/service/message_service.go around the ChatPresence handler);
  • call client.SubscribePresence(ctx, jid) and return {data:{subscribed:true}}.

With the subscribe in place, the existing Presence → webhook path just starts flowing. No other change needed.

2. Decrypt edited messages (currently the new text is unreadable)

When a contact edits a text message, the event arrives with Info.Edit == "1" and the new text encrypted inside Message.secretEncryptedMessage (secretEncType: 2), with the original message key under secretEncryptedMessage.targetMessageKey. Because this is never decrypted, downstream consumers receive an opaque envelope instead of the edited text.

Real captured payload (redacted):

{
  "event": "Message",
  "data": {
    "Info": { "Edit": "1", "ID": "3A3EFD...", "IsFromMe": false, "Type": "text", "Timestamp": "..." },
    "IsEdit": false,
    "Message": {
      "secretEncryptedMessage": {
        "encIV": "…", "encPayload": "…", "secretEncType": 2,
        "targetMessageKey": { "ID": "3A35AE...", "fromMe": true, "remoteJID": "…" }
      }
    }
  }
}

Two observations:

  • data.IsEdit is false even for an edit — the only reliable signal is Info.Edit == "1". If that's intended, it would help to document it; if not, it may be a small bug worth fixing.
  • The message handler already decrypts poll votes with DecryptPollVote (in pkg/whatsmeow/service/whatsmeow.go, in the same event-processing block that handles PollUpdateMessage). The edit path could mirror that: when evt.Info.Edit indicates an edit (or secretEncryptedMessage is present), decrypt the secret message and emit the resulting editedMessage / plaintext in the webhook (e.g. as protocolMessage.editedMessage or a decoded Message), so consumers can update the original bubble.

Request: decrypt the secretEncryptedMessage for edits (as already done for poll votes) and surface the plaintext new text in the webhook payload.

Environment

  • Evolution Go build "Evolution GO 1.0" (self-hosted), consumed by an external CRM via webhooks + REST.
  • Baileys-based Evolution API already surfaces both of these (contact online + decoded edits), so this is purely about reaching parity on the Go engine.

Thanks for the project! Glad to send PRs for these if you'd point me at the preferred approach.

Ngôn ngữ chính
Go
Star
890
Fork
473
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

  • Có Dockerfile hoặc tệp Docker Compose
  • Có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của evolution-foundation/evolution-go

Tất cả issue của evolution-foundation/evolution-go

Issue tương tự

Thêm issue về Go

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.