therelayproject/relay

AI Summary: This issue describes the implementation of a file upload and download service using MinIO presigned URLs. The flow involves the client requesting an upload URL, uploading directly to MinIO, and then associating the file with a message. Metadata will be stored in a new database table, and workspace quotas will be enforced.

AI Summary: This issue requires the implementation of a multi-line message composer in Flutter. Key features include a growing text field, a send button, an emoji picker, platform-specific keyboard shortcuts, a character limit with a counter, and draft persistence. The implementation will involve a `ComposerNotifier` and platform detection.

AI Summary: This issue focuses on implementing a highly efficient message list in Flutter. It requires virtual scrolling to handle thousands of messages and cursor-based pagination to load older and newer messages on demand. The implementation involves managing state with `AsyncNotifier`, using `ScrollablePositionedList` for rendering, and integrating with a Drift cache for persistence. Key features include optimistic message insertion, handling new messages via WebSocket, and deep linking for specific messages.

AI Summary: This issue involves setting up Meilisearch for message indexing within workspaces. It requires creating Meilisearch indexes on startup, consuming NATS events for message creation, updates, and deletions, and exposing a search endpoint. The goal is to enable users to search their workspace history with specific search and filter attributes.

AI Summary: This issue involves implementing a push notification service that dispatches messages to offline users via FCM or APNS. It requires subscribing to NATS events, filtering users based on online status and notification preferences, and storing/retrieving device tokens from a new database table.

AI Summary: This issue proposes implementing real-time presence (online/away/offline) and typing indicators for a messaging service using WebSockets. It outlines the necessary WebSocket events, server-side implementation details involving Redis and NATS, and acceptance criteria for presence updates and typing notifications.

AI Summary: This issue describes the core message sending flow for a messaging service. It involves receiving a message via WebSocket, persisting it to PostgreSQL, and then publishing it to NATS for fan-out to all connected channel members. The implementation requires integrating with NATS and handling multiple connections per user.

AI Summary: This issue focuses on implementing the WebSocket connection handler for the real-time messaging service. It involves handling the WebSocket upgrade, authenticating users via a token, registering active connections in Redis, and managing bidirectional communication through goroutines. The implementation also includes keepalive pings, graceful shutdown, and publishing presence updates.

AI Summary: This issue aims to add basic integration tests for the `sdk-go` package. It involves ensuring the SDK is included in the `go.work` file, adding the `testify` dependency, and writing several test cases to verify the `NewClient` constructor and its options. The goal is to ensure the SDK can connect to a running server and that the tests pass.

AI Summary: This issue proposes adding a new Makefile target to streamline the development workflow. The `make run svc=<service-name>` command will allow developers to easily start individual services with live reloading enabled using the `air` tool, improving the development feedback loop. The task involves modifying the Makefile, creating a shared `air.toml` configuration, and updating documentation.

AI Summary: This issue requires the creation of a skeleton OpenAPI 3.1.0 specification file (`docs/api/openapi.yaml`). The file should include basic API information, server details, security schemes, and stubbed paths for all defined Phase 1 endpoints. The primary goal is to establish a foundational structure for API documentation that can be expanded upon in future development.

AI Summary: This issue describes the implementation of a Time-based One-Time Password (TOTP) Multi-Factor Authentication (MFA) screen within a Flutter application. The screen will handle the entry of a 6-digit TOTP code, including auto-submission, a backup code option, and error handling, following a specific API flow. This feature is a dependency for further authentication stages.

AI Summary: This issue describes the implementation of a 3-pane layout for a Flutter application, featuring a workspace switcher, a channel list sidebar, and a content area. The layout needs to be responsive, adapting to desktop/web and mobile screen sizes. Key implementation details include using `LayoutBuilder` for responsiveness, creating a `WorkspaceShellNotifier`, handling deep links with `go_router`, and using mock data if necessary.

AI Summary: This issue requires implementing a Dio interceptor in Flutter to handle JWT token refreshing. The interceptor should automatically attach the access token to requests, and upon receiving a 401 Unauthorized response, it should attempt to refresh the token using a refresh token. If the refresh is successful, the original request should be retried with the new access token; otherwise, the user should be logged out. A mutex should be used to prevent race conditions during concurrent token refreshes.

AI Summary: This issue requires the implementation of two core Flutter screens: a login screen and a registration screen. The login screen will handle email/password authentication and include placeholders for OAuth, while the registration screen will manage user account creation with client-side validation. Both screens need to integrate with a backend API, securely store authentication tokens, and manage the application's authentication state using `AsyncNotifier` and `freezed`.

