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.

Status

PENDING REVIEW

What does this PR accomplish?

• Uses "characters" instead of "letters" to describe the minimum passphrase length in the related alert
• Updates the documentation accordingly

Note Although it might seem like nitpicking, the distinction between letters and characters is quite important when it comes to the password complexity.

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.

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

https://github.com/getify/youperiod.app/pull/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

Please see my note here:

https://github.com/getify/youperiod.app/pull/10#issuecomment-1174441718

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.

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.

Changes

closes #51

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

Checklist

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings

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.

Changes

This PR adds some sane defaults re: code formatting. It attempts to explicitly communicate and set the code style rules for the whole project.

I've envisioned three stages for this PR:

1. Add .prettierc and define all the rules (code review process should be used for discussion)
2. Install Prettier as a dev-dependency and create a script that would format the code
3. Finally, commit the formatted code to the code base as the new baseline

Warning Formatting the code with these new rules will create a huge diff. It is somewhat painful step and it is crucial to get it done as early as possible for that very reason.

Type of change

• [x] New feature (non-breaking change which adds functionality)
• [ ] This change requires a documentation update (quite possibly, not sure yet)

Checklist

• [ ] My code follows the style guidelines of this project
• [ ] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [ ] My changes generate no new warnings

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

Changes

The core part of this is functionality is done, the design and placement is kind of rough, I assume the design will get picked up else where in work.

• I have used the EFF's version of diceware as the original version contains inappropriate and problematic words.
• Word count support.
• (Possible) support for different languages.
• CSP connect-src changes to support reading wordlist file.

Adds feature #4

Type of change

• [ ] Bug fix (non-breaking change which fixes an issue)
• [x] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] This change requires a documentation update

Checklist

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [ ] I have commented my code, particularly in hard-to-understand areas
• [ ] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings

Changes

Created a calendar.html, calendar.css and calendar.js (separated out the css because didn't want to interfere with the base css as I worked through it all)

I looked at the sigma and added spaces for each thing on the dash board but the calendar is the only part with function so far. This creates the calendar of the current month and marks the current date. It also allows the user to use the arrows next to the month/year info to go forward and backwards to a new month. It populates the month with what should be the correct first day of the month and the total days.

There are some classes in the css that would be used to display the predicted period if that is a feature, a logged period and the flow of the logged period if add. The js for that isn't made yet because I just thought about that but wanted to push a smaller pull request instead of giant change files.

Fixes #53

Type of change

• [x] New feature (non-breaking change which adds functionality)

Checklist

• [x] My code follows the style guidelines of this project
• [x] I have performed a self-review of my own code
• [x] I have commented my code, particularly in hard-to-understand areas
• [x] I have made corresponding changes to the documentation
• [x] My changes generate no new warnings

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

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

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

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.

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.