-
I want a lightweight text chat client that I can self-host for simple chatting with friends and family. Like, AOL chat room level simple. (did you see there's a project that reverse engineered AOL 3.0 and have a FOSS server for it? )
At first blush, Synapse seems like it would be a good option because I could just direct them to download simple clients, have them register an account and get moving... but going from "hmm, I need a simple chat client for friends and family" to an actual working solution with synapse was like following a treasure map (oh, I just have to enable registration here... wait why won't my terminal reconnect? The logs say what? Well I found the requisite setting in some source file... oh I have to generate tokens manually? Damnit. How do I submit post data with curl again?). Their API is documented but the path from blank slate to working solution is pretty much undocumented. As soon as I thought "I guess I could make a clone of matrix-register in PHP and put it in a LAMP container" I looked at the overall end-user experience it would yield, slapped myself for even considering it (face still hurts), and hit uninstall on the like 3 app's I'd already had to install to try and get it working smoothly. I have no interest in a tinkering project that requires regular multi-step CLI intervention with user interaction— at least not if I can't do it easily from an iPhone web browser or native iOS app.
The administration experiences in Mattermost and Rocketchat are fantastic, but the complete collaboration suite solution feature set is not only more than I need, it would confuse some of my most important users. Some older family members are the sort of people whose Facebook profile picture is them confusedly looking at their phone screen and at least 20% of their posts are misplaced google search terms. It's easy to laugh at, but they want interaction with their great nieces and nephews enough to go WAY outside of their comfort zone— not only do I think that's pretty admirable, but I think it's worth offering a "jitterbug phone" version of online interaction to ease their burden.
I've written VERY simple centralized chat client/server applications before... I know there are probably a million edge cases that make it way more irritating than it seems at the outset, but should I just write it? Am I really looking for some modern version of ejabberd or something like that? Does this seem super niche or would anybody else be interested? Reinventing the wheel is stupid and I'd much rather use an existing solution, but lacking that, I'd much rather spend my time creating a unique tool useful for people to self-deploy than porting a clunky bolt-on bandaid for synapse's missing internal functionality. I noticed there are a lot of German users in here— any tips/libraries/etc. for making internationalization easier at the beginning of a project?
If something does exist but isn't available on Cloudron, I imagine y'all would be open to my at least getting a jump on making a containerized version of it for you?
-
No idea how AOL 3.0 worked. Was never my provider
The third result of a quick search for "php chat" -> https://justblab.com/blabax-php-ajax-website-chat-software
Put an htpasswd in front of it and you have your local chat in a browser. -
IRC?
The Konversation app included with Kubuntu / KDE- Neon might be the kind of thing that you're thinking of?
-
Or something like this perhaps? https://apps.apple.com/ai/app/wirc/id1182382960
-
@marcusquinn IRC is certainly a lightweight lift for the tech but I don't think the end-user experience is quite simple enough. Konversation is a great client but there's no way I'm walking Nana or whoever through figuring out how to build it on whatever computer she's using.
-
-
@marcusquinn Additionally, there's also no existing IRC server in Cloudron AFAIK and maintaining two separate containers for this plus supporting nontechnical users getting set up with clients is more than I'm interested in doing for ongoing administration.
I'm kind of surprised there's no FOSS "I just want to have dead simple, low-touch chat functionality" web app out there.
-
@marcusquinn I mean, I worked in support for 5 years before I worked in IT for about 7 years before I worked as a web developer for 11 years, and am now transitioning into interface design. I've got a pretty good idea of where the friction will end up being with this user set, and the cost/benefit ratio that will make this too annoying for me to bother with for regular ongoing maintenance. I'd rather put double the effort into maintaining a simple purpose-built tool that might solve this problem for other people than making sure two half-solutions consistently work together well enough for the intended audience.
-
If Cloudron have XMPP then you could use something like https://conversejs.org/
Snikket looks great imho and there are decent clients for mobiles too.
-
@jdaviescoates Yeah if I was going to do one myself I'd probably use an XMPP back end. Cloudron doesn't have an existing XMPP server AFAIK but maybe a container with ejabberd and a really simple front end or something like that.
-
-
@drew said in *Really* lightweight, simple (use and administration) real time chat? Does it even exist today?:
Cloudron doesn't have an existing XMPP server AFAIK
It doesn't, but it ought to!
-
Signal.org provides a nice mix as an example app.
Today one should consider the UX needs by not focusing only on chat. For example for your "jitterbug" clients who would benefit from less chat and more video call type interaction. Once you open this path, it suggests that their preferred method of messaging might be short audio or video messages which techies avoid with text chat based options.
Many of the collaboration tools have chat built in, like NodeBB with it's web based in-page chat.
Another is EtherPad with the sidebar chat while you edit a text document which can also be a live chat that is a document record after you're done. It also has a p2p video plugin that works well while you do all this.
Then there's Jitsi which is focused on p2p audio/video but also has a chat option + screen sharing.
All this to say, re-consider for your specific use case and group what comes first as a primary feature (ex async or live), then secondary (a/v/text), which will help narrow down what you actually need and what the group will respond to with delight.
-
@robi I've done some product design and UX work and agree that actual research would likely reveal audio/video being the ideal path— older folks make up one of TikTok's largest demographics. Unfortunately, the point is moot because creating a system like that would be a vastly heavier lift in every conceivable way. Really a job for a team with a resource budget, not a person with a broad skillset. Beyond that, I wouldn't have the bandwidth to host it and lots of older folks wouldn't have the data plans or devices to easily use it. In terms of the cost/benefit ratio, the potential benefits are significant, but the costs drown them out.
The alternate chat solutions all suffer from one problem I'm trying to avoid— lack of interface focus on my core requirement. Folks who aren't used to navigating complex software environments shouldn't have to cut through a bunch of other functionality to accomplish their goals. And there's a good reason many that the alternate solutions you mentioned all have tiny centralized built-in chat functionality bolted on— because it's easy as hell to make. A small centralized chat app is often a tutorial project for various frameworks. If you're clamping down scope creep to the barest functionality for an MVP and using a modern framework that deals with lots of the security, storage, etc. it's a pretty light lift.
And considering these folks do use text-based synchronous (but state persistent) methods to communicate, the cost benefit ratio for a single creator looks immeasurably better. The real trick would be making that experience good enough to get the other people on board with it.