[jcastro]

> Because they don't give a rat's ass about the freedom aspect of free software.

It's attitudes like this that make people really not care about FOSS. Yelling at people because they're not using IRC instead of slack isn't a good way to convince anyone.

[kuschku]

When IRC looks like this https://quasseldroid.info/assets/images/phone.png or this https://blog.irccloud.com/static/2018-05-14-slack-integratio... and people still complain about IRC’s UI or usability, then what more can we IRC devs do?

[komali2]

For me the issue with IRC protocol (not that I know much about it outside my interaction with UIs built around it) was authentication, and connectivity.

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.

[mjevans]

That's more an issue with your connection. Mobile devices have really bad connections. IRC was //never// designed with them in mind; they literally didn't exist and were not likely to exist for decades (which it has been).

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.

[zapzupnz]

I guess that's the thing, though. Yes, mobile users should be using a bouncer — but who's going to set it up for them, who's going to host it for free and in a manner that it has guaranteed next-to-no-downtime?

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)

[caf]

(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.

[kuschku]

> 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.

That's what SASL has been for for over a decade nowadays :)

https://i.k8r.eu/Jr-NBg.png

[jcastro]

Maybe consider the UX that Slack gives users instead of just cloning the UI on top of IRC and expect it to work out?

[kuschku]

That's a major part of what I've done recently, trying to significantly reduce complexity, and contribute to clients to make them more discoverable and require less knowledge to fully utilize them.

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 :)

[pixelrevision]

IRC had its problems but I’d still rather be able to control my ui rather than have a bloated web browser running all day.

[jamesgeck0]

IRCCloud is okay, but the UX/UI isn't anywhere near as nice as Slack.

[jeena]

Why would you need to use Slack (or IRC) when there is

    https://rocket.chat/
    https://zulipchat.com/
    https://matrix.org/
    https://mattermost.com/

[Crinus]

Probably because the few people who want to use alternatives to Slack are spread among these four alternatives instead of using one and sticking with it.

And honestly, of all the alternatives, IRC is by far the most popular one (and the other alternatives have IRC bridges) hence the most likely to stay around the longest.

Also the simplest to implement, which helps a lot too.

[kuschku]

That may be true, but it's good enough that it should be easily usable by developers.

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 :)

[jamesgeck0]

> it's good enough that it should be easily usable by developers.

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.

[ummonk]

I know plenty who use IRCCloud. There is nothing FOSS about it, though.

[malvosenior]

Neither of those look as good as Slack imho. Regardless, there's a bunch of stuff you can do with Slack that you can't with IRC. Emoji reactions, voice/video/screenshare, easily post files and images... Plus there's a unified experience for all users that's not client dependent, no burdensome technical or protocol jargon, no federated servers (or servers to think about at all)...

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.

[kazinator]

"federated servers" is the only way to maintain a form of freedom while (out of necessity) operating software as a service.

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.

[oneplane]

Federation has been tried a lot and in the end it always fails, even if it's the best solution. XMMP is pretty much dead regarding free use, IRC for a lot of FOSS project is slowing dying, there were a lot of federated social media projects that simply failed because they couldn't attract anyone.

Being technically the best (or the best in 'freedom') doesn't seem relevant to anyone.

[wahern]

Centralization has never succeeded. Let's see how popular Slack is in 5 years. 10 years. There's no reason to believe it won't go the way of ICQ, AIM, Yahoo Messenger, etc.

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.

[oneplane]

I suppose you are right from a technology standpoint. I was aiming at the user-facing side of things. There is SMTP and email that is federated and usable by most people, so I suppose there are examples of user-success.

[rjsw]

I would guess that he was editing source on ITS or a Lisp Machine before this point.

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.

[malvosenior]

Yeah, I don't think so. I work on other OSS and happily use Slack because it's fun and easy (I used to use IRC). I'm not conflicted at all because I appreciate a good UX. I think it would be totally awesome if more open source developers realized that people will use whatever is better for them which often doesn't mean prioritizing openness over usability or features.

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.

[kazinator]

You're only narrowly escape being conflicted because you identify as an "OSS" developer rather than a "free software" developer. The term "open source" and its identification was basically crafted to avoid being conflicted this way.

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".

[malvosenior]

This is correct. I care about user experience far more than any political statement. I love open source because I'm a developer and can work with the codebase but that doesn't hinder my enjoyment of closed source software at all if it provides an excellent user experience. There are way more buckets someone may fall into rather than closed source freedom killer and free software activist.

[kuschku]

Emoji reactions are actually a thing nowadays thanks to IRCv3 :)

And personally I consider the slack UI, especially due to the different workspaces, relatively unintuitive.

[thaumasiotes]

> there's a bunch of stuff you can do with Slack that you can't with IRC. Emoji reactions

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.

[floatboth]

Forget IRC. You can do everything with Matrix :)

[subway]

Kinda-sorta?

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).

[Arathorn]

This is pretty disingenuous - we have spent loads of time making Riot work well with self-hosted servers (c.f. the current login & registration flows, which explicitly prompt you to select a server), and around 50% of the network are running their own servers. Our intention is to turn off the original matrix.org server once we have decentralised accounts and the network is healthy enough.

[subway]

Please share a useful workflow for getting a non-technical user onto a non matrix.org homeserver.

I've personally run 3 homeservers for communities formerly centered around Facebook, only one of which was technical. For the non-technical communities the workflow was the one provided by riot-web when a mobile user visits the homeserver.

Neither of the non-technical communities saw more than 5% adoption in the org. The technical community constantly complained about the login flow.

When I deployed Mattermost with a custom app for the first non-technical community I saw 40% adoption within a week, and 80 within the month. The second community has looked at the first as an example, and I can expect 80%+ adoption within a week or two of deployment.

I've asked repeatedly in both #ios:matrix.org and #android:matrix.org about assistance in putting together docs similar to mattermost's and was completely ignored.

I've asked if the Riot folks would be open to deep-links providing the homeserver to mobile apps, and was shut down by somebody who insisted deferred deep links were the only kind of deep links, and that they would only ever be supported by a Google Play on-boarding flow.

I really want to love Matrix, but y'all make it fucking difficult sometimes.