The app is currently (at time of this writing) a proof-of-concept for the registration/login/encryption portion of this app, involving Argon2 (WASM build) password hashing and AES-GCM 256-bit symmetric encryption/decryption. Data is persisted only in the client, using indexDB, while sessionStorage is used for tracking the login session (including storing temporarily the encryption/decryption key).

There's some nuances around needing graceful handling if the cryptography settings of the app are changed later and that ends up needing to upgrade someone's existing account, transparently and without data loss. That part was slightly tricky to get correct and robust.

Need to document more fully how the current JS code (split into several files, including a web worker) is architected, so THAT part of the behavior isn't lost when the code is worked on more significantly by other contributors. Also need to document the parts of the static file server that are important, given they are sending out some very specific and important security headers for different types of responses.

All the JS code that handles UI stuff is fine to re-org or throw away, that's all toy POC stuff. But the cryptography/security stuff is important to not be messed with.

Please see my note here:

#10 (comment)

If this is interesting to you, please speak up, or reach out to me privately [email protected].

Is your feature request related to a problem? Please describe.

There are number of features and processes that have been proposed at a lower level. I believe it is as important to have a high level overview of the project direction. It can help to address certain areas like:

• High priority features
• Features to be worked on next
• Features currently being worked on
• Versioning systems
• Timelines
• Milestones
• Potential features
• etc

Describe the solution you'd like

For start a simple document describing important project goals and Milestones:
https://mozillascience.github.io/working-open-workshop/roadmapping/

Add an education page.

Need a page that would seek to educate users on topics related to menstruation cycles including:

• What to Expect for those who have yet to have a period, or those who have only started their periods (some content in the post below)
• How contraceptives (eg, the Pill, mini Pill, IUDs, implants) affect menstruation
• Postpartum menstruation for those who have recently given birth and/or are expecting to give birth
• Some sort of a when-to-see-a-medical-provider page

Possibly FAQ style, should have links to medically credible sources as reference

Per #3 -- suggested to work out copy here before HTML

I just happened to stumble upon this video: Building a Containerless Future with WebAssembly.

It might be related to what you're building here.

WebAssembly is the future of distributed computing. Its security, memory isolation, small footprint, and true portability are all advantages on the web, but become truly game-changing when used to build functions and services deployed in the cloud. This session illustrates how to host WebAssembly modules in Rust code, how to build modules in many different languages (including pros and cons of each), and how to securely grant cloud-native capabilities to these modules. Discussed in detail is the current state of the art in WebAssembly and what can be built with it today. Learn what developers can start doing now to build the containerless future where WebAssembly modules are the de-facto unit of immutable deployment in the cloud, at the edge, and even in IoT and embedded devices.

some way on the registration screen to get suggestions for passphrases (diceware, etc).

I would suggest to change the license with this, that will prevent the unethical usage of the code of the app

https://firstdonoharm.dev/

Is your feature request related to a problem? Please describe.

It would be nice to have some kind of protection on the app itself.
What do I mean? Anyone can go through your phone and access the app. For example, I'm thinking how customs have the right to go through your phone without a warrant in an airport, or if you are in an abusive relationship they can do the same. Are there any proposals for this?

Describe the solution you'd like

Some ideas that come to mind: pin protected app, easy to access wipe functionality

Add calendar to app.

• The calendar should highlight today's date
• The user should be able to navigate into the past in the calendar

Possible considerations:

• A date on the calendar may have a different display if there is a period logged for that day in the data
• A date may have a different display if it is a projected period date

Is your feature request related to a problem? Please describe.

A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Describe the solution you'd like

A clear and concise description of what you want to happ

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

Add any other context or screenshots about the feature request here.

I don't know if I'm missing something, but cannot find a page about what the project does exactly?

Thanks

Add a privacy policy page. This issue: #3 has some initial copy suggestions.

If you would like to work on this issue, please go ahead and open a PR, ensuring your PR mentions "closes #50 "

