Skip to content

GuZZ1119/Pollux

Repository files navigation

Pollux

A permissions-aware AI communication copilot for email and team chat.

Pollux helps users review messages, generate context-aware replies, and send responses through the original platform — while keeping the user in control of every meaningful action.

Demo video: https://youtu.be/TH21j4cuX7Q


Overview

Pollux is a full-stack AI communication product built around a simple trust model:

  • users sign in explicitly
  • users connect communication platforms intentionally
  • AI helps with drafting, summarizing, and prioritizing
  • outbound actions remain visible and user-approved

Instead of copying messages into a separate AI tool, Pollux brings identity, account connection, message context, reply generation, and sending into one product surface.

Today, Pollux supports

  • Gmail: real inbox reading, real message detail retrieval, AI reply generation, real sending
  • Slack: real OAuth connection, real message reading, AI reply generation, real sending
  • Outlook: inbox access powered by Auth0 Token Vault through Connected Accounts
  • Dashboard / Inbox / Settings: polished product UI for daily use
  • Style Personalization: custom reply style learned from presets, writing samples, or Gmail sent mail
  • Daily Brief: AI-assisted summary of what happened today and what needs attention
  • Persistence: database-backed token storage, style profile storage, and send logs

The Problem

Modern communication is fragmented.

Important work is split across email, chat, and notifications. Most AI tools can generate text, but they often sit outside the real workflow. They do not clearly show what data they can access, what actions they are allowed to take, or how much control the user still has once the AI is involved.

That becomes a bigger issue when AI stops being just a writing tool and starts acting on behalf of users.

A trustworthy communication copilot needs more than good text generation. It needs:

  • clear identity
  • explicit platform connection
  • scoped access
  • understandable permission boundaries
  • strong human review before high-impact actions

Pollux is built around that model.


What Pollux Is

Pollux is a permissions-aware AI communication copilot.

It lets users connect the platforms they already use, view real messages in one interface, generate multiple AI reply options, personalize reply style, and send the final response through the original provider.

Core workflow

  1. Sign in with Auth0
  2. Connect Gmail, Slack, and/or Outlook
  3. View real inbound messages
  4. Ask Pollux to generate reply candidates
  5. Review and optionally edit the draft
  6. Send through the original platform where supported
  7. See activity reflected in summaries, send logs, and the unified inbox flow

Why This Matters

Pollux is not only about replying faster.

It is a product exploration of a larger question: how should AI systems act on behalf of users inside explicit authorization boundaries?

Pollux makes that question concrete by showing:

  • explicit connection flows instead of hidden access
  • platform-aware actions rather than detached text generation
  • user review before sending
  • separation between identity, connected accounts, and AI-assisted actions
  • a UI that makes the workflow feel understandable rather than magical

That makes Pollux relevant both as a useful communication product and as a practical prototype for safer agent authorization patterns.


Core Features

Unified AI inbox

  • Aggregate connected communication channels into one product surface
  • Support provider-aware rendering for Gmail, Slack, and Outlook
  • Show source, risk, message status, and interaction state in one view

Real Gmail integration

  • Gmail OAuth connection flow
  • Real inbox retrieval through Gmail API
  • Message detail parsing with MIME handling
  • HTML email sanitization with DOMPurify
  • Attachment metadata extraction
  • Real reply sending via gmail.users.messages.send
  • Thread-aware sending using Gmail thread context

Real Slack integration

  • Slack OAuth connection flow
  • Real message retrieval from accessible channels and DMs
  • Provider-aware message fetch and send paths
  • Real reply sending via Slack API with thread support

Outlook via Auth0 Token Vault

  • Microsoft account connection through Auth0 Connected Accounts
  • Outlook inbox access powered by Auth0 Token Vault
  • Provider access retrieved through Auth0 rather than app-managed Microsoft refresh tokens
  • Microsoft Graph inbox reads normalized into the shared MessageItem model
  • Outlook messages surfaced in the same inbox UI as Gmail and Slack

In the current version, Outlook is implemented as a Token Vault-powered inbox provider path. Gmail and Slack remain existing direct integrations.

AI reply generation

  • Multiple reply candidates per message
  • OpenAI-backed generation with graceful fallback
  • Prompt-injection-aware prompt design
  • Provider-sensitive tone differences between email and chat
  • Reply source labeling for transparency

Style Personalization V1

Users can build a personalized writing profile through four paths:

  • start from a preset
  • learn from recent Gmail sent mail
  • upload writing samples
  • paste writing samples directly

