therelayproject/relay

AI Summary: This issue describes the implementation of a file service that enables users to attach files to messages. It leverages MinIO presigned URLs for direct client-to-MinIO uploads and downloads, bypassing application servers. The task involves creating a new API endpoint to generate these URLs, storing file metadata in a new `files` database table, and using the MinIO SDK to manage object storage.

AI Summary: This GitHub issue outlines the development of a Flutter message composer component. Key features include a multi-line text input that grows, a send button, an emoji picker integration, platform-specific keyboard shortcuts for sending/newlines, a character limit with a dynamic counter, and real-time draft persistence to a Drift database on every keystroke.

AI Summary: This GitHub issue outlines the implementation of a Flutter message list, a critical UI component designed for efficiency and real-time interaction. It will utilize virtual scrolling and cursor-based pagination to handle thousands of messages, loading older/newer pages on demand. Key features include real-time updates via WebSockets, optimistic UI updates for sent messages, a local Drift cache, and the ability to jump to specific messages via deep links.

AI Summary: This issue outlines the implementation of a real-time message search service using Meilisearch. It involves creating workspace-specific Meilisearch indexes on startup with defined settings, consuming NATS events for message creation, updates, and deletions to keep the indexes synchronized, and exposing a search API endpoint for querying messages.

AI Summary: This issue describes the implementation of a notification service to send push notifications to users when new messages are posted in channels. It involves subscribing to NATS message events, filtering eligible users based on their online status and notification preferences, and then dispatching notifications via FCM or APNS using device tokens stored in a new database table.

AI Summary: This GitHub issue outlines the implementation of real-time presence (online/away/offline) and typing indicators for a messaging service. It defines the WebSocket events for client-server interaction and details the backend logic using Redis for managing temporary states (like presence TTLs and typing indicators) and NATS for broadcasting presence updates.

AI Summary: This issue describes the implementation of the core message sending flow. A client sends a message via WebSocket, which the service validates, persists to PostgreSQL, publishes to NATS, and then fans out to all relevant WebSocket subscribers by querying a Redis connection registry. An internal REST endpoint will also be set up to proxy to this messaging service.

AI Summary: This GitHub issue outlines the implementation of a WebSocket connection handler for the Messaging service. It covers upgrading HTTP requests to WebSocket, authenticating users via a query parameter token, registering active connections in Redis, and managing the connection lifecycle using read/write goroutines, ping/pong liveness checks, and publishing presence updates to NATS upon disconnection.

AI Summary: This issue aims to add a basic integration test to the `sdk-go` package. The test will verify the `NewClient` constructor, ensuring it handles missing base URLs and correctly initializes sub-clients (Messages, Events) when provided with a valid URL. The task involves verifying the package's presence in `go.work`, adding `testify` as a dependency, and creating a new test file with the provided Go code.

AI Summary: This issue proposes enhancing the development workflow by adding a top-level `make run svc=<service-name>` target. This new target will enable running a specific Go service with live reload functionality using the `air` tool, automatically rebuilding and restarting the service upon file changes. It also includes creating a shared `air.toml` configuration and updating the `CONTRIBUTING.md` with `air` as a prerequisite.

AI Summary: This issue requires creating an initial OpenAPI 3.1.0 specification file (`docs/api/openapi.yaml`) to document the API. The file should include basic structural elements like title, version, server, and security schemes. Additionally, it needs to contain stub entries for all Phase 1 endpoints, using a placeholder for their respective schemas.

AI Summary: This GitHub issue describes the implementation of a Time-based One-Time Password (TOTP) Multi-Factor Authentication (MFA) screen in a Flutter application. After a user successfully enters their password and the API indicates MFA is required, the app needs to display a 6-digit input screen. Key features include auto-focus, auto-submission on the 6th digit, a backup code option, and visual error states with animations.

AI Summary: This GitHub issue outlines the initial Flutter app shell layout, which includes a responsive three-pane design for desktop/web featuring a workspace switcher, channel list, and content area. For mobile, it specifies a bottom navigation bar with Channels, DMs, and You tabs. The implementation requires using `LayoutBuilder` for responsiveness and a `WorkspaceShellNotifier` for managing active workspace state.

AI Summary: This issue outlines the implementation of a Dio interceptor in a Flutter application to automatically refresh JWT access tokens. Upon receiving a 401 Unauthorized response, the interceptor will call a refresh endpoint using a separate Dio instance, store the new tokens, and retry the original request. If the token refresh fails, the user's tokens will be cleared, and they will be redirected to the login screen.

AI Summary: This task involves creating Flutter login and registration screens, featuring email/password fields, client-side validation for registration, and placeholder OAuth buttons. It requires API integration for authentication, secure token storage using `flutter_secure_storage`, and robust state management with `AsyncNotifier` and `freezed` to manage authentication state, redirecting to the workspace upon successful login or registration.

