Optional account, for people who want one

Open
#175 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Active
Tech stack
swift

Research direction

This is a design discussion, not a code task: it names no files, tests or entry points. The open questions are which sign-in method to use (GitHub device flow or email links) and where the account service runs. Read the design rules and the linked usage-reports issue #176 first. Done would mean a written decision on those questions, agreed by the maintainer, before any implementation starts.

Written by the indexing model from the issue text.

Description

enhancement priority:P2 roadmap

SpeakType works with no account today, and that stays true: dictation, models, history and settings never require signing in, and the app keeps working offline forever.

An account would be opt-in, and worth having for:

  • Usage reports (#176), so people who want to help can share how the app is doing.
  • Sync between devices, once the phone keyboard exists. That's the only feature that genuinely needs an identity.
  • A way to reach people who ask to be told about releases.

Design rules, or it isn't worth building:

  • Nothing in the app is locked behind an account, now or later.
  • Signing in is a choice made once, never a prompt on launch, and never a wall on first run.
  • Signing out removes the local copy of the account, and deleting the account removes everything held for it.
  • No account, no data leaves the machine. That promise stays exactly as it is for everyone who skips this.

Open questions: which sign-in (GitHub device flow is the least friction for this audience, email links are the most familiar), and where it runs. Whatever we pick should be documented, so people can see what's stored.

Dominant language
Swift
Stars
540
Forks
74
PR merge metrics
No merged PRs in 30d

Getting set up

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 karansinghgit/speaktype

All issues in karansinghgit/speaktype

Similar issues

More Swift issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.