Sharing

Setup history sharing

Share your history to your friends
Never share a cloud sync QR code/link with anyone, as this may result in your data being merged.

You can share your history with your friends directly in the app. They will have a live access of your history. The access is read-only, they can't start or edit any change of your history.

About Cloud Sync

Share your history

Once cloud sync is enabled, go to your history page, in actions bar, use

History sharing
's action.

A dialog box will prompt you to enter the sharing name (e.g., the name/username of the person you want to share your history with). You can also allow or not allow the access to your accident history.

You can then send the generated link to your friend.

Sharing links must not be shared publicly. They can only be used once!
You can generate as many links as you want. A link is for single use.

Simply open the sharing link on your phone. The DiapStash app will automatically detect it. If it doesn’t work (or if you are using the web version), you can use the Use link option in the app’s settings to paste the link manually.

Once the link is activated, the app will ask you to name the share. This name will identify the share in the tab bar of the history section.

Q&A

How I can revoke or edit the access to my history ?

You can revoke or edit any sharing in Manage Sharing settings.

Manage Sharing

Why you can't interact with shared histories

Shared histories are only available in read-only mode. This is a technical choice. Interacting with a shared history requires performing verifications and modifications on multiple elements. These actions are currently done directly in the application.

To perform these actions in shared history, we would need to perform these actions on the server side. This cannot be done in the application because we need to ensure that people accessing a history have all the necessary permissions. This would therefore involve duplicating the code so that it is both in the application and on the server side. Code duplication creates major risks of bugs related to processing differences, and would involve doubling the work to be done with each code modification. Moreover, since the application is distributed progressively (it generally takes 1 week for a majority of users to be on the most recent version), we would need to ensure that the server adapts its behavior according to users. This technical choice is therefore made to guarantee maximum stability and without adding workload (the application is developed in my free time).

Furthermore, we would need to adapt the application interface to indicate to each user which history they are manipulating. This can be complicated to propose due to the fact that we must ensure that the entire application is usable on very varied screen sizes.

Notifications

Both the owner and the recipient of a shared history can enable push notifications to stay informed about activity on the shared history.

The following notifications are available:

  • Start of change on shared history: Notified when a change is started on the shared history.
  • End of change on shared history: Notified when a change ends on the shared history.
  • Accident on shared history: Notified when an accident is recorded on the shared history.

You can configure these notifications from Settings > Notifications > Manage Sharing notifications.