[ ] Host a bot building competition to drive adoption.
[ ] Maybe add video recording messages (audio + webcam + screensharing) such as Beseda does.
[ ] Fix the DB concurrency issues. For example, if a group chat has two admins, and they both leave at the same time, then the DB allows for it. This is because the DB constraints aren't enough, and therefore such logic exists in the application layer. However, since there are no locks, the first line of code which checks whether the admin can leave (i.e., whether there's more than one admin) succeeds, and then the second line of code which removes the admin gets run. Of course, this only happens if both the admins run at the exact same time but since we're running an asynchronous application with servers in different regions in parallel, such issues are bound to arise.
[ ] #48
[ ] #56
[ ] #66
[ ] #61
[ ] #67 (Implement once we're using a graph DB.)
[ ] Implement an operation which returns the cursor of the first unread message because the chat must start paginating from there upon opening on the client. Implement once we're using a graph DB.
[ ] Maybe implement mentions (e.g., @neelkamath Can you take a look at this?). This would be useful if users wanted to switch off notifications for public chat unless they were mentioned. Ant Design has a Mentions component. We could render the mention as the username but store the user ID under the hood since usernames are mutable. You'll need think how mentions of deleted accounts are handled.
[ ] Once Jackson supports Kotlin value classes, use them for GraphQL scalar models, and classes implementing ClientData in the broker.
[ ] Make a page comparing Omni Chat with every major competitor (e.g., Quill, Ruma, Keybase, Discord, WhatsApp).
[ ] Check out docker scan.
[ ] See if there's a way to use E2EE. Signal apparently allows multiple devices to use E2EE chats. Otherwise, you can have a separate encrypted chat type. I think Rocket.Chat also has E2EE.
[ ] Optimize the DB queries. There are currently way too many queries. Use SQL joins, indices, views, etc. Optimize the calling code as well.
[ ] Stored procedures such as readChatIdFromMessageId() can be cached using Redis since the data never changes. You could also store it in-memory. Look into using this technique for performance optimization.
[ ] Maybe implement Facebook chatheads for phones, and Google Hangouts desktop apps/browser extensions for use like you and Bilal liked.
[ ] Maybe invalidate codes such as password reset codes and group chat invite codes after a certain period of time for security reasons.
[ ] Maybe build a website for Omni Chat's docs. You could use GitHub Pages to generate it. Add the OpenAPI spec as a page.
[ ] Have a way for admins to reset users' email addresses. This is important because users can get locked out when either they update their account to use an invalid email address or they delete their existing email address.
[ ] Add load tests.
[ ] Consider using a different DB such as Neo4J, DynamoDB, or distributed DBs such as Orbit.
[ ] Once Docker App is stable, look into publishing one.
[ ] #60
[ ] Implement Query.searchBookmarks.
[ ] Use a combo of Cloud Deployments, Kubernetes, Terraform, and Serverless Framework.
[ ] Maybe rename the application to be a verb. This would be similar to how people say things like "WhatsApp me" or "Google it".
[ ] Look into using a webhook instead of a WebSocket to notify bots of triggered actions. See what other systems such as Slack do.
[ ] In the development build, the APP_NAME environment variable gets set to Gradle for an unknown reason.
[ ] Maybe have a feature like Discord's servers.
[ ] Maybe have a feature which allows the user to specify their three "types" of time. The types are when they are unavailable (e.g., sleeping), prefer not to be interrupted unless it's urgent (e.g., if they eat some time between 12:00 - 13:00, they'd be generally unavailable during that time), and free (e.g., evenings). Other users can see these times. Of course, users can message anyone at any time but they'll get to know when they're most likely to get a response, or have a realtime conversation.
[ ] Maybe allow the user to schedule which times of which days notifications get sent.
[ ] Maybe allow the user to temporarily switch off notifications (e.g., Google Hangouts can mute notifications for a few hours or days).
[ ] Maybe target this at businesses as a Slack competitor.
@neelkamath Can you take a look at this?). This would be useful if users wanted to switch off notifications for public chat unless they were mentioned. Ant Design has aMentionscomponent. We could render the mention as the username but store the user ID under the hood since usernames are mutable. You'll need think how mentions of deleted accounts are handled.ClientDatain the broker.docker scan.readChatIdFromMessageId()can be cached using Redis since the data never changes. You could also store it in-memory. Look into using this technique for performance optimization.Query.searchBookmarks.APP_NAMEenvironment variable gets set toGradlefor an unknown reason.