Since web workers (loaded from separate files instead of inline blobs/data-uris) do not respect the hosting document's CSP policy, they are potentially slightly less secure. There's a way to fix that though:

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers#content_security_policy

Need to have server.js (around this line) check for the request for "auth-worker.js", and to set a specific CSP just for that worker response -- a derivative subset of this base CSP policy, but in particular setting the script-src to include only self and wasm-unsafe-eval.

Since each developer uses a different style to format his/her code, the code may look more and more inconsistent as the project grows.

I think having a prettier config file, at these early stages, would help to keep the code consistent and more readable in future.

Need to implement JS functionality (and some UI and carefully considered wording to the user) around opting the storage of this app (indexDB) into "persistent storage" mode.

More info here: https://web.dev/persistent-storage/

This is a tricky piece of functionality, because how it works and how it appears to users varies cross browser, and it can also sound a little "scary" to users -- like in violation of the core principles of this project -- if messaged poorly.

In detail...

1. We need to check if the user's device supports "persistent storage" (a web platform feature). If not, we need to explain to the user the implications of not having their data stored in such a protected/resilient state, and the risks of them continuing to save their information on that device and in this app.

2. But if the device supports this feature, need to have a message that comes up, sometime after the user has registered and logged in the first time, but not right away. Probably when they go to enter their first piece of "real" data (not just account info or settings).

