Repository metrics
- Stars
- (35 stars)
- PR merge metrics
- (PR metrics pending)
Description
One of the pieces of software that adds tremendous value is simple messaging. Going back to the days of AIM/MSN/IRC, simple chat clients provided tremendous value and captivated people. We would like to see a simple chat experience that allows members to communicate across channels. Those channels can be platform-wide (#main) or personal messaging threads. Let's keep things simple at first, and enable text, attachment sending and pictures.
Our users should be able to create new messaging threads. They should be able to reply to a thread. There should be optional notifications per thread, but it should not use the Notification API since not all browsers support it. Instead, we can store a running thread of notifications locally (but let's avoid persistent online notifications, such as email or SMS for now. I would like people to be able to shut off the OS, and not have it hound them across multiple access points. Just like with AIM, when you log-in - you can see the messages that you hadn't yet read, but there were no notifications sent to your email - the messages THEMSELVES were the notifications. Similar to Hey's policy for email.
Right now, the messaging system is built off an auto-generated GraphQL API using AWS-Amplify CLI, that stores messages in DynamoDB and has support for multiple channels out of the box. I would like to build off this system, unless it proves prohibitive in cost. Right now the Dynamo auto-scaling is turned off, so there is no chance for outrageous costs.
The most immediate item - we need to migrate the Messaging subscription operations out of Messaging.js and move it into App.js, so that way we can access/save the messages and not have to reload all the latest messages in Messaging.js every time we load. It's also necessary, so that we can listen for the subscriptions outside the Messaging container, and relay notifications system wide.
To add the right amount of polish and features for this item, qualifies it as an ownership ticket, which means you are qualified to become a maintainer of the repository upon completion of the Issue and desire to be a maintainer. You don't have to become a maintainer, but it's an option.