Follow-up (~2026-11-04): Revisit Facebook OAuth + Meta business verification

[auerbachb]

Context

Tickler for revisiting Facebook OAuth (#285), which was deferred on 2026-05-04 because Meta requires business verification documents that Still Point doesn't have as a personal/hobby project. See #341 for full context, decision options, and code preservation status.

When to act on this issue

Around 2026-11-04 (~6 months out).

What to check / decide

1. Has Still Point's business situation changed?

   • Did you form an LLC for it? → can proceed with Meta verification
   • Did you file a DBA? → can proceed with Meta verification
   • Still personal hobby project? → continue deferring, bump this issue another 6 months

2. Is Facebook still worth the effort?

   • Check current sign-in usage: how many users use the existing OAuth providers (Google, Apple, Microsoft)?
   • If Facebook would meaningfully expand reach → worth the verification overhead
   • If existing providers cover the audience → close Backlog: Facebook OAuth blocked on Meta business verification requirements #341 + this issue as "won't fix"

3. Has Meta's verification process changed?

   • Sometimes Meta loosens requirements (e.g., for non-commercial apps); occasionally check their developer docs in case the gate is different now
   • https://developers.facebook.com/docs/development/release/business-verification

Outcomes & next steps

• Proceeding with verification: reopen Backlog: Facebook OAuth blocked on Meta business verification requirements #341, gather documents, complete Meta verification, reopen PR feat(auth): Facebook OAuth provider (#285) #326 (or rebase equivalent), test, merge
• Still deferred: bump this issue forward another 6 months, add a comment with the current rationale
• Abandoning: close Backlog: Facebook OAuth blocked on Meta business verification requirements #341 and this issue with the rationale; remove any stale Facebook code references in the codebase if they exist

Acceptance criteria

• Business situation re-evaluated
• Decision made: proceed / continue deferring / abandon
• Action taken to match the decision
• Issue closed (if decision is reached) OR rescheduled with comment

Related

• Backlog: Facebook OAuth blocked on Meta business verification requirements #341 — Backlog: Facebook OAuth blocked on Meta business verification (the umbrella deferral)
• OAuth: Facebook provider setup + integration #285 (closed) — original OAuth setup issue
• PR feat(auth): Facebook OAuth provider (#285) #326 (closed) — preserved code branch cursor/facebook-oauth-285-aaff
• Follow-up (~2026-06-01): Check Microsoft tenant recovery status for bretton.auerbach@gmail.com #333 — sibling pattern: Microsoft tenant recovery follow-up (~2026-06-01)

[github-actions]

@coderabbitai plan

[coderabbitai]

Coding Plan

Summary

• This is a decision/evaluation ticket, not a coding ticket — the primary deliverable is a documented decision based on three criteria: business status, user demand, and Meta's requirements
• The plan provides conditional execution paths for each possible outcome (proceed, defer, abandon)
• Code changes are only required if abandoning (cleanup of stale references) or proceeding (reactivating PR #326)
• All evaluation findings should be documented in issue comments to preserve institutional knowledge for future reviews

Design Choices

Design Choice 1: Current business status of Still Point

Options Considered:

1. LLC/DBA has been formed → can proceed with Meta business verification
2. Still a personal hobby project → must defer or abandon

Chosen Option: 1

Rationale: This must be determined by the project owner before any technical work begins. The plan provides paths for each scenario.

Design Choice 2: Current user demand for Facebook OAuth

Options Considered:

1. Significant user segment would benefit from Facebook → worth verification overhead
2. Existing providers cover the audience → abandon Facebook OAuth effort

Chosen Option: 1

Rationale: Requires analysis of sign-in usage data. The plan includes steps to gather this information.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Gather Decision Inputs

Collect the information needed to make an informed proceed/defer/abandon decision per the ticket's evaluation criteria.

Task 1: Assess Business Entity Status

Determine whether Still Point's business situation has changed since the original deferral.

• Check if an LLC has been formed for Still Point
• Check if a DBA (Doing Business As) has been filed
• Document the current legal/business status for the decision record

Task 2: Analyze Current OAuth Provider Usage

Review sign-in analytics to understand user authentication patterns and whether Facebook would meaningfully expand reach.

• Query or review analytics for OAuth provider distribution (Google usage, any Apple/Microsoft if enabled)
• Assess the user demographic and whether Facebook OAuth would serve an underserved segment
• Document findings on user demand for additional OAuth providers

Task 3: Review Meta's Current Verification Requirements

Check whether Meta has changed their business verification process since the original deferral.

• Review Meta's developer documentation at https://developers.facebook.com/docs/development/release/business-verification
• Note any changes to requirements (e.g., relaxed rules for non-commercial apps, new verification tiers)
• Document whether the verification barrier has changed

🤖 Prompt for AI agents

This phase involves no code changes. It is a research and information-gathering
phase to support a business decision.

- Assess whether Still Point has formed an LLC or filed a DBA
- Review sign-in analytics to determine OAuth provider distribution and user
demand for Facebook login
- Check Meta's developer documentation at
https://developers.facebook.com/docs/development/release/business-verification
for any updates to business verification requirements
- Document all findings in issue comments for the decision record

Phase 2: Document Decision and Rationale

Based on the gathered information, make and document the formal decision.

Make and Record the Decision

Synthesize the evaluation findings into a clear proceed/defer/abandon decision.

• Create a decision record summarizing: business status finding, user demand analysis, Meta verification status
• State the chosen path: proceed, defer 6 months, or abandon
• Provide clear rationale linking the decision to the evaluation criteria

🤖 Prompt for AI agents

This phase involves no code changes. Synthesize the findings from Phase 1 into a
documented decision.

- Create a decision record (e.g., as an issue comment) that summarizes: business
status finding, user demand analysis, and Meta verification status
- Clearly state the chosen path: **proceed**, **defer 6 months**, or **abandon**
- Provide rationale linking the decision back to the evaluation criteria
gathered in Phase 1

Phase 3: Execute Decision Path

Take the appropriate actions based on the decision made. Only one of the following task groups applies.

Task 1: If Proceeding — Initiate Facebook OAuth Implementation

Reactivate the deferred Facebook OAuth work and begin the verification process.

• Reopen issue #341 (Facebook OAuth blocked on Meta business verification)
• Begin Meta business verification process with required documents
• Once verification completes, rebase or recreate PR #326 from branch cursor/facebook-oauth-285-aaff
• Test the Facebook OAuth flow end-to-end
• Merge and close #341, #285, and this issue

Task 2: If Deferring — Reschedule Review

Push the evaluation forward another 6 months.

• Add a comment to this issue documenting the current evaluation results and rationale for continued deferral
• Update the issue due date to ~6 months from now
• Ensure #341 remains open with a cross-reference to the rescheduled date
• No code changes required

Task 3: If Abandoning — Clean Up and Close

Remove Facebook OAuth from the roadmap and clean up stale references.

• Close issue #341 with rationale comment explaining the abandonment decision
• Close this issue with the same rationale
• Optionally remove stale Facebook references from the codebase:
  • Remove commented Facebook env vars from .env.example
  • Remove Facebook comments from src/lib/auth-config.ts (lines 191-193)
  • Consider removing 'facebook' from the oauth_accounts CHECK constraint in future migration (or leave for potential future use)
• Delete or archive the preserved branch cursor/facebook-oauth-285-aaff if no longer needed

🤖 Prompt for AI agents

Execute only the task corresponding to the decision made in Phase 2. The three
possible paths are:

**If Proceeding:**
- Reopen issue `#341`
- Begin Meta business verification with required documents
- Once verification completes, rebase or recreate PR `#326` from branch
`cursor/facebook-oauth-285-aaff`
- Test the Facebook OAuth flow end-to-end
- Merge and close issues `#341`, `#285`, and this issue

**If Deferring:**
- No code changes required
- Add a comment to this issue documenting evaluation results and rationale for
continued deferral
- Update the issue due date to ~6 months from now
- Ensure issue `#341` remains open with a cross-reference to the rescheduled date

**If Abandoning:**
- Close issue `#341` with a rationale comment
- Close this issue with the same rationale
- Optionally clean up stale Facebook references in the codebase:
  - Remove commented Facebook env vars from `.env.example`
  - Remove Facebook comments from `src/lib/auth-config.ts` (lines 191-193)
- Consider removing `'facebook'` from the `oauth_accounts` CHECK constraint in a
future migration (or leave for potential future use)
- Delete or archive the preserved branch `cursor/facebook-oauth-285-aaff` if no
longer needed

Research

The codebase has OAuth infrastructure built on Auth.js (NextAuth v5) with Google as the only active provider. Facebook OAuth is reserved in the database schema (oauth_accounts CHECK constraint includes 'facebook') and referenced in comments, but has no runtime implementation. A preserved code branch cursor/facebook-oauth-285-aaff and closed PR #326 contain the deferred Facebook OAuth work. Stale references exist in .env.example, drizzle/ migrations, and src/lib/auth-config.ts as comments.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

This phase involves no code changes. It is a research and information-gathering
phase to support a business decision.

- Assess whether Still Point has formed an LLC or filed a DBA
- Review sign-in analytics to determine OAuth provider distribution and user
demand for Facebook login
- Check Meta's developer documentation at
https://developers.facebook.com/docs/development/release/business-verification
for any updates to business verification requirements
- Document all findings in issue comments for the decision record
===============================================================================

Task: 2

This phase involves no code changes. Synthesize the findings from Phase 1 into a
documented decision.

- Create a decision record (e.g., as an issue comment) that summarizes: business
status finding, user demand analysis, and Meta verification status
- Clearly state the chosen path: **proceed**, **defer 6 months**, or **abandon**
- Provide rationale linking the decision back to the evaluation criteria
gathered in Phase 1
===============================================================================

Task: 3

Execute only the task corresponding to the decision made in Phase 2. The three
possible paths are:

**If Proceeding:**
- Reopen issue `#341`
- Begin Meta business verification with required documents
- Once verification completes, rebase or recreate PR `#326` from branch
`cursor/facebook-oauth-285-aaff`
- Test the Facebook OAuth flow end-to-end
- Merge and close issues `#341`, `#285`, and this issue

**If Deferring:**
- No code changes required
- Add a comment to this issue documenting evaluation results and rationale for
continued deferral
- Update the issue due date to ~6 months from now
- Ensure issue `#341` remains open with a cross-reference to the rescheduled date

**If Abandoning:**
- Close issue `#341` with a rationale comment
- Close this issue with the same rationale
- Optionally clean up stale Facebook references in the codebase:
  - Remove commented Facebook env vars from `.env.example`
  - Remove Facebook comments from `src/lib/auth-config.ts` (lines 191-193)
- Consider removing `'facebook'` from the `oauth_accounts` CHECK constraint in a
future migration (or leave for potential future use)
- Delete or archive the preserved branch `cursor/facebook-oauth-285-aaff` if no
longer needed

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!