temp draft of new content

content/notes-ramblings.md

@@ -24,5 +24,4 @@ It's _very_ stream of concious-y and often not super coherent so often there gap
 
 ## Design things
 
-* Nothing Yet
-
+* :wave: [Bubble Chat and it's User Data](/notes/rationalizing-user-data)

content/notes/rationalizing-user-data.md

@@ -0,0 +1,43 @@
+---
+title: Rationalizing User Data
+description: "Like how do I approach storing sensitive user data in Bubble?"
+date: 2025-01-07T21:34:12-08:00
+draft: false
+category: article
+---
+
+
+This is a stream of concious post where I go through the process of figuring out 
+how I am going to store user data in my [bubble project](https://git.shockrah.xyz/shockrah/bubble)
+
+Schema for the users can be found here: [link](https://git.shockrah.xyz/shockrah/bubble/src/branch/main/db/setup-tables.sql)
+
+
+# Pre-requisites
+
+* Using Postgres 
+* Hashed and salted passwords
+
+# User ID's
+
+By default I was going to use regular ID's that increment on each insertion.
+Considering using some form of UUID's for the sake of a slight increase in sec.
+Even though this isn't a major form of security, every layer towards
+better security counts, and I see this as one more layer to add.
+
+
+UUID's tend to suffer from indexing issues but later versions of UUID seem to
+have this figured out.
+
+After some reading v7 seems like the move.
+
+* Time based meaning sorting ( and thus searching ) is reasonably performant
+* Sufficient entropy for this case ( 74 bits ). We want ****some* entropy but also
+don't want to nuke performance
+* While we want to make it harder to guess, aiming for "unguessable" is just not
+reasonable. UUIDv4 is best for that but compromises performance so hard it's not
+worth it in the grand scheme of things
+
+
+IDK v7 feels like a good middle ground for security + performance for the **user id**
+