Note

• Add extension_id to probe_settings where extensions could be none, joke, bible verse etc.
• If extension is enabled, based on extension, get text & send back to user.

E.g. joke - you get a joke with your probe, or custom-questions - you get a custom puzzle, if solved correctly, that means you're okay, math - get a random math problem each time to check if you're okay

Should help prevent replay attacks with token

What the release should contain

• #8
• #9
• #10
• #18
• #20
• #21
• Increase version of pkg & publish

• Twilio setup
• Google cloud storage setup

User can add multiple notes. Each note has a trigger e.g. Send note to emergency contact after 1hour/30days of being unavailable.

Use cases:

• Send personal note to loved ones - doesn't contain any secrets
• Share encrypted content(for which the recipient has the key) - which could have passwords etc
• The note can contain information on what to do if user is no longer available 😢

Investigation

• Look into storing public key pair for users to handle encryption of personal messages ?
  • The server can store the public key & then make the user download the private key. I.e emergency contacts will need to have key pair generated for them. And the message will be encrypted using the recipients public key.
  • The author of the message will also have a copy encrypted with their public key so they can update the message whenever they want.

• POST /users - return user_id/info on user creation
• Return 400 for bad request(e.g db errors like duplicate data or failed constraints) instead of 500
• GET /probes - should work without status filter
• GET /jobs - should work without status filter
• Support Pagination on all endpoints that require it
• GET /users/{id}/probes
• API versioing
• Update docs accordingly

When a user probe status is unavailable/bad, call webhook url defined by user.

Start with probeScheduler

TODO:

• --test mode should use in:memory db for test
• Test that ScheduleProbes:
  • Loads crons for probes where users have their probe_settings set to active
  • Loads crons for probe followups i.e. ENQUEUE_FOLLOWUP_PROBES_HANDLER
• Test that the probes are executed when they are suppose to be ?
  • Perhaps this should not be a probeScheduler test, but a wokerPool test ?

• Remove all touchbase code
• Replace touchbase documentation with server documentation

Also add validation for cron_expression

• Fix typo in 'dependcies'
• Include dev mode i.e. kronus server --dev
• Add that it doesn't work in distributed environment

After a probe reaches max_retries, it doesn't wait for an hour for a response before escalating a message to an emergency contact.

This is probably the culprit > https://github.com/Daskott/kronus/blob/main/server/helpers.go#L234-L257. Folder is not created, if it doesn't exist in dev mode

A user can text the server something like:

probe 15m

And a probe will sent to the user in 15m, with 0 retries. Can be done through scheduled jobs.

TODO:

• user.probe_settings should have max_retries & wait_time_in_minutes(i.e. time to wait for a reply after which the probe is retried or is marked as unavailable)
• When creating a probe use the users user.probe_settings to set max_retries & wait_time_in_minutes - they should also be fields in probe.
• Add scheduledAt column to jobs table.
• When user sends sms command, create a job added to the scheduled queue & set scheduledAt(i.e. when the job should be run)
• Create a new worker that only pulls jobs from the scheduled queue & move them to the enqueued queue if scheduledAt <= time.Now()
• The scheduled job should have ["probe_max_retries"] arg set to 0. So after the user's dynamic probe triggers, if they don't reply, immediately mark as unavailable & contact emergency contact.

Enhancement:

• Move this logic into a database query:

  kronus/server/pbscheduler/pbscheduler.go

  Lines 126 to 138 in 14355ab

  	// Only send out followup probe after at least 1 hour after the last probe was sent,
  	// until max-retries. So the user has enough time to respond.
  	//
  	// E.g sendInitialProbe @ 5:OOpm
  	// Follow up 1 will be @ ~6:00pm
  	// Follow up 2 will be @ ~7:00pm
  	// Follow up 3 will be @ ~8:00pm
  	//
  	// And if no respons, @ ~9:00pm send out emergency probe
  	if time.Since(*probe.UpdatedAt) < 1*time.Hour {
  	continue
  	}

Note:

• Perhaps multiple retries & shorter wait times for dynamic probes
• The ability to do this via text should be deprecated at some point, but the feature can still be used in a diff interface

Right now, email & phone_number column in contacts model is set to unique. This shouldn't be the case.

• Option 1: Replace the constraints with user_id_phone_number & user_id_email
• Option 2: Just remove the constraints

• #13
• #24
• Increase version number & update readme.md
• Publish package

Send link with probe, to get user location via browser & store location for each probe

Benefits:

• Simple

Problems:

• Information is not realtime
• Requires very frequent probes to make information more useful
• User experience is not great

Constraints:

• With the use of links, no need to receive Y/N response. Clicking on the link indicates you're okay & sends your location. However, we need to still be able to send Y/N response, for cases where the user has no internet or doesn't want to send location info.

Questions:

• Should the link have Y/N option ? Or should clicking the link prove you're okay ?

Todo:

• Move entire probe verification to web app. User gets' notified with link & they click to verify aliveness
• Given the current constraints, make it as user friendly as possible.
  • Ask user on web_page to include location co-ordinates

Later:

• We could have a mobile app that auto transmits location on each probe