AI Summary: This issue requires implementing cursor-based pagination for API list endpoints using Snowflake IDs. It defines a contract for the API request and response, including `before` and `after` cursors and a `limit` parameter. The implementation involves creating a `Cursor` struct and a `ParseCursor` helper function in Go, along with SQL patterns for fetching data before or after a given ID. The goal is to enable infinite scrolling for clients like Flutter.

AI Summary: This issue proposes the creation of a reusable middleware called `PermissionGuard` for the API service. This middleware will resolve the caller's role within a workspace and enforce a minimum required role for accessing specific API endpoints, preventing repetitive role-checking logic in individual handlers. It defines an interface for its usage and outlines the implementation details, including error handling and role hierarchy.

AI Summary: This issue involves implementing API endpoints for managing workspace members and their roles. It includes inviting users, listing members with pagination, changing roles, and removing members. Specific attention is given to role hierarchies, guest access to channels, and preventing the removal of the last owner.

AI Summary: This issue involves implementing CRUD (Create, Read, Update, Delete) operations for channels within a workspace's API. It defines endpoints for creating, listing, retrieving, updating, and archiving channels, with specific rules for channel types, naming, and visibility for private channels. The implementation also needs to handle archiving by setting a timestamp rather than hard deletion and ensure name uniqueness.

AI Summary: This issue outlines the implementation of CRUD (Create, Read, Update, Delete) endpoints for managing workspaces within an API. It details specific endpoints, required authentication, data validation for slugs, authorization checks for updates and deletions, and database interaction details. The goal is to enable users to create and manage their workspaces, with specific roles for ownership and modification.

AI Summary: This issue proposes the creation of an internal HTTP endpoint for the auth service to validate raw JWTs. This endpoint will be used by other services, like the messaging service, to verify token validity without importing auth business logic. It needs to check token signature, expiry, and a Redis blocklist for revoked tokens.

AI Summary: This issue requires implementing Time-based One-Time Password (TOTP) Multi-Factor Authentication (MFA) for the auth service. It involves endpoints for enrolling users in TOTP, verifying their enrollment, and challenging them during login with a TOTP code. The implementation will use a specific Go library, encrypt TOTP secrets, and handle backup codes.

AI Summary: This issue describes the implementation of an authentication service with login, refresh, and logout endpoints. It involves generating JWT access tokens and opaque refresh tokens, securely storing them, and implementing token rotation and blocklisting for security. The goal is to allow users to log in and maintain authenticated sessions with short-lived access and long-lived refresh tokens.

AI Summary: This issue describes the implementation of a user registration endpoint for an authentication service. It requires creating a POST request handler that accepts user credentials, hashes the password using Argon2id, stores the user in the database, and returns appropriate responses for success, conflicts, and validation errors. It also includes specific requirements for validation, password hashing, and unit testing.

AI Summary: This issue involves integrating the pgx/v5 database connection pool into the API service. It requires adding the pgx library, creating a new database pool function that reads the connection URL from an environment variable, and initializing/closing this pool during service startup and shutdown. The goal is to prepare the API service for database interactions.

AI Summary: This issue requires writing unit tests for the `/health` endpoint in all 9 services. The tests should verify the response shape and status code, and serve as examples for testing HTTP handlers. This involves creating a `health_test.go` file for each service and potentially refactoring the `health.go` handler to accept the service name as a parameter.

AI Summary: This issue proposes to centralize hardcoded 'magic numbers' like port numbers and timeouts into a dedicated constants file within each service. The goal is to improve maintainability and readability by eliminating scattered literal values and replacing them with named constants.

AI Summary: This issue proposes adding standardized `writeJSON` and `writeError` helper functions to the `internal/handler` package of all nine services. This will ensure consistent HTTP response formatting across the codebase, preventing variations in error handling and improving maintainability. The task involves creating a new `response.go` file in each service and updating existing handlers to utilize these new helpers.

AI Summary: This issue requests an update to the project's README file to include a more comprehensive architecture diagram. The current ASCII diagram is too basic, and the goal is to visually represent the relationships between the Flutter client, API service, nine other services, and their various infrastructure dependencies like PostgreSQL, Redis, NATS, MinIO, Meilisearch, and Livekit. The diagram should be in ASCII art or Mermaid format for native GitHub rendering.