Thank you! It's all because of Mojolicious real time web framework. The fun of using the well designed components, and not to mention the ease of writing tests makes it a no-brainer to me :)
It's fun running cloc from time to time: Very evenly between Perl, JavaScript, CSS and template files: https://convos.by/doc/#statistics
CTCP messages are widely implemented, and there are no standardised or restrictions to how to format them. Since there are no good way to pass WebRTC signalling through IRC, I made up my own protocol. If a more standard way is available in the future, then Convos will for sure adopt it.
The server part of Convos is like an IRC bouncer, but instead of supporting the IRC protocol from the client side, it has a HTTP/WebSocket interface that talks to the Convos frontend.
So Convos keeps your connection, so even if you close the web browser, you will still receive messages and you can see the history once you open your browser again.
If you stop the Convos server, then you will also be disconnected from the IRC server.
I am not suggesting that Convos should support chatting without JavaScript and CSS enabled. I am suggesting that users who wish to use IRC should be allowed to do so, and if given the link to the web page, should be able to read it to determine what IRC server to use, regardless of whether or not JavaScript and/or CSS and/or images are enabled.
Too many web pages say IRC, and then if you select it just says "You must activate JavaScript to use IRC", without telling you what IRC server and channel to use, and that is no good.
Wouldn't you be the one choosing the IRC server? I thought the point of this was if you wanted to run your own IRC bouncer with a web client, similar to a self hosted IRCCloud.
I suppose so, yes, but it says "multiuser chat application". However, it also seems that you are correct about you would run your own and just use it by yourself; this is a bit confusing perhaps.
However, I looked again and it also mentions an archive, which can be useful (for public channels) even if you are not using the web interface to connect to IRC. The archives should probably be available (perhaps configurable, in case you are using it privately and do not want public archives) even to those not using the web client.
The documentation mentions invite links and new user registration, so it does seem like it can be used for multiple users. Still, some users will want to use IRC directly (or might want to use IRC for communication but use the archives). Therefore, please fix it so that the IRC server to use (the value of window.__convos.default_connection, as far as the JavaScript code is concerned) is visible regardless of JavaScript/CSS enabled/disabled.
For archiving, I recommend supporting the "esologs" raw format, which works as follows: Each line begins with < or > indicating the direction of the message (where < means server to client and > means client to server), followed by a space, UNIX timestamp, space, microseconds, space, and then the full contents of the IRC command, uninterpreted. File names are like "YYYY-MM-DD-raw.txt" where "YYYY-MM-DD" is replaced by the date. For logs of an entire month, the format is "YYYY-MM-raw.txt". Replace "-raw.txt" with ".html" for formatted logs. (The esoteric programming IRC uses this format.)
Very cool. I'm working on a service that add apps to my email inbox. Is there a way you think we could self host this and create accounts / link accounts automatically for our users? I'd love to have an irc client that can run in an iframe and I'd access it by clicking a tab.
I would very much like this as well, but "kiosk" mode is currently not planned. Might start consider it again after https://github.com/Nordaaker/convos/issues/414 is closed... Please do open an issue where you describe what you think is required for Convos to work from within your email inbox, or join #convos on freenode and have a chat with us.
Perfect! I just replied to the issue too. We don't even need email auth. As long as there's a way to login / create a user in the back, we can handle auth.
