Choose the Android push transport and notification payload contract
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- android, go
- Domain
- api, backend-api-design, mobile
Research direction
Read internal/notification/model.go and service.go, then review the account contract in #88 and the selected app target. Compare transport options against the stated Android constraints and define the registration, payload, retry, expiration, deduplication, and fallback contracts. Done means the decision is committed with synthetic payload examples for the server and client tasks.
Written by the indexing model from the issue text.
Description
Roadmap: #76
Goal
Define the provider integration and data contract before adding device push delivery.
Acceptance criteria
- Compare transport options against the selected Android architecture, hosting requirements, and behavior without the provider's device services.
- Define registration, token rotation, opt-out, account rebinding, and expired-device behavior.
- Specify minimal notification payloads and authenticated content retrieval; decide what may appear on the lock screen.
- Define retry, expiration, deduplication, and fallback-to-inbox behavior.
- Commit the decision with synthetic payload examples used by server and client tasks.
Start: internal/notification/model.go, service.go, the account contract #88, and the selected app target.
Prerequisites: #88.
- Dominant language
- Go
- Stars
- 1
- Forks
- 7
- Avg merge
- 6h 25m
- Merged PRs (30d)
- 18
Getting set up
We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.
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.
More from wavefnd/wave-platform
-
bug difficulty: beginner documentation good first issue help wanted localization
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
wavefnd/wave-platform#139 ·
Maintainers usually reply within 1 day
-
bug difficulty: beginner documentation good first issue help wanted localization
Difficulty 2/5 Half a day Newbie friendliness 88/100
wavefnd/wave-platform#137 ·
Maintainers usually reply within 1 day
-
bug difficulty: beginner documentation good first issue help wanted localization
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
wavefnd/wave-platform#136 ·
Maintainers usually reply within 1 day
-
bug difficulty: beginner documentation good first issue help wanted localization
Difficulty 1/5 Under an hour Newbie friendliness 94/100
wavefnd/wave-platform#135 ·
Maintainers usually reply within 1 day
-
bug difficulty: beginner documentation good first issue help wanted localization
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
wavefnd/wave-platform#133 ·
Maintainers usually reply within 1 day
All issues in wavefnd/wave-platform
Similar issues
-
area: global bug dx priority: low
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
enhancement
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
grafana/mcp-grafana#1267 ·
Maintainers usually reply within 1 day
-
automation models
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
coverage-gap good-first-pattern help wanted
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
GoogleCloudPlatform/k8s-aibom#114 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
txn2/mcp-data-platform#1984 ·
Maintainers usually reply within 1 day