mikhael28 / paretOS

A high-level operating system to maximize human potential. Live at https://paret0.com
https://paret0.com
GNU General Public License v2.0
35 stars 45 forks source link

Improved/Production Messaging Platform #74

Open mikhael28 opened 3 years ago

mikhael28 commented 3 years ago

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.

Leoactionz commented 2 years ago

Hi @mikhael28, is there a similar platform we could check out to see how this works?

mikhael28 commented 2 years ago

@LeoUCon this is what I meant by AIM: https://en.wikipedia.org/wiki/AIM_(software)

Think like a simple IRC client as well.

mikhael28 commented 2 years ago

I've gone ahead and removed the previous implementation from the codebase entirely, as the v3 aws-amplify/api library it was integrated with was deprecated, and was causing breaking issues when upgrading npm packages. So, I've gone ahead and simply removed it. Now the search for a better solution can begin in earnest.