story
So I had an android IRC app for a bit, some top paid one, and get booted from a bunch of my favorite channels because apparently it was just sat in my pocket cycling my connection and flooding the channel with join/unjoins.
That, plus the weird way to authenticate doing /msg Nickserv identify. That might be just how the server I was connecting to was implemented, but it felt fucky.
IRC was designed, mostly, for two types of users: A) Large institution users who had a fixed link to the internet and ran in their shell on a mainframe. B) Dial-in users, who's devices mostly stayed connected, and when they disconnected, usually required manual intervention to get back on.
Anyone, and I mean ANYONE using a mobile phone SHOULD be using a 'bouncer' or other gateway to access a live communications environment. This would be more like use case A where someone has a small agent on a slice of a server they 'trust' and that maintains state (for their client) and stateful connection (for links to other servers and users).
IIRC, Quassel IRC has such a client/server model for the client, there are probably others too.
It occurs to me that if IRC networks hosted their own bouncers, but that these bouncers were written efficiently to exchange data directly with the IRC servers' and their database rather than keep individual logs and so on, we might have something close to the "open-the-app-and-see-past-messages-without-needing-to-be-permanently-connected" quality that people have come to expect from instant messengers, Slack, Discord, etc.
(but then you might as well just write such functionality directly into the IRCd)
Nah, such a thing would make most sense as a separate daemon that uses the server-server protocol to connect to the ircd (ie. it appears to the rest of the network as just another ircd).
It wouldn't be hard to build such a thing, the hard part would be convincing an existing IRC network to run it.
That's what SASL has been for for over a decade nowadays :)
The goal is to get rid of the historic interfaces which required a lot of RTFM, and instead to allow users to discover functionality through the UI easily.
If you have any suggestions on what to improve regarding UX of Quasseldroid (my main project), I'd love to hear suggestions, as I'm always interested in improving its UX and learning more about UX design. After all, I, as quasseldroid maintainer, am just one student, not a team of highly paid UX designers.
(And personally, I'm a huge fan of tools like Zulip, Mattermost and Matrix as well — we're all fighting on the same side, after all :)
https://rocket.chat/
https://zulipchat.com/
https://matrix.org/
https://mattermost.com/And I'm personally working on Quasseldroid, improving its UI to make it much more usable.
If you have suggestions on how to make Quasseldroid usable for the people that refuse to use IRC, I'd love to hear them :)
Sure, but the reason all the developers at my workplace use Slack is because we have to communicate with a lot of people who aren't developers.
Slack's good UX extends beyond the basic chat interface to configuration, administration, and initial signup. It's significantly easier for someone nontechnical to toss money at Slack to get a new private space than it is with IRC. The first page of "IRC hosting" search results on Google for me are mostly shell accounts; nothing turnkey and professional looking that a business person could/would use.
I've used IRC quite a bit but Slack is light years beyond in terms of the UX of even the nicest IRC clients. I think Discord is probably even better than Slack though.
If you think that you can't do free software development without relying on all the capabilities of Slack, then the honest thing to do is to quit and spend the rest of your days just working on proprietary stuff. You obviously prefer the solution which has features over any other concern, so why would you waste your time having anything to do with free software?
Richard Stallman obviously used proprietary software. But not past the point when he had replace it, even imperfectly: "I began work on GNU Emacs in September 1984, and in early 1985 it was beginning to be usable. This enabled me to begin using Unix systems to do editing; having no interest in learning to use vi or ed, I had done my editing on other kinds of machines until then." [https://www.gnu.org/philosophy/fsfs/rms-essays.pdf] This tells us that Stallman used Unix. Well, why wouldn't he have; what other practical way was there to code anything? (One supposes he could have started from the bootloader on up, like the Unix guys before him.)
Stallman wouldn't use Unix today, since it has been replaced by free software, and he wouldn't use arguments like, well, such and such proprietary Unix has better memory management or faster I/O, so I will still use that.
If you're using things like Slack or Github without the slightest intent of working toward replacing them, yet using them for free software activities, then that is a comically conflicted position.
Being technically the best (or the best in 'freedom') doesn't seem relevant to anyone.
IP, TCP, SMTP, HTTP, these are fundamentally technologies of federation. They succeeded and continue to succeed spectacularly. However, with the commercialization of the Internet there are much stronger countercurrents. I still expect federated solutions to succeed, but adoption will be slower and punctuated, and in the interim there'll be countless proprietary also rans.
I think you can see some evidence of what people thought were development machines by the fact that Lisp Machines only seem to have been NFS servers, not NFS clients.
I totally get the value of a non-corporate, non-centralized solution. It just needs to have at least as good of a UX for me to switch back to using it.
https://www.gnu.org/philosophy/open-source-misses-the-point....
> A pure open source enthusiast, one that is not at all influenced by the ideals of free software, will say, “I am surprised you were able to make the program work so well without using our development model, but you did. How can I get a copy?” This attitude will reward schemes that take away our freedom, leading to its loss.
> The free software activist will say, “Your program is very attractive, but I value my freedom more. So I reject your program. I will get my work done some other way, and support a project to develop a free replacement.” If we value our freedom, we can act to maintain and defend it.
Relying on Slack, Github and what have you is clearly not to "get my work done some other way, and support a project to develop a free replacement.” It aligns with attitude exemplified by the "pure open source enthusiast".
And personally I consider the slack UI, especially due to the different workspaces, relatively unintuitive.
I don't see a big difference between sending the message :rose: in Slack and having the client display it as a picture of a rose, vs sending the message :rose: in IRC and having the client display it as a picture of a rose. Emoji don't enter into it.
Reactions, maybe.
Matrix is an incredibly centralized service masquerading as an easily self-hosted distributed service. The moment you try to get a non-technical user connected to a homeserver other than matrix.org, all hell starts to break loose.
It's bad enough that both France (tchap) and Purism have created their own client forks to make on-boarding somewhat tolerable at the expense of really painful rebases against upstream Riot, while Riot tries to get it's shit together on the non-matrix.org user story.
Mattermost has a slightly less painful situation -- they provide a relatively easy to brand/preconfigure client (and fantastic docs on how to do so: https://docs.mattermost.com/mobile/mobile-compile-yourself.h... ), but you lose out on federation and self-service sign-up, leaving your community isolated (sometimes a pro, sometimes a con).