1. 15
  1. 9

    The problem with libre chat applications with federation is that they suck. And that’s an honest statement. Matrix is major suck (source: I tried to run a small chat server for a community of 20 people using matrix).

    IRC on the other hand sucks because it has barely any features. Anything beyond the most basic and simplest requirements will in turn require you to run atleast several auxiliary services (like NickServ, which exists on almost every IRC network and none of them seem compatible).

    Any chat service that wants to compete with Discord for the place to communicate about FOSS on, needs to provide the same features as Discord (or atleast a very decent subset of the features) with almost 0 friction. Because that is what Discord offers.

    The End-Users, who will be the primary consumers of your community chat, do not care about restrictive ToS, lack of control or alternative clients. They want to click a link that opens a webpage and it just works intuitively. Ideally they already opened the app and it works out the details in the background. The admins need to be able to easily and effectively moderate the spaces. The returning users will want a chat log built into the app, something they can easily search. Etc etc.

    What they do not want is clicking a link and the app immediately trying to get them to sign up to something, patronizing them in the meantime by explaining what a federated service is and that’s why they need to sign up. We have spent decades to teach users not to sign up to random crap services. They don’t want the interface to be non-intuitive (which is an area in which Matrix seems to try to outcompete GNU projects). They do not care if the client is FOSS or not, they want it to immediately work for them.

    In short, if you want FOSS projects to use FOSS chatops, you need users to pick the FOSS chat app out of practical reasons, not ideological ones. Very few people care about software licensing ideology.

    1. 3

      I have been very happy using Discord for the sole instance I frequent (dealing with analog photography). Everything, from the on-boarding to the clients, have been very smooth.

      I sympathize with the sentiment expressed in the linked argument, but the arguments put forth are only ideological. None of the issues raised in the recently posted article about chat at Mozilla (accessibility in the sense of ease access, moderation of harmful content, ease of use for moderators) are addressed.

      1. 10

        I sympathize with the sentiment expressed in the linked argument, but the arguments put forth are only ideological.

        Perhaps, but… it matters? I mean, yes, it ideologically offends me that I can’t open the developer console in my web browser when I’m using Discord without violating their terms of service, but it is also a practical problem that it doesn’t work well on my laptop, which is not cutting-edge but certainly not out of date by any reasonable measure. It’s not an ideological problem when I ask the Discord devs to fix bugs regarding how their software scans and rescans my video devices hundreds of times a second, wasting CPU time and battery, and am told that I shouldn’t be prying into how the software works. It’s not an ideological problem when I offer them a patch for the issue and am told I’m violating the ToS by modifying the client.

        Discord is anti-user, plain and simple.

      2. 4

        I don’t understand what Matrix is doing.

        Signal is widespread but doesn’t federate. Okay. Their source is FOSS, though, so prop up a hosted version and put a stake in the ground as a commitment to federate. You’ve just saved all the effort it’s taking to develop Matrix, and can pour 100% of your energy into your value-add on top of what Signal already offers.

        Heck, I don’t even understand why people are wasting time writing new clients to go along with their bespoke protocols. Suppose that we accept that there’s something magical in the protocol you’re developing. It still doesn’t follow that you need to split your time, attention, and energy between the protocol and creating new client for it. Take the Signal client and wire it up so that it speaks $WHATEVER.

        1. 8

          I don’t think SIgnal is a great example. moxie has been pretty hostile in the past towards people who try to fork signal, and he has a history of resisting some pretty, imho, important features (e.g. being able to use signal without google crap services) for silly reasons. He did ultimately accept that feature, but not without a lot of struggle.

          1. 0

            So hostile that he decided to give away the source code?

            Besides you’re talking about something completely different. I’‘m not suggesting that people try to work with Signal to get features upstreamed. I’m explicitly saying to do the opposite. Fork it. The code already exists. Why is it a good idea to throw away a team’s scarce development resources just to reimplement a chat UI?

            1. 2

              Why is it a good idea to throw away a team’s scarce development resources just to reimplement a chat UI?

              Well, as someone else pointed out, Signal really isn’t a replacement for IRC/matrix/whatever. They really aren’t even close to being the same thing..

              1. 2

                Also Signal’s Desktop UI (rather than it’s mobile UI) is actually pretty bad. It takes a long time to start up in a way I haven’t noticed on the mobile android app. I mostly use it on my phone rather than my desktop computer, so I dont mind too much, but I wouldn’t actually suggest forking the signal UI to make other chat clients.

                1. 0

                  I’d say we’re going in circles here, but we’re three messages deep and never actually left where we started.

                  That person’s quibble is about the use of phone numbers. For the third time now: Why ignore an existing, proven, solid codebase unless you had to?

                  If you don’t like Signal’s use of phone numbers or something else about the Signal protocol, then don’t use the Signal protocol. Wire it up to the protocol you’re using. There seems to be no good reason for pursuing the totally-from-scratch strategy that folks like Matrix are going after.

                  1. 2

                    I never said anything about phone numbers, maybe you replied to the wrong comment? It’s not really ‘proven’ for the purpose of replacing something like IRC, matrix, etc… In fact, it’s not at all the same, as I mentioned previously.

                    1. 0

                      This is getting pretty exhausting.

                      In addition to actually reading my comments before replying to them, maybe you should read your own and the comments from the other people you’re citing for support.

                      I’m done with this thread.

                      1. 1

                        I’m done with this thread.

                        Good. Because clearly the thread was done with you a long time ago when you stopped comprehending it.

                        1. 0

                          What’s the point of a message like that?

            2. 6

              I don’t see signal as a replacement for IRC at all. Signal uses phone numbers as identifiers - it’s a replacement for text messaging with people you know well enough to give your phone number to. I would actively not want to use a chat system tied to my IRL phone number to talk with people on the internet.

          2. 6

            The terms quoted by Discord are currently standard terms that lawyers (tm) came up to be able to operate a media system. Note the:

            Your Content in connection with operating and providing the Service.

            This means they can create a new client and display it there or provide e.g. a website somewhere that displays current media in a chat.

            Also, it misses the discussion why projects still use Discord despite alternatives being available. I can only speak for the Rust project, but we have evaluated all of the mentioned services and more and found them lacking in a lot of departments.

            I am absolutely not in love with Discord (for philosophical and usability reasons) and am hoping for the moment where we can step of, but the FOSS chat community needs to step up their game at making choosing them a no-brainer.

            Finally, I don’t agree with the “infrastructure control” argument, e.g. Zulip has famously been discontinued and recontinued. The times were projects should bear the load of running their own chat systems are over.

            Shout-out to Zulip and Matrix here though, who have done great strides to be great vendors to the FOSS ecosystem.

            1. 4

              I agree with the ideological argument that free software projects shouldn’t force its users and developers to use proprietary software to communicate in an official capacity.

              I think the biggest practical problem is that IRC is clearly has a more limited featureset than people want, but the most promising FOSS modern chat protocol, Matrix, is still being actively developed and is still buggy. I think the best thing to do to make libre software chat also be libre would be to put more development efforts into making Matrix a more polished piece of software, so that more organizations would reach for it rather than Slack or Discord.

              1. 3

                I agree here, if you want to improve things, get involved in writing modern and slick clients for matrix or zulip and consider joining a client team instead of writing your own.

                As an old-time jabber nerd, I’m kinda pained that jabber lost on the client front much more then the protocol front. Let’s not make this mistake again.

                1. 2

                  The features provided by those new protocols are hardly critical for a software project. Code snippets gets unwieldy after few lines. Stickers and fancy emoticons are distracting and are discouraged in various projects/orgs during serious conversations. The interactive nature of the medium makes it ill suited for polls and in-depth discussions.

                  1. 6

                    I would consider notifications, logs, good mobile support, and persistent presence quite important.

                    1. 4

                      Emoticons and especially emoji reaction are a great way to show agreement, congratulations, disagreement etc. without spamming the channel. They do fulfil a communication role that people have become to expect.

                      1. 1

                        I agree they are useful, I disagree they are critical.