• Project directory structure has been created.
• Basic documentation (README, etc.) has been initiated.

• Implement video upload and storage.
• Enable video previews and playback within the chat interface.
• Add a new message type for video messages in the chat domain.

removing mongo and using SQLite

https://github.com/vlcn-io/cr-sqlite

Will allow offline and sync

the server and client both use the same db

Fly.io is using it for distributed shakeout of the servers but it can just as well be used for the clients.

Discussed in #23

(jose jwt package)[https://github.com/square/go-jose] has been archived and we need to change it to a proper and active library to be able to handle the JWT signing operations.

Easy to update parts of any html / go template based gui

and also easy to extend in a decoupled way with plugins for other gui elements etc .

I have been using htmx for gui where you want to update parts in real time . Htmx can use WS or SSE to update the gui html is response to bsckend events

The goal of this issue is to build a service-agnostic context for the Notification Service from scratch. By employing a factory pattern, we aim to provide the Notification Service the flexibility to adapt different notification service providers (like Firebase, OneSignal, etc.) without impacting the internal workings of the system.

Tasks:

• Define an interface that outlines the essential methods for notification operations such as Send, Receive, Delete, UpdateStatus, etc.
• Implement a factory pattern to instantiate the appropriate notification service provider based on configuration or runtime requirements.
• Develop an initial implementation using a placeholder or dummy notification service that adheres to the defined interface.
• Integrate this factory and interface into the existing Notification Service codebase.
• Write unit tests to confirm that the Notification Service works as expected with the dummy implementation.

Acceptance Criteria:

• Notification Service should be able to operate with different notification service providers without changes to the internal services.
• Unit tests confirm that the new implementation meets the expected behavior.

• Integrated Fiber for fast HTTP requests.
• Created essential middleware.

Implement a real-time system to indicate the online/offline status of users in a chat room. The feature will involve both server-side logic and WebSocket notifications to inform room participants of any status changes.

Requirements:

• API Endpoint: Extend existing APIs to handle the online/offline presence of users. Add presence information to relevant data models. Consider a status field with values like online, offline, away, etc.
• Event Types: Define event types to communicate user presence status.

EventTypeUserOnline: User has come online.
EventTypeUserOffline: User has gone offline.
EventTypeUserAway: User is temporarily away.

• WebSocket Notification: Notify room participants of any changes in user presence via WebSockets.
• Persistence: Store the latest presence information in the database, so new room participants can get up-to-date info.

Success Criteria:

• Users in a chat room should see accurate, real-time updates on the online/offline status of room participants.
• User presence information should be persistent and retrievable for future reference.

• Add functionality for audio message recording and upload.
• Implement audio playback within the chat.
• Create a dedicated message type for audio messages.

As the title says, the discord invite link in the README is expired.

I really like what you are doing here as it is pretty hard to find good information on how to do DDD/Clean Architecture well in go and I wanted to come on to ask a few questions.

Setup NATS for message queuing and event-driven architecture.

Setup basic user authentication and JWT.

Discussed in #23

Implement a real-time update system to notify all users in a chat room when someone starts or stops typing. The feature will be implemented using a POST API endpoint and WebSocket notifications.

Requirements:

• API Endpoint: Create a new POST API endpoint /room/:roomID/event for the typing event. This endpoint will accept an eventType to indicate whether typing has started or stopped.

Sample API Contract:

POST /room/:roomID/event { "eventType": "typing.started" }

• Event Types: Two event types should be supported:

EventTypeTypingStart ("typing.started"): User has started typing.
EventTypeTypingStop ("typing.stopped"): User has stopped typing.

• WebSocket Notification: Once the server receives the API request, it should broadcast this event to all users in the room using WebSockets.
• Rate Limiting: Implement rate limiting for this feature to avoid unnecessary network calls. For example, limit the number of "typing started" and "typing stopped" events per user per second.

Success Criteria:

• Users in the same room should see real-time updates when someone starts or stops typing.
• The feature should be resilient and optimized, adhering to best practices.

To be able to showcase the system, we need to create an example client

• Set up a new Vue.js(might change) project as an example client to connect with the NatterNet backend.
• Implement basic chat functionality, allowing users to join rooms, send messages, and receive notifications.
• Make sure the client is compatible with the current WebSocket implementation in the NatterNet backend.
• Provide comprehensive documentation to guide users on how to set up and use the example client.

• Designed the database schema for chat rooms and messages.
• Integrated MongoDB for data storage.

Integrated logging mechanisms.

• Add support for image uploads to the server.
• Implement a feature to preview image messages in chat.
• Create a new message type in the chat domain to handle images.

The goal of this issue is to refactor our MongoDB context into a factory pattern. This will enable us to easily switch between different database adapters without affecting the internal packages or application logic. The internal packages should be unaware of the database structure, and this refactor will help us achieve that level of abstraction.

Tasks:

• Create an interface that defines all the methods required for data manipulation (e.g., Insert, Update, Delete, Find, etc.)
• Implement the factory pattern to produce instances of different database adapters.
• Refactor the existing MongoDB context to conform to the new interface.
• Update the application logic to use the new factory and interface, replacing any direct MongoDB calls.
• Test to ensure that the existing functionality remains intact after the refactor.

Acceptance Criteria:

• All internal packages should be able to perform CRUD operations without being aware of the underlying database structure.
• It should be easy to plug in a new database adapter (like MySQL, PostgreSQL, etc.) without modifying the internal packages.
• The existing test suite should pass without any failures.

• Basic API endpoints for chat functionalities designed.
• Swagger documentation initiated.

Implement functionality that allows users to edit or delete their messages in chat rooms. This will enhance user experience by allowing corrections and removals.

Requirements:
API Endpoints: Extend existing APIs to handle the editing and deleting of messages. The operations should be restricted to the original message author.

Sample API Extensions:

PUT /message/:messageID/edit
DELETE /message/:messageID/delete

• Event Types: Define event types to communicate message edit and delete actions.

EventTypeMessageEdited: Message has been edited.
EventTypeMessageDeleted: Message has been deleted.
WebSocket Notification: Notify room participants of any message edits or deletes via WebSockets.

• Database Changes: Ensure the edited message is updated in the database, and deleted messages are either removed or flagged as deleted, depending on your data retention policy.
• Client-Side Behavior: Update the frontend to reflect these changes in real-time without requiring a page reload. (Note: While this task focuses on the backend, the frontend will also need adjustments.)
• Testing: Include unit and integration tests to confirm that the feature functions as expected.

Success Criteria:

• Users should be able to edit their own messages.
• Users should be able to delete their own messages.
• All participants in the room should be notified of these actions in real-time.

Added request validation and robust error handling.

The objective of this task is to design and implement a service-agnostic context for the storage system. Utilizing a factory pattern, the goal is to create a system flexible enough to adapt to various storage solutions (such as AWS S3, Google Cloud Storage, local filesystem, etc.) without affecting the existing application layers.

Tasks:

• Define a Storage interface that includes essential methods for storage operations like Upload, Download, Delete, List, etc.
• Implement a factory pattern to generate instances of the appropriate storage service provider, based on configuration or runtime requirements.
• Create a basic initial implementation using a placeholder or dummy storage service that complies with the defined interface.
• Integrate this factory and interface into the existing storage service codebase.
• Write unit tests to verify the correct behavior of the service-agnostic storage context.

Acceptance Criteria:

• The storage service must be capable of interacting with multiple storage service providers without requiring modifications to the internal application layers.
• Unit tests should validate that the new implementation works as expected, adhering to the defined interface.

• Integrate with geolocation APIs to obtain user location.
• Enable sharing of location within chats.
• Add a new message type specifically for location sharing.