3. The messaging needs to be something along the lines of (but not this exact wording, because I'm not a skilled copy writer):

   Since the data you enter in this app only ever resides on this device, and we assume you want to keep your data as safe as possible, we'd like to request the device to elevate its protection of your data in this app -- what is referred to as "persistent storage" (again, on this device only). This protection will help prevent your important information from accidentally being discarded by the browser or device, as happens on occasion with typical web data. If you agree, once you click this button, your device may offer you an additional confirmation prompt, or it may simply grant the permission, depending on your device type and settings.

   Like I said, that's wordy and needs a lot of cleanup. But it's a tricky and delicate thing to explain to the user why we need to ask this, and also to help them understand what the device prompt is about (in cases where the device pops it up) so they're not surprised by it and deny the permission.

   We also need to carefully but firmly explain that if they do NOT agree to this, their data is less safe and subject to potential loss at some point that's not much in our (or their!) control.

4. Once we have properly and successfully received the user's permission to do this, we call an API to try to get the persistent storage mode activated. A promise will resolve letting us know if that was successful. If so, great. If not, we need to message the user similarly to if the device didn't support such storage, explaining the risks of continuing use without that protection in place.

5. Moreover, there's another API we need to call from time to time, perhaps once per session, but not all the time, which essentially re-checks to see if the storage is persistent. Once granted, it should stay granted forever, but it's possible some devices/settings might someday revoke it. If it has been revoked, we might end up then needing to re-prompt the user for continued persistent storage permission, so again need careful messaging like the above to warn them about what's happening.

I want to contribute to this open-source world-changing project. and I want to work on UI/UX Designing.

I know this is going to be a PWA APP.
i was thinking that we can have a TWA from PWA, and since this is going to be open source, we can put it on F-Droid.
What do you think, can we think about this too?

Basic caching service worker needed, to make this an installable PWA. Probably should use a basic versioning system in it as well.

Add "Track" capability, where user will log bleeding for a specific date.

Considerations:

• Bleeding is the first thing to track, but other tracking will be added in the future
• This needs to be able to be considered into calendar display to display logged periods on the calendar

We need to have contribution guidelines and PR templates as well as issue templates.

Is your feature request related to a problem? Please describe.

Define the code style from the beginning of the project (aka now or ASAP) and set the guards that would "enforce" it. This has multiple benefits:

1. It will remove opinionated debates and potential flame wars
2. It will streamline contribution
3. It will save A LOT of time for both contributors and code reviewers by preventing redundant whitespace changes

Describe the solution you'd like

There is already .editorconfig in the project which is an amazing first step! It will set the tone for everything else.
However, it is a basic set of definitions which is easily "overridable", depending on the IDE and the preferences people set in their IDEs.

Note
Prettier integrates pretty nicely with editorconfig and will enforce and respect its rules, unless instructed otherwise!

Proposal:

• At the very minimum, add the prettier config that would extend editorconfig (#28)
• I'd also suggest adding eslint to the project but that could be a potentially sensitive topic and I'd leave it to @getify to define his own set of rules and checks, rather than going with any predefined ruleset

Next steps:

• Add a script that would auto-format the code
• Add pre-commit hook that would automate that process
• Add a basic lint check using GitHub Actions

Describe alternatives you've considered

A clear and concise description of any alternative solutions or features you've considered.

Additional context

#28 is WIP and a place where the initial discussion about Prettier config extending editorconfig should happen. Once complete and merged, this PR will:

• at the very least add a config
• at best add both the config and the lint script

Here's a few ideas for initial features:

1. we're going to need a way to easily see ranges of dates in the future for projected/expected periods, as well as the ranges in the past for actual periods (and compared to what was projected).

2. There will also be a sort of "daily check-in" during a period (or the days leading up to it) for self-reporting any symptoms or status of the menstrual flow, etc.

But especially for those who have seen/used period-tracking apps already, please speak up and help us plan out what features are needed, and details about how they need to work to be useful and as easy as possible UX wise.

Need an about page, a privacy policy page, maybe a couple of others.

We'll need to feature-test the browser someone uses, and warn them if they're using one that doesn't have the required APIs, that they unfortunately cannot use the app.

Here's the critical ones I can think of:

• WASM
• ServiceWorker
• Worker
• IndexedDB
• sessionStorage
• WebCrypto
• TextEncoder & TextDecoder
• StorageManager.persist

Basically, this will boil down to us not supporting IE <= 11 or Safari <= 11. So if they don't pass the tests, we need to disable the app from loading/doing anything else, and display a graceful message informing the user that their browser doesn't support the features necessary to keep their data safe and reliable.

APIs we might use, and the user should have (and perhaps be warned if they don't), but which are not strictly required:

• Notifications
• CredentialsContainer
• getUserMedia

Some features/settings of the app may have to be disabled if the necessary APIs aren't present.

Related to #2.

I kinda like the logo I originally designed for this, as can be seen in the attached image. But I'm not deeply attached to it. If someone comes up with some good variations on logo, we can certainly discuss them here.

More importantly, whatever logo we pick, we need:

1. SVG of it (with font glyphs changed to curves)
2. PNG of it in a couple of general sizes (small ~100px, medium ~400px, large ~1000px) on both transparent, light, and dark backgrounds
3. Favicon that is based on, or recognizable as related to, the logo. I had envisioned something like a red circle with a "Y" in the middle of it, as the favicon. But certainly open to input. The favicon should be square and have 16x16, 24x24, 32x32, and 64x64 resolutions embedded into it. I use an app (windows) called Icofx (v3) for making my own favicons like this.

Figured I should explicitly write out several things that may be helpful to reference in terms of technical decision making going forward:

1. I'm NOT going to act as a dictator (BDFL) for this project. Right now I'm the main/only core maintainer, and I own the server (and paid for the domain and SSL certs and upgraded DNS + DNSSEC). But those are, in my mind, temporary conditions that currently place me in a more authoritative role. Over time, I expect and hope that others will be promoted to core maintainer status, and as that happens, I fully expect to share decision making and even to defer to others on certain matters. So please don't think that I'm going to hold an iron grip over this project. I see myself as shepherd right now, and I will protect and fight for what I think is right, but over time, what's right is that it won't be only me doing so.

2. I hold a firm stance and belief that complexity of systems has to be fought at the individual decision level, and that means deciding to use restraint in including tools and processes unless and until those can be fully justified. There've already been a few conversations of that sort, such as discussion over using linter/style-formatter tooling (deferred for now, perhaps revisited later).

   I've also taken some criticism/disagreement in social media over publicly stating that the app won't be built on top of frameworks (like React/Vue/etc). I firmly believe apps should be built with the least technology necessary to accomplish the task. I'm not even remotely convinced either the app's complexity, or the complexity of our contributor organization/skills, will justify using a framework. That fits with my general feeling that most apps these days, even SPAs, don't actually need these tools, and that they're chosen more to prioritize dev UX and not to fit the actual technical needs of the system being designed. Will this app ever use those? I doubt it, but it's not impossible.

   I have a number of libraries I've authored, which I would LOVE to showcase in this project. But I haven't even remotely considering bringing any of them in. As much as I'd love to use the coding styles/approaches they enable, and as much as I'd love to be able to show off why I think they're awesome (they are!), that's not what is best for THIS project.

   Why? Because privacy/security/safety are THE MOST IMPORTANT FEATURE, period. End of story. The increase in surface area for the code this app uses exponentially increases the risks, especially as it relates to proper security auditing (hopefully by independent parties eventually). It also harms general developer readability to have more code in the code base than is strictly necessary, since that's more to read, more to learn, more to understand.

   I don't judge the supposed developer productivity increases of using popular frameworks/libraries/tools like that, to outweigh the importance of minimizing, wherever possible, what code exists in this app, and certainly what "third party" code is included. Plain and simple. My libraries aren't going to be used (probably), and other frameworks and libraries also aren't going to be used (probably).

   The few exceptions we make, to include third party code, will be deliberate and will have strong justification, not simply preferences. Right now, I already made the call to include three: idbKeyval (a very well known and super visible and trusted cross-browser tool for ironing out complications with storing data in indexDB), hash-wasm (specifically, the wasm build of the argon2 password-hashing algorithm), and base64-arraybuffer, a small but important chunk of code for efficiently AND CORRECTLY handling conversion of data to/from base64 string representation and binary array buffers (used in encryption/decryption). Why these 3? Because getting them wrong (by doing them ourselves) actually undermines the main principles of the app: privacy/safety/security. Since that's so important, and since the areas are so sensitive and difficult to get right, I judge that these 3 tiny libraries meet the bar necessary to be included.

3. The app is client-side only, and will remain that way with no stateful server (only stateless static file serving, with some important tweaks for security headers), despite how nice some server-enabled features might be (for devs and for users), UNLESS AND UNTIL we can justify such a (huge) inflection point change. I've got a running list of things a server could do for us, if we ever decide to cross that line, and we can discuss the merits and weigh things. But the default position is, this app runs client-only, and that user data is always encrypted and always local-only on their device. That fits with the main principles of the app, and is therefore how I justify such a position.

4. The app is using web technology on purpose, even though in some respects it would be better for the app if it were built with fully native technologies (Java, Swift/Obj-C, etc).

   Why? Because I deem the value of view-source for this app to be of sufficient importance to the overall project principles to override the arguments to the contrary. It's not enough, in my mind, that this app be open-source. It must be able to be audited, on any device, to guarantee and prove that it does what we say it does, no more, no less. Users cannot audit their native apps like that, but they CAN audit web apps. So we will embrace that.

   That leads to another perhaps surprising decision: we will not transpile, bundle, minify, or otherwise obfuscate any of the JS code of this app (other than including any third-party tools as previously discussed, in their distributed forms). Again, why? Because we are prioritizing lowering the barrier to being able to see, audit, and prove what this app is doing, and excluding from concern anything that it's not doing.

   NOTE: gzip compression is fine, and will be used, as it simply reduces bandwidth costs and serves the user better by increasing the initial install/load performance. But we'll be gzipp'ing fully open and readable JS code and delivering that to the browser. No funny business with source maps where the code running is even slightly different than the code the user or developer sees in the browser tools.

5. This app will be offline by default (again, client only), performant by default, and accessible by default. We will use, where appropriate, basic but important accessibility affordances in building this app, including but not limited to:

   • semantic HTML, native HTML form elements, alt-text on images, CSS for its intended/native purposes, etc
   • HTML aria attributes, like "role", "aria-label", "aria-live", "aria-atomic", etc
   • proper color contrast (see https://contrast-ratio.com and other similar tools)
   • keyboard, pointer, and other appropriate input events that are by default more accessible
   • etc

I will probably add more to this list as we go along, but hopefully this helps shed some light on the philosophies/principles I will be using in guiding the technical decision making of this project.

I welcome any and all input/feedback on these philosophies. I promise to listen to and respect dissent, but I don't necessarily promise to change these principles unless and until it becomes clear and justified to do so.

For the live proof-of-concept that's running on YouPeriod.app, I'm going to add a few simple (but important) features:

1. Add some basic popup messages to confirm success of saving data, or displaying any error message (instead of only in the console)

2. Add a "change passphrase" feature, which -- more complicated than it seems! -- has to upgrade the stored login-challenge AND safely re-encrypt the data without the possibility of data loss

3. Add a "delete my local profile and data" feature.

So, you'll see a few code changes to the web/* files soon regarding that. Just heads up.

I already have a growing list of capabilities/protections that an app like this could include, but which would require moving beyond simply a static file server into a more specifically tailored and integrated server.

This of course opens up a whole list of additional complexities/downsides, including cost, maintenance, security, governmental interference, etc. That means we should be very weary to do any such things, and only cross this bridge if we cand deeply and fully justify it, and have a plan for managing those complexities.

But in the interest of discussion, I want to list some of the ideas I am already contemplating, and invite others as well.

1. off-site/off-device backup: offer the option to either one-time or automatically upload the encrypted dataset from your device to the server. We would NOT include the decryption key itself, but would need to keep the other encryption params (algorithm, salt/iv, etc) necessary to reconstruct the key (provided the user remembers the passphrase). We'd also need some mechanism (like a hash challenge) and some unique identifier (email?) so that someone could prove, from a new device, that they are authorized to retrieve/decrypt that data. Complex stuff, but we could figure it out I think.

   Also considered is your own export-backup that you have to store somewhere (like google drive, etc). This has its own (many) downsides though.

2. Similar to backup, offer optional "device sync" where you can one-time, or somewhat-automatically sync your data from one device to another. Could generate a QR code one one device to scan from the other, to streamline. All the same complexity.

3. Perhaps a way around some of the complexity of device sync (but with its own complexity) could be direct device sync via webrtc (data channels) so that the actual data never even touches our server. Still need server for the webrtc signaling negotiation, etc.

4. Optional 2-factor auth (like RSA 6 digit code kind, NOT through SMS) to further secure your login/encryption.

5. Optional biometric auth (in web terms, using Webauthn API with FIDO on the server) so user could unlock/decrypt with fingerprint, face ID, etc, instead of inputting their passphrase.

Is your feature request related to a problem? Please describe.

Will the app be offered in multiple languages?

Describe the solution you'd like

I see the app is framework-less, and am curious about internationalization techniques which will be used here.

Is your feature request related to a problem? Please describe.

People will have a lot of questions about this project as it starts growing. Both the contributors and the potential users of the app. Using Slack for discussion is a common practice but it has many downsides and can be overwhelming for people who are not used to using it.

Also, if the key value of this app is privacy, Slack is probably not the best idea.

Describe the solution you'd like

Enable GitHub Discussions for this project to start building the community and the body of knowledge.

Describe alternatives you've considered

• Mattermost is almost identical to Slack but it is OSS
• Twist is an amazing Slack alternative and is much better suited for async communication

Additional context

In general, I'd suggest using the full GitHub ecosystem (wiki, projects, discussions, actions...). This is an OS project and as such it is eligible for a pretty generous free packages that GH offers.

Hey guys,

Noticed repository missing issue and PR templates.
So I am proposing to add issue (bug report, feature request) and PR templates to make things easier and as per conventions.

For better collaboration a contribution guideline will be needed as a reference.

Add an about page. This issue: #3 has some initial copy suggestions.

If you would like to work on this issue, please go ahead and open a PR, ensuring your PR mentions "closes #51"