The resulting style profile can include:

  • tone rules
  • banned phrases
  • sign-off patterns
  • greeting patterns
  • directness level
  • hedge-word preferences
  • representative writing examples
  • user guardrails

Daily Brief

  • Summarize today’s communication activity
  • Highlight high-attention items
  • Extract action items
  • Break down activity by provider
  • Support rule-based generation with AI upgrade and fallback
  • Cache summary generation for better stability and cost control

Reliability and persistence

  • Gmail tokens persisted to Neon PostgreSQL
  • Slack tokens persisted to Neon PostgreSQL
  • Style profiles persisted to Neon PostgreSQL
  • Send logs persisted for traceability
  • Backend-driven message fetching for reply and send consistency
  • HMR-safe in-memory caching patterns for local development
  • Better local development handling for ngrok / OAuth domain consistency

Security, Authorization, and User Control

Pollux is designed so that AI assistance stays inside explicit boundaries.

Principles

  • Explicit sign-in

    • User identity is handled through Auth0.
  • Explicit provider connection

    • Gmail and Slack access are granted through dedicated OAuth flows.
    • Outlook is connected through Auth0 Connected Accounts.
    • Platform access is not assumed or bundled invisibly.
  • Scoped access

    • Pollux only operates with the scopes granted to the connected provider.
    • Gmail and Slack connections are handled directly in the app.
    • Outlook access is retrieved through Auth0 Token Vault.
  • Human-in-the-loop sending

    • AI drafts suggestions.
    • The user still reviews and approves the message before it is sent.
  • Backend consistency for sensitive actions

    • Reply generation and sending prefer backend-fetched real message context rather than trusting the frontend alone.
    • This reduces mismatch between what the user saw and what the system sends.
  • Visible action channels

    • Send results are surfaced clearly, including whether a reply was sent through a real provider path or a fallback path.
  • Safe rendering

    • HTML email content is sanitized before rendering.
    • Suspicious prompt-like instructions in inbound messages are treated as untrusted content in the generation pipeline.

Auth model in practice

Pollux separates three layers:

  1. Who the user is
    Auth0 session and identity

  2. What Pollux can access
    provider-specific connection state and granted scopes

  3. What Pollux can do
    summarize, draft, and prepare replies — with the final send action remaining user-approved

In the current architecture, Auth0 powers product authentication and session management across Pollux, and also powers the Outlook provider path through Connected Accounts + Token Vault. Gmail and Slack remain existing direct integrations.


Demo

The video is the fastest way to understand the Gmail / Slack workflow and the Outlook authorization path powered by Auth0 Token Vault.


How It Works

User flow

  1. Sign in to Pollux
  2. Connect Gmail, Slack, or Outlook
  3. Open the Inbox
  4. Pick a message
  5. Generate AI reply candidates
  6. Select or edit a draft
  7. Send through Gmail or Slack where supported
  8. Review Daily Brief or continue triage

Technical flow

  1. Auth0 establishes authenticated product access
  2. Gmail or Slack OAuth connects direct providers
  3. Outlook is connected through Auth0 Connected Accounts
  4. Provider adapters fetch normalized message data
  5. For Outlook, Pollux retrieves provider access through Auth0 Token Vault
  6. Message detail is parsed and normalized into shared internal types
  7. Reply generation builds prompt context from:
    • message content
    • sender / subject / provider
    • user style profile
    • representative writing examples
    • guardrails
  8. The user chooses a draft
  9. The backend re-fetches authoritative message context when needed
  10. The message is sent through the platform-native API where supported
  11. Send logs and style/persistence state are stored in PostgreSQL

Architecture Overview

Pollux is structured as a modern full-stack web application with provider adapters.

Main layers

Frontend

  • Next.js 15
  • App Router
  • React 19
  • Tailwind CSS 4
  • polished Dashboard / Inbox / Settings experience

Identity and access

  • Auth0 for product login and session handling
  • direct provider OAuth flows for Gmail and Slack
  • Auth0 Connected Accounts + Token Vault for Outlook

Integrations

  • Gmail OAuth + Gmail API
  • Slack OAuth + Slack Web API
  • Outlook via Auth0 Token Vault + Microsoft Graph
  • provider adapter layer for inbox and send paths
  • backend message fetchers for authoritative message detail retrieval

AI layer

  • OpenAI-based reply generation
  • style-aware prompt composition
  • Daily Brief AI summary path with fallback
  • injection-aware prompt structure

Persistence

  • Prisma ORM
  • Neon PostgreSQL
  • token storage
  • style profile storage
  • send log storage

