I don't, and I consider it a wasted effort. There are existing apps for messaging.
Unless your app is a social app, and even then I'd integrate messaging only if it's a core ability.
At work, the team that was responsible for the app before I came along, 12 years ago, wanted to integrate a messaging ability into our internal company app.
I was literally shocked when they told me that, since that it reflected such a disconnect from reality, reality being the app was extremely crashy, not documented, and filled with bugs, and a disconnect from what users really wanted (I'm a former user turned core dev) that I couldn't even believe these people were for real.
I’ve started using email all over for “internal app messaging” because it’s pretty great. mailto: hyperlinks are actually quite capable if you read the docs. I made a gem for my Rails apps at https://github.com/rocketshipio/mailto that makes it super easy to pretty much compose messages for people who want to send you a support or sales request via Erb templates.
For outbound messaging, emails are sent from the sever.
It would be awesome if other applications, like Teams, Slack, and Discord had a mailto:-like integration, but they don’t.
I like your perspective. It reinforces and states more bluntly what were my thoughts on this topic.
But the app is partly a social commenting app, with reddit style comments.
And for some other features, there are some one-on-one communications that need to happen. For now, those conversations happen out of band ( discord, ... ).
Users that are out of the loop just miss out and even users that are in the discord room keep asking for in-app messages regularly.
That's why now, it's on the todo list.
The company I work for has had (for many years) an internal feed mechanism, where you can create groups and posts, like and reply, etc.
Post COVID, 99.99% of the company is using Teams for quick sync chats, WhatsApp for company broadcasts, and email for longer term async chats. We're probably going to deprecate the feed mechanism.
My takeaway is unless your solution is so compelling that it will draw people away from these existing platforms and the network effect that draws them into them, its not worth the effort.
A very simple way is by having the app listen to a Firebase JSON object via a websocket. Whenever the contents (of the "chatroom") change, the new text is pushed down to all users in the room.
In fact, this was the original use case for Firebase, which was first released as a tool for building in-app chats.
The room is just a JSON object, too (or a "path" down inside one), so anyone you want can be in the room. If only two people are listening to that object, it would look like private messaging. If everyone were listening to a room, it would appear "public."
The disadvantage is that you have to build it. It's easy, so I'd say that's really an advantage because you will deeply understand it. NoSQL data and websockets are really important technologies and Firebase is free, including hosting, until you hit some pretty high usage limits.
What I normally do is restrict communication to sole A-Z, a-z and 0-9. And store everything locally on each persons computer with a really simple encryption method so you don't actually see the chat. This protects you from liability as well as any exploits due to not sanitizing the data.
Literally just a "GET getChatMessage(AUTH, USER)" and a "POST sendChatMessage(AUTH, USER)". And inside getChatMessage, delete all messages that are sent.
I am not sure we will go down tha t path, but I am really glad you provided that comment. It expanded my view of what is possible. I guess the experience your users expect allow you to use that method ? If you have more interesting details on how it works, I would love to hear them !
IMO the easiest path is to use a ready-made chat SDK and a hosted service.
But it only make sense if their pricing fit your business model.
Usually such services are priced by number of users and/or concurrent connections. So they only make sense when you're small and very fast can become prohibitively expensive. Then it's a time to implement your own messaging functionality.
Hi, I'm one of the founders of https://talkjs.com, a chat SDK with a pre-built UI. Obviously my position is biased.
Users have come to expect a chat experience that Just Works, and has all the basics covered. Those basics, however, go a lot longer than just the websocket/firebase "hello world" chat app and it's a lot of work to cover them sufficiently well. Typing indicators, online status, sharing photos and files and locations, reliable delivery on shitty networks, notifications through other channels (eg push, email, etc) when not logged into your site/app, URL previews, read receipts, replies, edit/delete, emoji rendering, emoji reactions, and on and on and on. And with good design and UX for all of them.
Must you have all of these? Definitely not. But if a user feels they need some of them to have a comfortable/effective chat, they'll go to great lengths to move the conversation away from your app to some other channel (eg Telegram or WhatsApp). We have quite some customers who replaced a handrolled chat by TalkJS, citing users actively trying to circumvent their own messaging functionality as a primary reason.
Meta level note: Most users, especially the not-very-techy ones (ie the vast majority) really do appreciate having good communication tools right at their fingertips, directly in the application they're currently using. Nevertheless I agree with the current top comment in that if you business does not suffer from leaking users to other services and your users are relatively tech savvy, you probably get the happiest users fastest by just letting people share Telegram/Whatsapp/Matrix/Discord contact info and calling it a day. But otherwise, build a good chat feature. We're just one of the options, it's worth it and it's very little work.
Do reach out if you think we may be of service! Our chat support is manned by programmers so ask away :-) (or hit me an email, contact info in my hn profile)
Messaging is a hugely complex with the amount of features users expect nowadays. Best to integrate an existing FOSS solution and customise it to your particular needs e.g. Matrix, XMPP, Mattermost, Rocket Chat, etc.
Thanks. What would be the best choice, in your opinion, between those FOSS solutions if the goal is to integrate them into an already existing app ? ( Pros / Cons ?)
Unless your app is a social app, and even then I'd integrate messaging only if it's a core ability.
At work, the team that was responsible for the app before I came along, 12 years ago, wanted to integrate a messaging ability into our internal company app.
I was literally shocked when they told me that, since that it reflected such a disconnect from reality, reality being the app was extremely crashy, not documented, and filled with bugs, and a disconnect from what users really wanted (I'm a former user turned core dev) that I couldn't even believe these people were for real.