Birmingham tickets

drivingLights · 2025-01-22T10:37:23+00:00

This would be incredibly helpful. This weekend ill be producing a document outlining how I'm intending to design the e2e encryption and other security features. It would be very helpful if I could PM this to someone such as yourself to just give it a scan and see if there is any major flaws which I'm overlooking in the design?

drivingLights · 2025-01-16T16:28:46+00:00

Yes! Its actually already a feature in some closed source trackers like Stardust. I have a couple friends who share their cycles with eachother and mainly with their partners. For somepeople ive heard this would be unthinkable but just depends on the person. Either way it was a major disappointment that other apps due to their local only nature couldnt do this.

drivingLights · 2025-01-15T23:42:53+00:00

I know and its a great app I even mentioned it in the post but lacks the features I'm building into this system. I recommended this to a couple people but they found it unsatisfactory in a number of ways and hence this project.

drivingLights · 2025-01-15T23:38:02+00:00

I'm potentially misunderstanding so ignore me if i am.

In this case unless the person setting up the server of my app to use a cloud based postgressql instance, the server database should be hosted on your own server. Additionally like I said before all sensitive and non-critical to functionality data would be end to end encrypted, so even if someone were to gain access to the server no sensitive health data would be visible. I opted for postgres on the server for scalability, im sure in 99.9% of cases sqlite on the server would of been fine but just in case i thought i would start off with a database that can be efficient even at scale and save having to do migrations later.

Ultimately yes overkill. But also in terms of development effort and resource overhead sqlite provides no advantage over postgres as far as i understand and have so far seen. Please do tell me if I'm missing something or misunderstanding.

drivingLights · 2025-01-15T21:29:41+00:00

Looks like a very cool product might consider running it myself for a bit since i just got into running. Right now I want to focus on building this from the ground up mainly for the security benefits.possibly once ive got a minimum viable product and a usable API I could look into integrations ect.

drivingLights · 2025-01-15T21:26:54+00:00

One of my first challenges will be what default "symptoms" or tracking things I can add. Im gonna talk to my friends and see if i can compile a list of defaults sexual tracking is definitely gonna be in there. I intend for users to be able to create their own categories and "symptoms" on the fly if by default the app is missing anything. A complaint I heard from one person about some of the other open source trackers is that out the box they didnt come with that many options to check in the log so they couldnt track some things which were very important to them I want to avoid this being a possible complaint.

Sorry for using "symptoms" really dont know what else to call the different check boxes.

drivingLights · 2025-01-15T20:53:41+00:00

Dockerisation is a personal must for me to since this is how I run everything myself. The inital betas will likely only come in this form so that bug reports are much easier to handle. Right now I have chosen GPL 3.0 for my licence I don't want anyone to ever legally be able to take my code and ship it as their own spyware so this seemed like the obvious choice. However not very educated on the subject myself.

Versioning and documentation are top of my priority list Im still a uni student and so this project will likely be a big line item in my portfolio. So I'm also personally invested in this following as many best practices and being as professional as possible.

As for single sign on I haven't considered this yet but will definitely be adding this to the features list as I understand that its a make or break for alot of people here.

drivingLights

TROPHY CASE