Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Slack is inappropriate for open source communications

dave.cheney.net

Post reply on HN
Print view View original

461–470 of 536 posts

Re: Why Slack is inappropriate for open source communications

#461

Post by Arathorn »

ptman wrote: post #449
Arathorn wrote: post #261

Earlier quoted context omitted.

(that said, I think the point of Dave Cheney's article is more that sync realtime chat is bad for FOSS collaboration relative to mailing lists and forums. So until Matrix finally lands threading & forum semantics and smtp/nntp bridges, I suspect it's part of the problem he's complaining about :D)

Threading I know is being worked on, but is SMTP/NNTP anything other than a jape?

SMTP/IMAP is very serious - we would love to bridge email convos into Matrix eventually. I suspect we're a little late to rescue NNTP though but perhaps someone will write a bridge for sentimental reasons :)

Re: Why Slack is inappropriate for open source communications

#462

Post by mfukar »

creeble wrote: post #43
mfukar wrote: post #10

I must've missed the memo which says any conversation around the globe is waiting for my input before it proceeds.

Well put. But you may have missed the memo because you're in the wrong time zone, and with Slack, your possibly-relevant input is ignored because you can't participate in real time. This is my beef with chat. As the OP says, it biases all conversation to those in the same time zone. Fine for some things (like baked goods arriving in some far-off kitchen), but not for others (like a design decision that should have in…

I agree, but it's not a shortcoming of the tool (no tool can fix it, anyway) as much as a shortcoming of the process.

Re: Why Slack is inappropriate for open source communications

#464

Post by ZoomZoomZoom »

joaodlf wrote: post #125

Forums. I don't know why the internet got tired of them, even when they sometimes fit the bill so well. Slack is chat. Mailing lists are far too outdated. Forums are good, and some good people out there are still developing them.

It's such a disappointment that social networks killed forums! The experience is so much poorer now. There's insane amount of fragmentation (everybody wants to run their own thing because likes), no search, no discoverability, no ways to conveniently track the discussions.

But the main huge drawback, from my point of view, is that non-anonymous model of conversation means people more inclined to judge you from looking at your profile and not from the specific local reputation, which was a thing with forums.

Re: Why Slack is inappropriate for open source communications

#465

Post by akerro »

ktta wrote: post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

You have completely misunderstood the post.

Re: Why Slack is inappropriate for open source communications

#466

Post by milesrout »

photojosh wrote: post #404
milesrout wrote: post #374

Earlier quoted context omitted.

>Are you serious? I think lots of people do. I think it's one of the draws of Slack. No it isn't. What it implies is what people want: persistent logs, signing in from their phone logging them into the same session as signing in from their desktop, etc. >Is that what Slack does? Whatever they do, I think it's what people want. Indeed it is not an experience offered by IRC, perhaps because "most IRC servers don't want…

> Slack has a much higher barrier to entry than IRC and most people using it are private companies. Only if you're a nerd. Took me 5 minutes to get started with Slack for our company and managing it is a piece of cake. Mind you, I haven't used IRC for a decade, maybe it's become a whole lot easier since then...

Also, 'only if you're a nerd' is very silly. We're talking about this in the context of open source software. Everyone that is capable of non-trivially contributing to open source software is more than capable of operating an IRC client.

In fact, if you can't work out IRC then you're almost certainly too silly to be a programmer.

Re: Why Slack is inappropriate for open source communications

#467

Post by Arathorn »

zAy0LfpBZLC8mAC wrote: post #455
Arathorn wrote: post #425

Earlier quoted context omitted.

From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API - e.g. what arguments do you pass when you paginate? what data do you get when you sync? how do you tell it where to sync from? etc. I genuinely don't care whether you do RPC via an HTTP PUT, a COAP PUT, an MQTT Publish, or some funky custom RPC of your own devi…

> From my perspective, the defining bit of Matrix is the data model (eventually-consistent decentralised Merkle DAGs), the schema, and the semantics of the API Great, and where is that actually specified? > or whether you encode the data as JSON, CBOR, BSON, protobufs or whatever Except that you still need at least a sort-of JSON generator for the signing stuff, thus only adding bloat by using a different format? > I…

The encoding-agnostic schema for Matrix events is defined at https://github.com/matrix-org/matrix-doc/tree/master/event-s.... We haven't yet written up a transport-agnostic description of the client-server API, mainly because the spec is WIP and we haven't got to it yet, and because in practice it's trivial to procedurally convert the HTTP endpoints into whatever RPC mechanism you prefer. PUTing some JSON to a HTTP URI trivially maps to a JSON-over-TCP RPC mechanism or whatever it is you're pushing for.

Your complaint about the layering seems to be that the HTTP URIs sometimes include values (e.g. event types) associated with the JSON payloads, and that this is a layering violation. This is because HTTP isn't being used as a dumb data transfer transport (e.g. your HTTP v. SFTP example) but as an RPC transport - and you pass parameters when you make an RPC call. Sure, it means you have to map the RPC mechanism if you switch transports, but it's hardly the end of the world. In future I guess we'll specify the CS API semantics as some IDL style format to make it easier to map to other RPCs.

The idea that you can't expose alternative transports because "adding additional complexity when you are already exposing an HTTP engine is braindead" is just obtuse. If you really don't trust HTTP then by all means turn off the HTTP listener the client-server API and only support clients which talk your better transport protocol. You're obviously stuck talking it on the federation API for now, but we've always reserved the right to switch to an entirely different federation mechanism (e.g. a pure TCP line protocol, WebRTC datachannels, the IPFS DAG or whatever) in future - the migration would be similar to bridging Matrix with any other new network.

The idea that HTTP client libraries like python's, go's or curl's are somehow less reputable or audited than those used in web browsers seems questionable at best. But agreed that the last thing we need is a large distributed network which can be used as a botnet, and obviously it's in our interests to avoid that. Unconvinced that vulnerable HTTP stacks is the biggest risk there though...

Re: Why Slack is inappropriate for open source communications

#468

Post by erlehmann_ »

ktta wrote: post #213

A great alternative to Slack, in the spirit of IRC, is matrix[1]. It has lots of clients, and a great vision. You use an online client called riot[2] which uses the matrix protocol. There are other clients available[3] including desktop clients. There's E2E encryption coming to more of the clients which is inspired from signal protocol (double ratchet part of it specifically), without Forward secrecy so as to maintai…

I see advertising for Matrix every single time the chat topic comes up. Having looked at the protocol, it seems massively more inefficient than just using XMPP, which has numerous clients and a lot of features. Can Matrix do anything that XMPP can not?

Note that I have read the claims at http://matrix.org/docs/guides/faq.html#what-is-the-differenc... but critizising the minimal XMPP baseline feature set while claiming that XMPP is not being “well designed for mobile use cases” seems like someone wants to have their cake and eat it too – I have used XMPP over low-bandwith high-latency mobile data connections for years and noticed that XMPP's stream syncronization is a really nice feature for that use case.

Re: Why Slack is inappropriate for open source communications

#469

Post by ryanbrunner »

milesrout wrote: post #407
photojosh wrote: post #404

Earlier quoted context omitted.

> Slack has a much higher barrier to entry than IRC and most people using it are private companies. Only if you're a nerd. Took me 5 minutes to get started with Slack for our company and managing it is a piece of cake. Mind you, I haven't used IRC for a decade, maybe it's become a whole lot easier since then...

>Only if you're a nerd. Took me 5 minutes to get started with Slack for our company and managing it is a piece of cake. Slack requires you to make an account on their website, a new account for every Slack group. IRC you can just join - pick a nickname and type the server's address and you're in. IRC is completely trivially easy to use, Slack is not.

Setting up an e-mail address and a password is not an incredibly complex task. I have 3 seperate slack groups that are set up just for friends to chat.

Besides which, on most IRC servers, you're going to be using NickServ anyway, which is more complex a flow than setting up a user on Slack.

Re: Why Slack is inappropriate for open source communications

#470

Post by kuschku »

duskwuff wrote: post #270
iffycan wrote: post #263

Earlier quoted context omitted.

Call me crazy, but I think your example illustrates one reason why IRC is great: I can read it. And I could probably get it right even typing it from memory.

The IRC protocol is surprisingly difficult to implement correctly. I'm not an expert on the issues involved, but a few of the high points include: * No standard maximum message length. If you input a line which is more than 510 characters after being prefixed with the channel name, server name, and other metadata, it may be truncated for some clients. If you're on a network which includes multiple servers, some clien…

That was true a few years ago, but is long invalid, due to many recent changes. Nowadays it looks like this:

> * No standard identity services. NickServ is a common bolt-on, but it's a total hack. (It works by pretending it's another IRC server!)

SASL and account-notify.

> * No way to determine when certain commands have succeeded. In particular, commands which can generate multiple lines of output (like WHOIS) don't have a standardized termination. Command-line clients sidestep the issue by just showing all the output in one place; higher-level clients have to guess.

Batch messages.

You can find more at http://ircv3.net/, there’s a lot of specs on modern IRC features. IRC has changed a lot, you might want to take a look at it again ;)

Post reply on HN