Reliability utilities

  • HMR-safe global caches for local development
  • summary caching
  • event logging
  • provider-aware fallbacks
  • ngrok-safe callback redirect handling via APP_BASE_URL

Tech Stack

Product and frontend

  • Next.js 15
  • React 19
  • TypeScript 5
  • Tailwind CSS 4

Backend and data

  • Next.js Route Handlers
  • Prisma 6
  • Neon PostgreSQL

Authentication and authorization

  • Auth0
  • Auth0 Connected Accounts
  • Auth0 Token Vault
  • Google OAuth
  • Slack OAuth

Platform APIs

  • Gmail API
  • Slack Web API
  • Microsoft Graph

AI

  • OpenAI API
  • gpt-4o-mini for reply generation and summary generation

Security and content handling

  • DOMPurify for sanitized HTML email rendering

Tooling

  • ESLint 9
  • PostCSS
  • ngrok for public local callback testing

What Was Built During the Hackathon

Pollux was significantly advanced during the hackathon period.

It moved from a minimal runnable scaffold to a multi-platform, persistence-backed product prototype with a polished UI and a complete end-to-end demo flow.

Major shipped progress

  • built the initial full-stack scaffold with typed domain models and mock adapters
  • added Auth0-based login flow
  • added Gmail OAuth connection flow
  • replaced mock Gmail inbox with real Gmail inbox retrieval
  • added MIME parsing, HTML rendering, and attachment metadata extraction
  • connected OpenAI-based reply generation
  • implemented real Gmail sending
  • introduced risk classification, inbox metrics, filtering, and event logging
  • polished the Inbox and Settings UX for demo quality
  • added Daily Brief and provider-agnostic summarization
  • shipped Style Personalization V1
  • migrated key state to Neon PostgreSQL
  • added backend-owned message fetching for more reliable reply/send behavior
  • upgraded Slack from mock to a real second platform
  • added an Outlook inbox path powered by Auth0 Token Vault
  • fixed OAuth redirect consistency for local + ngrok development
  • finalized the product into a submission-ready demo

This is not a static concept repo. It is a working product prototype with real provider integrations and a real user flow.


Running Locally

Prerequisites

  • Node.js 18+
  • npm
  • a Neon or PostgreSQL database
  • Auth0 application credentials
  • Google OAuth credentials
  • Slack OAuth credentials
  • Microsoft / Azure app registration for the Outlook Token Vault path
  • OpenAI API key for live generation

Install

npm install

Configure environment variables

Create .env.local from .env.example and fill in your credentials.

Typical variables include:

AUTH0_DOMAIN=
AUTH0_CLIENT_ID=
AUTH0_CLIENT_SECRET=
AUTH0_SECRET=
APP_BASE_URL=http://localhost:3000

DATABASE_URL=

OPENAI_API_KEY=

GOOGLE_CLIENT_ID=
GOOGLE_CLIENT_SECRET=
GOOGLE_REDIRECT_URI=http://localhost:3000/api/auth/gmail/callback

SLACK_CLIENT_ID=
SLACK_CLIENT_SECRET=
SLACK_REDIRECT_URI=

# Optional; defaults to windowslive
AUTH0_MS_CONNECTION_NAME=windowslive

Prepare the database

npx prisma generate
npx prisma db push

Start the app

npm run dev

Then open:

http://localhost:3000

Local OAuth Setup Notes

Auth0

Configure your Auth0 application with callback/logout origins for local development.

Typical values:

  • callback URL: http://localhost:3000/auth/callback
  • connected accounts callback URL: http://localhost:3000/auth/connect
  • logout URL: http://localhost:3000

If using ngrok, also include the public ngrok URL in Auth0 allowed origins.

Gmail

Configure Google Cloud OAuth redirect URI:

http://localhost:3000/api/auth/gmail/callback

Slack

For localhost-only development, Slack OAuth is limited because Slack expects a public callback URL.

For public local testing with ngrok:

  1. run npm run dev
  2. expose port 3000 via ngrok
  3. set APP_BASE_URL to your ngrok HTTPS URL
  4. configure the Slack app redirect URL to:
    • https://<your-ngrok-domain>/api/auth/slack/callback
  5. restart the dev server after changing environment variables

Pollux uses APP_BASE_URL to keep callback redirection consistent in proxied local environments.

Outlook via Auth0 Token Vault

For the Outlook provider path:

  1. create a Microsoft app registration
  2. set the redirect URI to:
    • https://<your-auth0-domain>/login/callback
  3. add Microsoft Graph delegated permissions such as:
    • User.Read
    • Mail.Read
  4. create a Microsoft Account social connection in Auth0
  5. enable Connected Accounts for Token Vault
  6. enable the connection for your Pollux app
  7. ensure your Auth0 app includes:
    • APP_BASE_URL/auth/connect in allowed callback URLs

