Permission by permission

Prayer sync, explained functionally

The complete user journey, from first sign-in to account deletion, with each permission tied to the promise it enables.

CommunityRead-only agenda or no-OAuth delivery

SupporterFull sync, automation, 2 active agenda accounts

DeletionTokens, connections, feeds, and local data removed

scope identity or read-onlyscope write access protection or promise

Start

Onboarding

Identity only. No calendar access exists yet.

Create account or log in

Email and password, or OAuth sign-in.

uses:openidemailprofile

Set up prayer space

Location, calculation method, school, selected prayers, duration, and buffers are stored in the app. No calendar permission is needed.

Prayer times calculated

Aladhan calculates saved Prayer Defaults. This is an external prayer-time source, not a user calendar permission.

Preview draft

Arihna Biha proposes Prayer Blocks before anything is delivered.

Community tier by default

1 active agenda account, read-only included, no full sync, and no scheduling automation.

Choice

Choose a delivery path

The first calendar permissions appear here, and two of the three paths need no calendar OAuth at all.

Path A: read-only agenda

Show agenda context and detect conflicts.

calendar.calendarlist.readonlycalendar.events.readonly

User.ReadCalendars.Readoffline_access

Never creates, edits, or deletes provider events.

Switching the active agenda account does not revoke old OAuth or force OAuth again.

Path B: email / export

Deliver Prayer Blocks without Google or Outlook OAuth.

Zero calendar permissions. A verified delivery inbox is enough.

.ics download, grouped .ics email, or one calendar invite per Prayer Block.

Private, revocable feed URL. The calendar provider pulls it on its own timing.

Good no-write fallback, but not deterministic full sync.

Path C: nothing connected

Maximum privacy, in-app only.

Zero provider permissions of any kind.

Prayer Defaults and Preview stay in Arihna Biha.

No agenda reading, no provider writes, and no delivery until the user enables a path.

Upgrade

Supporter full sync

The upgrade adds write access only when the user chooses full sync.

Become Supporter

Stripe subscription or admin grant. Payment changes entitlement, not calendar permission.

Supporter entitlement

Unlocks full sync, scheduling automation, and up to 2 active agenda accounts.

Full calendar OAuth consent

Everything needed to choose calendars, plus the provider write permission.

adds:calendar.eventsorCalendars.ReadWrite

Choose Sync Target

The user picks the writable provider calendar where Prayer Blocks should live.

chooses via:calendar.calendarlist.readonlyUser.Read

Review, then write

Arihna Biha creates, updates, deletes, or restores only app-owned Prayer Blocks.

writes via:calendar.eventsCalendars.ReadWrite

Synced Events

Provider events owned and tracked by Arihna Biha.

kept fresh with:offline_access

Protections running alongside sync

Scheduling automation

Live rules retrigger on saved scheduling changes, Prayer Defaults changes, blocker agenda notifications, and writable target notifications. Scheduled .ics email follows its saved cadence.

Fallback dispatcher

Every 5 minutes, recovers dirty live rules and due .ics email rules. Clean direct-sync rules are not blindly recalculated.

Manual edit protection

Can respect Prayer Blocks moved in Arihna Biha and app-owned events moved or deleted in Google or Outlook.

Second agenda account

Supporters can keep an extra Google or Outlook account for blockers, previews, and targets.

Token promise applies to every calendar permission

Encrypted at rest Used only for selected calendar features Removed on disconnect or account deletion

Deletion

Account deletion

Every permission granted along the way is unwound in order.

Delete account requested

Active Supporter payments stop. Scheduling and live sync rules are disabled.

Optional provider cleanup

Future Arihna Biha-owned Prayer Blocks can be deleted from provider calendars while write access still exists.

last use of:calendar.eventsCalendars.ReadWrite

Provider access cleanup

Google revocation is requested. Microsoft local tokens are removed, and the user can also revoke consent provider-side.

removed:all granted calendar scopes

Final deletion and receipt

Local OAuth tokens, Calendar Connections, Agenda Sources, Sync Targets, feeds, Prayer Defaults, User-tied history, and the User account are removed. A deletion receipt is emailed.

Arihna Biha - permission model overview - gray = identity/read-only - gold = write access