Hacker News Reader

Comment by malvosenior | Hacker News Reader

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.

View on HN

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

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.

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

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.

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.

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.

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.

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.

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.

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

Forget IRC. You can do everything with Matrix :)

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

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.

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.

so, you should be able to enter an mxid (e.g. @matthew:wherever.com) on Riot/iOS & Android and log straight in.

Meanwhile, if you go to Riot/Web on mobile for a custom deployment, you should see a page like this https://webchat.kde.org/mobile_guide/ which guides you through the process.

Deeplinking from web into the app is hard, as the only way to do so vaguely reliably is by fingerprinting the browser using something like branch.io, which is distasteful from a privacy perspective. Meanwhile, affiliate links in google play seem to only work about 30% of the time, given the planets have to be in precisely the right orientation for the association to not get lost.

Mattermost might be doing something smarter (perhaps letting you install the app generically, and then getting you to click a custom URI handler link from the web to provision the correct config on the client?) - but would be useful to know which of these failure modes people were falling into?

> Deeplinking from web into the app is hard

This is exactly whay I was getting at before. Please stop fixating on the deferred form of deep links. The play store need not even be involved for deep linking to an already installed app.

The mobile_guide instructions are where most people bail out.

"Yeah, no. This is too complicated." is the response when they see

"Install an app, then click on a check box that changes the UI, then enter https://foo.bar:8448, then register".

That's a massive turn off before your app is even installed. A flow of "Install this app, then return to this web page" is significantly easier. Or if/when branded builds of Riot are possible, it becomes "Install this app."

have filed https://github.com/vector-im/riot-meta/issues/290

Reply on news.ycombinator.com