AI Summary: This issue outlines the implementation of a shared cursor-based pagination system using Snowflake IDs for all API list endpoints. It defines the API contract, including request parameters like `before`, `after`, and `limit`, and a response envelope that provides `items` and cursor details such as `has_more_before` and `has_more_after`. The task involves creating a `cursor.go` helper with structs for `Cursor` and `Page`, a `ParseCursor` function, and specific SQL patterns for fetching data based on the cursor.

AI Summary: This GitHub issue proposes the creation of a `PermissionGuard` middleware for an API service. Its primary function is to resolve the caller's role within a given workspace and enforce a minimum required role for specific API handlers, thereby eliminating the need for repetitive role-checking logic in each handler. The middleware will integrate with existing authentication claims and a `WorkspaceMemberStore` to perform its authorization checks.

AI Summary: This GitHub issue defines the API service requirements for managing workspace members and their roles. It specifies endpoints for inviting, listing, changing roles, and removing members, alongside dedicated endpoints for granting and revoking guest access to channels. The issue details a comprehensive role-based access control (RBAC) system for owners, admins, members, and guests, outlining their respective permissions for managing other members, and includes implementation notes for handling user invitations and pending invite records.

AI Summary: This issue details the implementation of CRUD API endpoints for managing channels within a workspace. It specifies five endpoints for creating, listing, retrieving, updating, and archiving channels, which can be public, private, or announcement types. Key considerations include channel naming conventions, automatic creator membership, and soft-deletion via an `archived_at` timestamp.

AI Summary: This GitHub issue details the implementation of a set of API endpoints for managing user workspaces, which is part of Phase 1-B. It outlines the necessary CRUD operations (create, get, update, delete, list) for workspaces, including specific requirements for authentication, authorization (owner-only actions for update/delete), slug validation with uniqueness checks, and transactional creation of workspaces with their owners. All database interactions are to be handled in `internal/store/workspaces.go`, with response IDs formatted as strings.

AI Summary: This GitHub issue describes the creation of a new internal HTTP endpoint within the Auth service. This endpoint, `/internal/validate`, will allow other services to validate raw JWTs by sending them in an `X-Token` header. It will validate the token's signature, expiry, and check a Redis blocklist for revoked tokens, returning user claims for valid tokens (200) or a 401 for invalid ones.

AI Summary: This issue outlines the implementation of Time-based One-Time Password (TOTP) Multi-Factor Authentication (MFA) for the authentication service. It involves creating three new API endpoints for user enrollment, verification, and challenge, as well as modifying the existing login flow to enforce MFA. Key requirements include storing encrypted TOTP secrets and hashed backup codes in the database, using a specified TOTP library, and implementing AES-GCM encryption for sensitive data.

AI Summary: This GitHub issue outlines the implementation of an authentication service's login endpoint, focusing on a JWT-based system with refresh token functionality. It details three endpoints: `/login` for initial authentication, `/refresh` for token renewal with rotation, and `/logout` for session termination. Key implementation notes include using Argon2 for password verification, JWT (HS256) for access tokens, and Redis for managing refresh tokens (with rotation) and a JWT blocklist.

AI Summary: This issue describes the creation of a new user registration endpoint (`POST /api/v1/auth/register`) for the authentication service. It requires validating user input, hashing passwords using Argon2id, storing user data in the `users` table, and handling duplicate email/username conflicts by returning a `409 Conflict` status.

AI Summary: This GitHub issue outlines the task of integrating `pgx/v5` and `pgxpool` into the API service to establish a database connection pool. It involves adding the necessary dependency, creating a `NewPool` function to initialize and ping the database, and then integrating this pool into the `main.go` for dependency injection and proper shutdown. The goal is to prepare the API service for database interactions in subsequent development phases.

AI Summary: This issue requests the addition of unit tests for the `/health` endpoint across all nine services. The goal is to verify the response shape and status code, and to provide a clear example of how to test HTTP handlers. A specific Go test code snippet is provided, requiring minor adjustments for each service's name and a potential slight refactor of the existing `health.go` file to make the handler testable.

AI Summary: This issue involves refactoring 9 services to centralize 'magic numbers' like timeouts and ports. For each service, a `constants.go` file will be created in `internal/config`, and the `cmd/main.go` file will be updated to use the new `ShutdownTimeout` constant instead of hardcoded durations.

AI Summary: This issue aims to standardize HTTP response handling across nine microservices by adding `writeJSON` and `writeError` helper functions to a new `internal/handler/response.go` file in each service. The task involves copying the provided Go code into each service's directory and updating existing handlers (primarily health checks) to utilize these new helpers for consistent JSON and error responses.

AI Summary: The current README's ASCII architecture diagram is sparse and needs updating for clarity. The task is to create a more detailed diagram, using either ASCII or Mermaid, that illustrates the Flutter client, API entry point, all nine services with their roles, their infrastructure dependencies (e.g., PostgreSQL, Redis), and the central NATS event bus. This aims to provide a clearer visual for new contributors and potential users.