WhatsApp: the one place family logistics actually happens, and the one with no open door
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 434
- Forks
- 21
- Avg merge
- 18m
- Merged PRs (30d)
- 326
Description
Why
School WhatsApp groups are where the plans are made. Mail carries the formal version — the letter, the invoice, the calendar invite — and the group carries the thing people actually act on. A brief built only from mail sees the half that is already written down.
Why it is harder than Gmail
Gmail is a third row in a grant map we already have. WhatsApp has no equivalent, and it is worth being honest about that before it goes on a roadmap.
There are three doors and none of them is good:
Cloud API (official). Business-to-consumer messaging. It gives you your business number's conversations, not a person's own account, and it cannot read the groups a person is already in. It is the right door for an agent that has its own WhatsApp number and the wrong one for reading somebody's family group.
Bridges (mautrix-whatsapp and similar). These work by pairing as a linked device over WhatsApp Web's protocol. They do read the groups a person is in, which is the thing we want, and they are what every Matrix bridge in the wild uses. The costs are real: it is unofficial, it can break when the protocol moves, and the account is subject to whatever enforcement Meta applies to non-official clients.
Nothing. Ask people to forward things, which nobody does.
What I would actually propose
- Decide the door first, in the issue, before any code. This is a policy decision about a user's account, not an engineering one
- If a bridge: it is a linked device. Say so at the point of pairing, in plain words, including that it is unofficial and what the account risk is. Nobody should discover that afterwards
- Read into
internal/threadasClient: "chat", so it renders as a stream and not as mail — see #1471 on genre, which already says the client is the genre - Index owned, like everything else that is a person's
- Group messages are other people's words. They are already covered by the record's own rules, but a group is a larger audience than a thread and worth checking against the privacy note in
inbox/
The honest alternative
An agent with its own WhatsApp number over the Cloud API, that a person forwards things to or adds to a group deliberately. Less magic, no account risk, no protocol to chase — and it puts the agent in the group as a participant, which is the same shape #1471 argues for with XMPP.
That may be the better product as well as the safer one, and it should be considered rather than treated as the fallback.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by resolving the Cloud API versus linked-device bridge decision, then read internal/thread, the privacy note in inbox/, and issue #1471 for the proposed genre and participant model. Done means the chosen door and account risks are documented, with the ingestion, ownership, group-message privacy, and rendering requirements specified before implementation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 32/100