Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

aw-notify: achievements / streaks / trophies (split from #200)

Open
  • Is something wrong?
#205 13 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
kotlin, rust
Domain
backend-api-design, mobile

Research direction

The issue is a design discussion for a new achievements system in aw-android, referencing aw-server and aw-notify. Start by reading the linked forum thread and the CHI paper to understand the gamification context. Examine the existing notification infrastructure in aw-android and the data query model from aw-server-rust to see how achievement conditions could be evaluated. 'Done' means a proposed design for storage, sync, and multi-device handling, not code.

Written by the indexing model from the issue text.

Description

Splitting this out from ActivityWatch/aw-android#200, per @ErikBjare's suggestion — the achievements/streaks/trophies direction is a distinct enough feature to track on its own rather than living inside the broader "smarter-than-thresholds" notifications thread.

Background

In #200 we compared anomaly-detection notifications (percentile/sigma above baseline) against a "coaching"/reward angle, and landed on achievements as a promising first step:

  • Works with minimal history (a first occurrence is still a valid achievement) — unlike anomaly detection, which needs ~30 days of baseline before it's useful.
  • Framing is additive/positive rather than corrective.
  • "Trophy for best focus day this month" is more shareable/engaging than "you're 2σ above baseline."
  • Fits the existing notification infrastructure (per-category historical time from aw-server) either way.

References:

Open design questions (from @ErikBjare, carried over from #200)

  • Storage: how do achievements get stored once conditions are met? Need references to which data sources were used, the time-range covered, and the source devices/buckets involved — not just a flat "achievement unlocked" flag.
  • Multi-device: should each device have its own achievement store that overlays locally, or should achievements sync across devices?
    • Sync as part of "settings"? Is settings-sync even supported yet?
    • Or should achievements live in their own dedicated bucket (e.g. an achievements bucket)? Is that a good fit for the existing bucket/event model, or a bad one?
  • Trophies should be collectable multiple times (e.g. per time-period — "best focus day this month" can recur), not one-shot unlocks.

Scope (not yet decided)

This issue is for continuing the design discussion — no implementation approach is locked in yet. Candidate shape: define achievement conditions declaratively, evaluate them against aw-server query results, surface via aw-notify, with the storage/sync model above still open.

cc @ErikBjare

Dominant language
Kotlin
Stars
270
Forks
57
Avg merge
23h 47m
Merged PRs (30d)
39

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

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ActivityWatch/aw-android

All issues in ActivityWatch/aw-android

Similar issues

More Kotlin issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.