Preliminary Design: Sign-In, Builder Profiles, and Comment System

Working Context

DataInsideData™ is evolving from a static portfolio/blog platform into a more interactive technical platform.

The current Builder Showcase pipeline already supports:

public submit form
→ Supabase Edge Function
→ builder_project_submissions
→ review queue
→ promotion into builder_projects
→ static publishing to the DataInsideData™ site

The next major platform idea is to eventually support:

sign-in
builder identity
project ownership
comments/discussion
moderation
community interaction

This document is a preliminary design note so the platform can grow intentionally instead of bolting on identity and comments later without a plan.

Why Sign-In Matters

Sign-in is not just a login screen.

For this platform, sign-in can eventually support:

builder profiles
claiming submitted projects
editing project submissions
commenting on projects/posts
saving projects
following project updates
moderation workflows
admin review tools
future AI-assisted resume/project feedback

The goal is not to add sign-in just because modern apps have sign-in.

The goal is to support trusted interaction.

Why Comments Matter

Comments can support the learning and portfolio ecosystem around DataInsideData™.

Potential comment use cases:

readers asking questions on technical posts
builders receiving feedback on showcase projects
learners discussing implementation details
admins leaving review notes
future mentors or reviewers giving structured feedback

Comments should not be treated as a simple “drop a comment box under every page” feature.

They need:

identity
moderation
spam protection
reporting
visibility controls
auditability

This is especially important because DataInsideData™ is about technical credibility, project evidence, and community learning.

Guiding Principle

The platform should encourage productive builders while protecting the quality of the site.

The rule is:

Make it easy for real people to participate.
Make it difficult for spam, impersonation, and low-quality abuse to scale.

The first sign-in version should be lightweight.

Recommended first options:

GitHub login
email magic link

GitHub login fits the Builder Showcase because projects are already GitHub-centered.

Email magic link is useful for non-GitHub visitors, future commenters, and general readers.

Avoid password-based login in the first version unless there is a strong reason to manage passwords directly.

Possible Identity Model

A future builder_profiles table could connect authenticated users to public-facing builder information.

Example concept:

builder_profiles
- id
- auth_user_id
- display_name
- github_username
- public_bio
- portfolio_url
- website_url
- avatar_url
- created_at
- updated_at

This would allow the platform to separate:

authentication identity

from:

public builder profile

That matters because not everything about an authenticated account should automatically become public.

Project Ownership Concept

Eventually, a submitted project could be connected to a signed-in builder.

Possible future relationship:

builder_profiles.id
→ builder_project_submissions.builder_profile_id
→ builder_projects.builder_profile_id

This would support:

builder dashboard
edit requests
claim project
view submission status
submit multiple projects
project history

For now, project submissions can remain email/GitHub based. Sign-in can be added later without breaking the current workflow if the data model is planned carefully.

Comment System Scope

Comments should be scoped to content.

Possible comment targets:

blog posts
fixes
how-tos
builder showcase projects
financial intelligence lab posts

A flexible comment table could support multiple content types.

Example concept:

comments
- id
- author_user_id
- author_display_name
- target_type
- target_slug
- parent_comment_id
- body
- status
- created_at
- updated_at

Example target_type values:

post
project
fix
how_to
financial_lab_note

Example status values:

pending
approved
hidden
rejected
spam

This keeps comments flexible without creating a separate table for every content type.

Moderation Model

Comments should not go public automatically in the first version.

Recommended MVP flow:

signed-in user submits comment
→ comment status = pending
→ admin reviews
→ approved comments display publicly

This is slower, but safer.

Later, the system can become more flexible:

trusted users auto-approved
first-time commenters moderated
flagged comments hidden
spam signals reviewed

But the first version should prioritize control and safety.

Comment Visibility

Public pages should only display:

approved comments

Admin tooling can view:

pending
approved
hidden
rejected
spam

This allows the public site to stay clean while still preserving review history.

Security and Row-Level Security

Sign-in and comments must use Row-Level Security carefully.

Basic policy direction:

authenticated users can create their own comments
users can view their own pending comments
public visitors can view approved comments
admins can review/update comment status
users cannot edit other users' comments
users cannot approve their own comments

This is one of the reasons comments should not be rushed.

The data model, policies, and admin workflow need to be designed together.

Spam Protection

The comment system should reuse lessons from the Builder Showcase intake form.

Useful protections:

honeypot field
frontend cooldown
backend duplicate checks
user-agent/origin/referer logging
IP hash logging with salt
Turnstile or CAPTCHA later
moderation queue

Comment spam is more likely than project-submission spam, so comments should be protected from the beginning.

Privacy Considerations

Sign-in and comments introduce more responsibility.

The platform should clearly explain:

what account information is stored
what profile information is public
what comment information is public
what technical metadata is collected for security
how users can request removal or correction

Any use of hashed IP or request metadata should be treated as security/anti-abuse metadata, not analytics.

This should eventually be reflected in the Privacy Policy.

Phase A: Planning Only

Current phase.

Define:

auth goals
comment scope
identity model
moderation model
privacy posture
database shape

No code required yet.

Phase B: Authentication Prototype

Add sign-in on a test route only.

Possible test page:

/labs/sign-in-test/

Goals:

test GitHub login
test email magic link
confirm auth session
display signed-in user identity
sign out

No public comment system yet.

Phase C: Builder Profile Prototype

Add basic builder profile creation.

Goals:

signed-in user can create profile
profile can link to GitHub username
profile can be public or private
admin can connect profile to submitted projects later

Phase D: Private Comment Prototype

Add comments in a non-public test area.

Goals:

signed-in user can submit comment
comment enters pending status
admin can approve/reject
approved comments display on test page

Phase E: Public Comment Rollout

Enable comments on selected content types.

Start narrow:

Builder Showcase project pages only

Then expand later:

selected fixes
selected how-tos
selected blog posts

The first public comment target should probably be:

Builder Showcase project pages

Why?

Because those pages are naturally project-centered and community-feedback oriented.

A project page comment section can support:

questions
feedback
implementation discussion
builder clarification
review notes

This fits the mission better than turning every blog post into a comment thread right away.

What Not to Do Yet

Do not rush into:

open anonymous comments
unmoderated public comments
full social network features
likes/follows/reactions
password-based auth
complex notification systems

Those can come later if the need becomes real.

The first goal is trusted interaction, not social media.

Near-Term Decision

Sign-in and comments should be planned now but not implemented before the current Builder Showcase hardening is complete.

The current order should be:

finish Phase 3 hardening
test the intake system
commit stable milestone
document architecture
then prototype auth/comments in a separate branch

This keeps the current pipeline stable while giving the next platform layer a clear direction.

Final Design Philosophy

The Builder Showcase is not just a place to display projects.

It is becoming a system for:

project evidence
technical storytelling
builder credibility
review workflows
community learning
career-facing proof of skill

Sign-in and comments should serve that mission.

They should help real builders, learners, reviewers, and readers interact around meaningful technical work.

The goal is not just interactivity.

The goal is trusted, useful, well-governed interaction.

TODO

turn it into an actual architecture doc with ERD tables, RLS policy sketches, and a first auth prototype plan.