Testing / Judge Quick Start

This repository is intended to be easy to review.

Fastest evaluation path

  1. Watch the demo video
    https://youtu.be/TH21j4cuX7Q

  2. Open the live app
    https://transnationally-jauntier-fritz.ngrok-free.dev

  3. Sign in

  4. Connect Gmail, Slack, and/or Outlook

  5. Open the Inbox

  6. Choose a real message

  7. Click Generate AI Reply

  8. Review the candidate drafts

  9. Edit if desired

  10. Send through Gmail or Slack where supported

  11. Open Dashboard to inspect the Daily Brief summary flow

  12. Open Settings to inspect style personalization and connection state, including the Outlook Token Vault path

What judges should look for

  • explicit sign-in and explicit provider connection
  • user-visible control before sending
  • real provider integrations
  • an Outlook authorization path powered by Auth0 Token Vault
  • backend / frontend coordination for trustworthy send behavior
  • polished end-to-end UX rather than isolated API demos
  • a product architecture that is aware of persistence, fallbacks, and local reliability issues

Demo / test credentials

Live app: https://transnationally-jauntier-fritz.ngrok-free.dev
Demo account: TBD
Test notes: TBD

Repository Structure

pollux/
├── prisma/
│   └── schema.prisma
├── src/
│   ├── app/
│   │   ├── dashboard/
│   │   ├── inbox/
│   │   ├── settings/
│   │   └── api/
│   │       ├── auth/
│   │       ├── inbox/
│   │       ├── reply/
│   │       ├── send/
│   │       ├── summary/
│   │       ├── style/
│   │       ├── events/
│   │       └── attachments/
│   ├── components/
│   │   ├── dashboard/
│   │   ├── inbox/
│   │   ├── layout/
│   │   ├── reply/
│   │   ├── settings/
│   │   └── shared/
│   └── lib/
│       ├── adapters/
│       ├── auth0.ts
│       ├── config.ts
│       ├── gmail/
│       ├── outlook/
│       ├── slack/
│       ├── openai/
│       ├── style/
│       ├── services/
│       ├── types/
│       └── viewed-store.ts
├── .env.example
├── package.json
└── README.md

Key directories

  • src/lib/adapters/ — provider-specific inbox and send adapters
  • src/lib/services/ — aggregation, send, reply, summary, risk, and event services
  • src/lib/gmail/ — Gmail OAuth, token, parsing, client, fetchers
  • src/lib/outlook/ — Outlook token retrieval through Auth0 Token Vault
  • src/lib/slack/ — Slack OAuth, token, client, fetchers
  • src/lib/style/ — style presets, extraction, storage
  • src/components/ — UI for dashboard, inbox, replies, settings, and shared primitives
  • src/app/api/ — route handlers for all product capabilities

Current Limitations

Pollux is functional, but it is still an early product prototype.

Current limitations include:

  • live deployment and demo credential setup may still require final packaging
  • attachment download is scaffolded but not fully implemented
  • inbox cursor pagination is not fully implemented yet
  • viewed/opened state is still localStorage-based rather than database-backed
  • risk classification is keyword-based rather than ML-based
  • Daily Brief caching is lightweight and in-memory
  • some local development flows still depend on careful OAuth configuration
  • Outlook currently supports inbox access only in the Token Vault path
  • Gmail and Slack remain existing direct integrations rather than Token Vault-based providers

These limits are real, but they are also clearly bounded and visible in the current architecture.


Future Work

  • richer action extraction and prioritization
  • audit-oriented action history views
  • stronger provider coverage beyond Gmail and Slack
  • deeper Outlook actions beyond inbox read
  • attachment download and handling
  • database-backed viewed state and user preferences
  • more advanced risk classification
  • more personalized communication modeling over time
  • broader multi-platform communication automation inside explicit approval boundaries

Why Pollux Is Different

Many AI messaging tools start from the model and add product later.

Pollux starts from the workflow:

  • who is signed in
  • what account is connected
  • what message is being acted on
  • what style the user wants
  • what the AI is allowed to help with
  • when the human must remain in control

That is the product idea at the center of Pollux.

The Outlook path extends that idea further by demonstrating how Pollux can use Auth0 Token Vault to access an external provider without app-managed Microsoft refresh-token handling.


License

MIT

About

No description, website, or topics provided.

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors

Languages