Replacement for IRC

[darobin]

A lot of our users are not familiar with IRC and struggle to figure it out. While the issue is likely less painful than with mailing lists, it is worth thinking about an IRC replacement.

So far however I have not been convinced with the alternatives. Any suggestions? Gitter? Slack? Any experience using those at scale?

[iherman]

I think the real issue is not IRC or other, but the bot-s than we have and we would like to use. Having the experience with calls in other environments, the queue control of zakim, for example, is extremely valuable and we need something similar (I am always suffering on calls that do not have any similar tools; it is always chaotic). RSS agent + scribe script is another example.

Ivan

On 30 Mar 2015, at 11:02 , Robin Berjon notifications@github.com wrote:

A lot of our users are not familiar with IRC and struggle to figure it out. While the issue is likely less painful than with mailing lists, it is worth thinking about an IRC replacement.

So far however I have not been convinced with the alternatives. Any suggestions? Gitter? Slack? Any experience using those at scale?

— Reply to this email directly or view it on GitHub.

---

Ivan Herman, W3C Digital Publishing Activity Lead Home: http://www.w3.org/People/Ivan/ mobile: +31-641044153 ORCID ID: http://orcid.org/0000-0003-0782-2704

[darobin]

I completely agree that if we were to use an alternative to IRC, it would have to expose facilities that allow us to script it in the way that we script IRC.

[xquery]

google hangouts ? gitter has an interesting bot with integration to irc

https://github.com/finnp/gitter-irc-bot

I have no experience with slack ...for selfish reasons I would prefer any new approach to integrate with an IRC client.

unsure if a 'frankenstein' layer over IRC is better then declaring wholesale bankruptcy for IRC ... also I imagine being able to export data is a primary concern to ensure perm record.

[darobin]

Gitter does have IRC integration, but in my experience it has been flaky. I am also unconvinced about tying chat to a repo — it seems weird.

I've never seen a Hangout with decent performance. As far as I can tell it is one of those Google properties developed by people who only test on a 16-core/32GB box running the latest Chrome.

I'm not ready to declare bankruptcy on IRC yet either. Maybe there's a nice Web interface to it that we could set up? We have one that's decent, but it might be a bit outdated.

[xquery]

that maybe a better direction, brief search yields;

https://github.com/erming/shout or http://demo.shout-irc.com/

this kind of server side solution is interesting.

others such as

https://github.com/torhve/glowing-bear

builds off the web client which is less attractive.

[darobin]

Thanks, Shout looks promising indeed — I'm adding it to the document as an option.

[sideshowbarker]

Gitter does have IRC integration, but in my experience it has been flaky. I am also unconvinced about tying chat to a repo — it seems weird.

Actually Gitter allows you to set up any arbitrary channel you want, as long as it doesn't stomp on somebody else's existing username/orgname/reponame. The per-repo channels are just ones that are sorta set up by default. They do have the big advantage of being discoverable/guessable for the highly common use case of wanting somewhere to report a possible bug in real time against the view from a particular repo, without needing to hunt around trying to instead guess where else you might have a chance of tracking down the maintainers for some synchronous discussion.

They also provide some tight off-the-shelf integration with the features of the repo, so you easily configure the channel to show notifications for build breakage, new pull requests, etc., with popups right in the same channel page that show diffs, etc.

On top of that, you can use markdown right in the channel and see it formatted, including images. And if you mirror it to an IRC channel, it's all still viewable and usable.

So it seems to me that trying to come up with an alternative to Gitter for our use cases is likely going to amount to reinventing Gitter in the end.

I think if we have use cases that Gitter doesn't currently serve well, or some other heartburn with any current Gitter behavior, it would be fruitful to contact the Gitter founder/chief-maintainer and have some discussion with him. In my experience he's extremely responsive and seems very interested in making it meet people's needs.

[darobin]

I don't deny that Gitter has several advantages, which you cite. The main issue I've had with it has been IRC -> Gitter integration which I find renders poorly and is sometimes days out of sync. I certainly don't think we should be reinventing Gitter — I am just wondering if it makes sense to have all of our chatting be on Gitter, or perhaps just some specific instances.

[sideshowbarker]

I am just wondering if it makes sense to have all of our chatting be on Gitter, or perhaps just some specific instances.

Sure. I don't plan marks on abandoning IRC for Gitter any time soon. I think the value of Gitter will only prove itself if/when it ever gets a critical mass odd github users and becomes a place where most github users just take for grantedーjust expect to find some level of communication taking place there when they come looking.

As far as what specific instances of discussion it's well suited for, I guess it sorta goes without saying but it's inherently suited to discussions that are closely bound to a particular repoー at the simplest level, pretty much like a repo's issue tracker, except synchronous and less costly in terms of the time from everyone involved.

The main issue I've had with it has been IRC -> Gitter integration which I find renders poorly and is sometimes days out of sync.

The sync latency is simply due to the crudeness of the current bots. That's all. It's not caused by any inherent problems in Gitter itself. The gateway bot I've used myself is not something Gitter provides or officially supportsーinstead it's something somebody slapped together in a couple hours and hasn't updated because it's just working fine for him as-is. Or for all I know it could be he's made massive updates in the last few weeksー or somebody else hasー and I just need to pull the latest code.

Anyway, regardless, I'm fairly certain any of the sync problems you've seen will just disappear once some less crude bots are available. Or maybe they are already available but just aren't being used where you're looking.

[darobin]

That's good to hear about the bots!

Still, it leaves me unsure what to do with this in the report. I think it suggests the following:

1. Stick to IRC, we're not replacing it soon. But give it a nicer interface.
2. Don't rule out Gitter. It's not an IRC replacement, but it is one of several tools that people ought to look into.
3. If Gitter becomes a thing, we'll need to make sure we're archiving it.

WDYT?

[ericprud]

Guessing this is the tail of a deep thread… (Why is the threading flat in github mail?)

• Robin Berjon notifications@github.com [2015-03-30 03:44-0700]

  I don't deny that Gitter has several advantages, which you cite. The main issue I've had with it has been IRC -> Gitter integration which I find renders poorly and is sometimes days out of sync. I certainly don't think we should be reinventing Gitter — I am just wondering if it makes sense to have all of our chatting be on Gitter, or perhaps just some specific instances.

I frequently use a combo of irc or skype and piratepad. Mike, do you see Gitter markdown meeting some of those collaborative doc needs or is it just for making serial text purty?

---

Reply to this email directly or view it on GitHub: https://github.com/w3c/modern-tooling/issues/16#issuecomment-87631993

-ericP

office: +1.617.599.3509 mobile: +33.6.80.80.35.59

(eric@w3.org) Feel free to forward this message to any list for any purpose other than email address distribution.

There are subtle nuances encoded in font variation and clever layout which can only be seen by printing this message on high-clay paper.

[sideshowbarker]

Still, it leaves me unsure what to do with this in the report. I think it suggests the following:

Stick to IRC, we're not replacing it soon. But give it a nicer interface.

I’m personally very comfortable with IRC and I know a lot of the longtime W3C community is too. I don’t think it’s broken. But at the same time, it’s clearly pretty important to think about the needs of the new people we don’t have involved so far but who we’d like like to attract—people whose ideas and expertise we’d like to be getting greater benefits from, on some kind of scale. And it seems like an implicit theme of the modern tooling effort is, we need to consider whether our existing tools are getting in the way of helping more people get involved in our work, or are they helping to attract them to it and to give them a good return on their investment of time.

And while I totally understand the idea of putting a nicer interface on IRC, I think that might be the wrong way of looking at it. At the more basic level, it’s really nice to have things like qwebirc (the IRC-Web gateway that W3C and Freenode both use) and above them, the ones that aim to do a little more. But I think they're all still aiming too low. I think what we instead need more at this point in the history of the Web are tools that are designed as Web-first systems, that also happen to provide some (degraded) level of communication with legacy systems like IRC that lack the richness of the Web, and the universality/addressability of the Web, and all the other qualities that you get from designing something for the Web from the get-go.

Don't rule out Gitter. It's not an IRC replacement, but it is one of several tools that people ought to look into.

I think looking at it from a “not an IRC replacement” POV is probably the wrong way to look at it. I realize I'm exceeding that scope of this issue, but since I'm already doing that I'll take the opportunity to go all the way and suggest we try looking at this problem from a forward-looking long-term perspective that we want a synchronous many-to-many communication tool that’s truly Web-first and that genuinely takes advantage of the core qualities of the Web—and we should start judging things in terms of what we really want to have, and aspire to see that become a reality.

To me there are not truly extraordinary qualities unique to IRC as a protocol that are tying us to it. The ties at this points as far as I can see are just familiarity and inertia. Well that and the fact we have a critical mass of users congregated on IRC already—but that just goes along with the inertia.

Anyway, more that anything else what I really like about Gitter is that seems to be taking a real Web-first approach rather than just trying to slap more lipstick on the IRC pig.

Further, Gitter has already become an IRC replacement for me for at least one of my projects: the Gitter channel for the validator repo is the place that’s been emerging as the first place to have validator-focused discussions in real time—after people recently starting wandering in there looking to find just that. Previously I had no specific IRC channel for such discussions, so in this case, the Gitter channel isn't replacing something that already existed—it’s instead creating opportunities for new kinds of discussions we didn’t have a place for previously.

If Gitter becomes a thing, we'll need to make sure we're archiving it.

Not sure if you knew already that every channel on Gitter is already being archived by Gitter—for an example, see the archive for the validator channel—but if so maybe you meant we need to make sure we’re keeping our own archive? If so, I guess then it seems like that’s the same as the general concern of having some separate copy of anything we’ve got hosted at github (e.g., the record of the issues from the issue tracker, the wiki content). But in the case of github we already have that solved for the most part by the fact that github provides an API to getting to that stuff—and in the case of wiki content, it's just a clonable repo. Perhaps Gitter provides a similar API to their archive contents, or otherwise provides some way to export them if needed.

[sideshowbarker]

I frequently use a combo of irc or skype and piratepad.

piratepad is an etherpad variety?

Mike, do you see Gitter markdown meeting some of those collaborative doc needs or is it just for making serial text purty?

Certainly Gitter (or any similar Web-first system that somebody else might come up with) pretty clearly has the potential to meet collaboration needs a lot more smoothly and naturally and Webbily than other ad-hoc combinations we’ve kludged together from Webbish tech (like etherpad/piratepad) with off-Web tech like Skype and IRC. It’s not a big stretch of imagination to envisage WebRTC voice+video interaction integrated directly into Gitter or similar. And not much further to imagine something etherpad-like that’s truly peer-to-peer, again just using WebRTC.

[sideshowbarker]

BTW outside of the Web-first quality, I think a goal for any synchronous many-to-many communication tool we adopt is that be attractive enough and productive enough that more people choose to use it instead of sending e-mail or instead of doing other things that clog us all up with yet more asynchronous notifications that just accumulate and sit somewhere, the way e-mail messages and such do.

[darobin]

@sideshowbarker I don't disagree with any of your statements, but it still leaves me mulling over what I ought to write up in the report concerning this :)

Re archiving, I did indeed mean that we need to be able to keep our own copy. That is indeed what we need to do for GitHub as well. It's not a differential treatment for Gitter, I know they keep archives which is really cool, it's just a general rule.

I get the impression that what you're looking for is something that does to IRC/chat what Discourse did to forums: turn the space into a real Web thing that works as awesomely well as the Web can. If so, I couldn't agree more. I don't know if you've tried Slack, but it certainly goes a fair bit of the of the way there. Unfortunately the free version has limitations that I don't think are compatible with the scale that we're looking at.

Similar limitations apply to Gitter btw: http://blog.gitter.im/2015/03/31/free-for-teams-of-up-to-25/. The limit of 25 likely works fine for many cases, but we'd certainly hit it. And $5/user/month gets steep fast after that!

[timbl]

The document needs some guiding principles. One is, what ever happens it is archived in machine-readable form forever by w3c. Another is that whatever happens is linked to from data of the underlying social structure so that it can be found from (data-generated) group home pages, etc.

We use Gitter in the linkeddata Github organization and Melvin produced a logger which saved the chat in machine-readable form. There is a human-readable link from the github organization to the gitter channel. Hey we are a standards body. We can make the effort of making the things which save all the different discussion spaces to data files use compatible formats so one could search them all and build a chat-archive reader which could be pointed at any of them.

[darobin]

I didn't want to go too far in terms of guiding principles — I get enough flak for writing too long and too philosophical already :) — but I did include some high-level notions in http://w3c.github.io/modern-tooling/#principles-for-external-tool-integration. The last § there speaks to your requirement (up to a point).

A key technical part of the approach is that everything gets archived at our end (http://w3c.github.io/modern-tooling/#unified-feeds); what few things cannot be captured there (the actual content of git repositories for instance) have their own backup (http://w3c.github.io/modern-tooling/#de-facto-github).

All of these events that get saved are then available as JSON data over HTTP. That is not the ideal format for everything, but it is a good unifying format. The idea is that downstream of the unified feed can sit pretty much anything listening to (filtered) content coming from it. This can be used to send email or IRC notifications (as indicated) but it could also be used to provide exports to any useful format.

In terms of the social structure, I certainly agree. My idea (sort of implicit in http://w3c.github.io/modern-tooling/#dashboard-1 but not clearly so) is that we can create structure easily. All events stored by the unified feed have enough information to identify their source. The dashboard needs to group those in order to be useful. An example will be clearest.

Say we have a Kitchen WG and it has repositories for its diverse specs; the Toaster API, the Ice Cream Churn Controller, the Shopping List Data Platform. No user of the Dashboard who's interested in tracking the Kitchen WG wants to have to create their own filter to track all of those specs (plus other events linked to the WG), as well as remember to update it when the group adds a new deliverable. The idea is that someone (typically the Team contact) will create a "Kitchen WG" filter that includes all the relevant sources. This feeds into a widget that shows all the results of that query so people can just add the "Kitchen WG" source and immediately see the results.

But the same filter can also be used for other things. There is nothing that prevents a group page from also using the data from the same filter to embed the information.

I'd love to make this happen magically rather than through a bit of configuration but I as much as I would be delighted to get funding for complex network analysis research I reckon the AC might consider that out of scope ;) My plan is to make said configuration really simple so that it isn't a problem.

[sideshowbarker]

I get the impression that what you're looking for is something that does to IRC/chat what Discourse did to forums: turn the space into a real Web thing that works as awesomely well as the Web can.

Yeah—though I don't think Gitter has nearly as ambitious a philosophy behind it as Discourse does (I mean with regard to Discourse being carefully designed to promote “civil discourse”, not just to make the best use of the Web that it can).

If so, I couldn't agree more. I don't know if you've tried Slack, but it certainly goes a fair bit of the of the way there.

I've not looked at Slack yet at all but will take a look.

Unfortunately the free version has limitations that I don't think are compatible with the scale that we're looking at. Similar limitations apply to Gitter

Not knowing Slack, I’m not sure what the specific limitations are in Slack that we'd run into. But I’m pretty sure it's actually not true that we'd run into similar limitations with Gitter—because Gitter in fact places no limitations on the number of people that can use a particular normal public Gitter room/channel at the same time. It does place some limitations on other types of rooms/channels, but I think those aren't relevant to our needs anyway, so we'd not need to worry about them. More details below.

btw: http://blog.gitter.im/2015/03/31/free-for-teams-of-up-to-25/. The limit of 25 likely works fine for many cases, but we'd certainly hit it. And $5/user/month gets steep fast after that!

100% agreed. Needing to pay anything per user per month is a non-starter. And $5/user/month is just nuts. But it’s irrelevant because in our case we would never actually have to pay anything at all. That’s cause the only thing that Gitter puts the 25-person limit on is the number of people in either a “private room” or what they call an “organization room”—as opposed to what they call a “public room“.

I think the meaning of “private room” is pretty clear in this context—it’s a room that you opt-in to making private, similar to the way you’d opt-in to making a particular github repo private. So in that case just as with github, you’d run into some limits on what you can get for free if you want that kind of privacy.

But “organization room” a bit of a term of art Gitter uses to specifically mean a room that Gitter automatically sets up for every github organization and that only members of that particular organization have access to. Our github W3C organization has such a room at https://gitter.im/w3c/ and the WebSpecs org has one at https://gitter.im/webspecs/ etc.

To compare it to our the mailing-list/WG taxonomy, those Gitter “organization rooms” are the similar to W3C member-only mailing lists, and opposed to W3C public mailing lists.

But we’re not restricted to only using those limited-to-25-people “organization rooms”, nor required to actually use them for anything. In fact I don’t know what we’d actually want to use them for.

Other than those “organization rooms” and any rooms that you opt-in to making private for some reason, all other Gitter per-repo rooms and any-arbitrary-name-you-want-to-create rooms have no limits on the number of participants. They are pretty much like one of our W3C public mailing lists: anybody can join, anybody can post messages, anybody can read them. For example, there’s already a Gitter room at https://gitter.im/w3c/modern-tooling with no participation limits.

[sideshowbarker]

Some updates from chatting with the Gitter founder today; quoting him:

1) the irc bridge was completely rewritten recently and is open source (https://github.com/gitterHQ/irc-bridge). it should no longer be flakey. if it is, we'd love to hear about it. 2) the paid plans are designed for commercial/for-profit institutes, we'd be more than happy to give your org a free plan so you wouldn't have to pay.

[frivoal]

I've used slack before, and would probably meet our requirements from a usage point of view. In particular, it is quite easy to integrate with things and write custom hooks and event handlers.

I am less convinced their pricing structure would work for us, even though I am not opposed in principle to paying for things. However, the underlying service isn't (as far as I can tell) based on an open protocol, and I don't think it would be appropriate for the w3c to rely on a proprietary system.

And I think that's the real issue. IRC is adequate for our needs, but far from great, so replacing it is tempting. But if you restrict (and I think we should) our search to open protocols, there isn't much left, I have yet to see anything better for us.

[odinho]

However, the underlying service isn't (as far as I can tell) based on an open protocol, and I don't think it would be appropriate for the w3c to rely on a proprietary system.

This. Indeed I also think IRC is the least-worst. A big problem with IRC currently is that no-one makes good clients for it. Shout is the best I've seen, we've been looking a bit at it for use internally at Opera already.

There's really nothing I can see in something like Gitter and Slack that shouldn't be possible to do with a federated backend, but the actual client work is lacking. For much of the core functionality (as I've seen) even IRC would work. The siloed web has become very strong.

If there was a GitHub for IRC that could solve it. Maybe IRCCloud should be added to this document as a potential hosted client for people to use. I'm not sure if they have anything such as an organization account, they would want to still be able to sell directly to users like now.

So there's IRC, I believe we should stay on an open protocol for communication, and nothing beats IRC currently. In the realm of other open protocols that exist, I'd like to suggest and introduce Matrix.

Matrix is a rather new project, and I would think it too soon for something like W3C tooling to look at. However, part of the project is also having strong IRC-links so that it can bootstrap itself on an existing network (the usual network problem). I'd suggest reading this LWN article on it: https://lwn.net/Articles/632572/ But their website has also become much better since I last checked it, and the project is gaining some steam and seems to be progressing fast: http://matrix.org/

[sideshowbarker]

However, the underlying service isn't (as far as I can tell) based on an open protocol, and I don't think it would be appropriate for the w3c to rely on a proprietary system

What does it mean for a Web-based many-to-many chat system to be based on an open protocol? Clearly such a Web-based system is already based on Web protocols. You can use it from multiple different browsers. It’s a open service. Are you suggesting a chat system should only be based on a protocol that’s usable outside of the Web, from a client application other than a Web browser?

[frivoal]

@sideshowbarker : Neither slack nor gitter are "web-based chat systems". Yes, they both have web-based clients, but they also have apps for all sorts of platforms. They might be very nice services, but they're not based on the type of open standards that the W3C champions.

It’s a open service.

In what sense? It's a service, and it's open for business? That's not very useful of a definition :)

Are there clients for this service implemented by different parties? Are there open source clients? Can you make one without risking being sued? Can we find alternative providers of the same service? Can we provide the service under our own domain name? Can we host the service ourselves? Can we continue using the service if the original service provider goes out of business or otherwise discontinue the service?

This list doesn't define "open protocol", but if you find yourself saying no to most questions, then it's unlikely that the thing your looking at is open in any meaningful sense.

Just because something can be viewed through a browser doesn't make it an open protocol. Otherwise, MS Windows is an open protocol, as I can use it through a web-based VNC client.

[plinss]

If we're really looking for an open protocol to replace IRC, it seems the obvious one to be looking at here is XMPP. It has a broad range of existing clients, it scales, it's completely open, lots of client libraries ( https://xmpp.org/xmpp-software/libraries/ ), and it's federated (also has a strong security model via TLS/DNSSEC/DANE).

It's currently used by IETF as well.

[frivoal]

Yes, in terms of openness, XMPP fits the bill (and hardly anything else does). It is much less clear to me that in actually would serve us better than IRC in terms of actual feature set though. In particular, the feature set of XMPP is huge when you consider extensions, but the interoperable featureset of XMPP is much more limited when looking at what typical clients and server actually implement.

And if the main goal is to increase ease of adoption to newcomers, XMPP is probably worse than IRC. Relatively few people already have an account they could use, AND it's harder to set up one than with IRC.

[marcoscaceres]

And if the main goal is to increase ease of adoption to newcomers, XMPP is probably worse than IRC. Relatively few people already have an account they could use, AND it's harder to set up one than with IRC.

Agree. Let's just keep providing IRC and let the community work out the best tools for communication for what they want to use. I honestly don't think we need to do anything here.

[sideshowbarker]

It’s a open service.

In what sense? It's a service, and it's open for business? That's not very useful of a definition :)

Among other things, in the sense that the Gitter service is actually fully accessible over IRC, using any IRC client you want to use with it; details at https://irc.gitter.im/

On top of that, they also provide MIT-licensed open-source code for an IRC bridge to connect with their service, if you prefer to run such a bridge locally yourself rather than using the one they provide.

(I have more to add but I think that’s probably sufficient for now, and anyway it’s 3:40am where I am so I'm going to chime in on this issue again after I get some sleep.)

[liamquin]

On Wed, 2015-04-15 at 11:27 -0700, Florian Rivoal wrote:

Yes, in terms of openness, XMPP fits the bill (and hardly anything else does). It is much less clear to me that in actually would serve us better than IRC in terms of actual feature set though. In particular, the feature set of XMPP is huge when you consider extensions, but the interoperable featureset of XMPP is much more limited when looking at what typical clients and server actually implement.

And if the main goal is to increase ease of adoption to newcomers, XMPP is probably worse than IRC. Relatively few people already have an account they could use, AND it's harder to set up one than with IRC.

Maybe people could use their W3C accounts, if the W3C systems team did the necessary integration work...

But in addition our existing tools, such as the Zakim bot, RRSAgent, tracker, botie, would need significant work, along with scribe.pl used for drafting minutes. So it's quite a cost without a clear (to me at least) benefit.

---

Reply to this email directly or view it on GitHub: https://github.com/w3c/modern-tooling/issues/16#issuecomment-93521981

[darobin]

I'm with @marcoscaceres here. Groups can, and in fact should, experiment with whatever tools they see fit. The only constraint is that we should be able to get our content back. With that in mind, Gitter fits the bill, Slack doesn't.

So if you want to use Gitter, use Gitter! We'll figure out the integration. If organically the groups that aren't using Gitter get Gitter-envy, then we'll all use Gitter! People who've spent time with it seem to like it a fair bit, which is really promising.

I don't see it as a goal of this project to top-down police the tools that people use. No one made it a policy to use GitHub, and yet here we all are. The goal of this project is to enable people to go forth and pick a thousand flowers without getting lost in the woods. Then show your pretty bouquets to your friends: they just might want to join you for a picnic in your clearing. I could cultivate this metaphor further but I think you get the point: it's all about cross-pollination.

In some cases we can recommend that older, less used tools should be phased out. But it's safe to say that IRC isn't there just yet.

[sideshowbarker]

I don't see it as a goal of this project to top-down police the tools that people use. In some cases we can recommend that older, less used tools should be phased out. But it's safe to say that IRC isn't there just yet.

100% agreed. Like I said way back at https://github.com/w3c/modern-tooling/issues/16#issuecomment-87636962:

I don't plan on abandoning IRC for Gitter any time soon. I think the value of Gitter will only prove itself if/when it ever gets a critical mass of github users and becomes a place most github users just take for grantedーjust expect to find some level of communication taking place there when they come looking.

I don’t want us to “replace” IRC but I am saying that when we have choices we should not just continue choosing to let inertia keep us locked into old systems we’re all comfortable with and whose shortcomings we’re all already inured to ourselves—and especially not unintentionally forcing new contributors to also adopt our choices-by-inertia if that’s in practice what they end up being forced into because that’s where the rest of us are all and have been since the dawn of time.

I think we have an opportunity to take a few risks here and help and encourage each other to get out of our comfort zones a bit and try some new things—especially new things that are using the same Web-platform technologies we’ve all been spending years of our professional lives working to develop.

t

[darobin]

Yeah, I think we're in violent agreement. I think there's going to be a great opportunity to experiment with Gitter coming up — let's do that!

[elf-pavlik]

What do you think about deploying http://shout-irc.com on https://irc.w3.org and people can simply choose to use channels on any IRC server: W3C, Freenode, Gitter, Slack etc.

Also currently W3C IRC doesn't manage identity AFAIK, I made demo once imposing @tantek on #social IWC log, W3C log

Last but not least @aaronpk did very nice setup of Loqi the Friendly IRC Bot on #social, we can even gamble now :stuck_out_tongue_winking_eye:

BTW IndieWeb folks can even favorite/like/bookmark messages from IRC

[Valodim]

found this discussion randomly and it's still open:

I'd like to add that the previously suggested matrix.org has not only reached a reasonably mature state in their reference implementation by now, but they have also grown a modern client for web, android and ios called Riot. More importantly though, they have an irc bridge which puts others I've seen to shame. Please do give it a shot If this ticket being open means you're still on irc and possibly looking for modern alternatives.

disclaimer: not affiliated with matrix.org, just a fan. I apologize for commenting from the sidelines :)

[plinss]

FWIW I've been taking a look at matrix.org and I'm impressed so far. The TAG will likely be giving it a try as we're currently using Slack, and this looks like a nice open, distributed, replacement.

[tripu]

Matrix++

(If we were to try Slack, we should consider Mattermost too/instead: it's an alternative that is both free and gratis, and we could host it ourselves.)

[xfq]

FYI - Gitter will be free and open-source:

Next piece of wow: we will be open sourcing all of the Gitter. That’s right, the web application, the mobile apps, the whole nine yards, free and open. This will not only allow the community to give back and improve Gitter for everyone, but will also allow communities to run their own Gitter instances.

[...]

We have a little bit of work to do to remove some internal configuration and operating parameters from the Gitter source code. We expect to have this completed and to move the code over to GitLab.com no later than June 2017.

Source: http://blog.gitter.im/2017/03/15/gitter-gitlab-acquisition/

[astorije]

Hey everyone! I know this thread a century-old, and some of you are not even involved with this anymore, but I just wanted to clarify something quickly. @vivienlacourba pointed me to this thread because it mentioned Shout, but note that Shout is not maintained anymore. The Lounge, an official (as in, approved by the author of Shout) and community-maintained fork started some time ago, and its codebase has grown significantly (almost 3 times as many commits), and is actively maintained by a few community members now. Some of the differences between Shout and The Lounge are listed here.

Feel free to stop by the repo, #thelounge on Freenode, and/or ask questions on Stack Overflow.

Just like Shout, you'll find a demo here, but note that the demo is in public mode, i.e. something that acts like a qwebirc, short-lived sessions that close and disconnect you when closing the tab. The Lounge's private mode, however, supports users, and resembles more like a Slack-like client that connects to IRC servers, and keeps you logged-in when you're not using your laptop. Private sessions are synced between devices. In fact, looking at this section, one can just read s/Shout/The Lounge/ and all of it would still be true.

@odinho, just curious, is Opera still using Shout internally?

[odinho]

@astorije Hi, I don't work for Opera anymore. But we got up a quite nice fork of Shout that logged people in using LDAP and auto-joined you to your relevant channels (based on your LDAP groups) on first login.

However, not long after (and before any announcement), IRC was killed in favour of Slack which became the official chat-tool. :/ So we were a bit too late in saving IRC.

[astorije]

Hey @odinho, thanks for the context!

It's a bit of a shame when you hear about cool forks that were not shown back to the upstream project, but seeing that daily at work, I can totally understand why and what would happen. And not nearly as a shame as hearing IRC was dropped in favor of Slack!

In any case, if someone stops by, The Lounge does support LDAP natively now (though we could use some help in maintaining and improving it!).

Thanks for your answer! 👋

[liamquin]

On Fri, 2017-08-25 at 15:56 -0700, Jérémie Astori wrote:

@vivienlacourba pointed me to this thread because it mentioned Shout, but note that Shout is not maintained anymore. The Lounge, an official (as in, approved by the author of Shout) and community-maintained fork started some time ago, and its codebase has grown significantly (almost 3 times as many commits),

Thanks.

There seem to be a tone of in-browser chat systems these days, most of which are short-lived or have few users but a few that look like they might stay.

Although I'm not sure we need to replace IRC - tools aren't bad merely because they were invented more than 6 days ago - any replacement needs to be hugely multi-platform and accessible and multilingual, as IRC use tends to be required for full participation, and we can't require something that would exclude people.

https://github.com/thelounge/lounge suggests (actually, states) that you need to run node.js in order to run a Lounge client, which I think makes it to high a barrier. I almost stopped looking but found on another page a link to a demo which, confusingly, didn't seem to require node (I'm not running it) and connected to a regular irc server (I think), suggesting it's an IRC client (which wouldn't move us away from IRC). I briefly found another home age for it with more info, but I'm lost in a maze of irritating github pages and wikis. The home page https://github.com/thelounge/lounge/wiki being one of the least useful :) although it does have a link to "Use Systemctl to run The Lounge as a Systemd Service on Linux" -an extraordinary thing to do for an IRC client.

I don't think an IRC client that requires people to be running node (or systemd, or edit systemd files) will work for us, except i was able to try the demo without doing those things, leading me just to get frustrated with the documentation. I know, i know, modern tools don't have documentation, you just have to be part of the in crowd :-). But this seems much too complex, unless I'm missing something (in which case i'd be more interestedi n contributing)

We have plenty of users who struggle with the existing IRC Web page. A replacement should presumably work without JavaScript on the client, work with a Braille terminal, a text reader, etc.... even if the interface on a desktop client is nicer.

-- Liam Quin, W3C, http://www.w3.org/People/Quin/ Staff contact for Verifiable Claims WG, XQuery WG

Web slave for http://www.fromoldbooks.org/

[xfq]

@liamquin

IIUC The Lounge is just like qwebirc we're using currently, and qwebirc is an IRC client running on a server (just like The Lounge requiring Node.js, qwebirc requires Python). Users connect to the qwebirc server, and use it as a client to connect to irc.w3.org.

But one difference is that The Lounge can remain connected to IRC servers while you are offline (if you choose to).

[Valodim]

I still urge you to seriously look at matrix. It's a nicely working client for web, ios and android (native and with actual push notifications). Administration of the synapse server is a breeze since it's debian packaged, nothing to do besides the occasional apt-get upgrade. It's federated so people who already have a matrix account can just join. Most importantly, for those people and bots that are on current irc - they can stay right there, zero change required. Just leave the ircd as is, and run a bridge in addition.

I've done the same process to great success at my local hackerspace.

If this is a problem of who's doing the work, I would absolutely volunteer to administrate a synapse+bridge+riot-web setup for you folks

[astorije]

Hey there @liamquin, long time no see! 👋 I have to say, I have known you less fiery than that :D (j/k)

Joke aside, this is great feedback, let me answer you fully.

First, the bad news. Bad news is that The Lounge is not capable of the needs you describes. Good news is, all of those that are not are in fact, planned. For example, it is already multi-platform. It is not multilingual, but we are currently working on that part. My point being that none of what you mentioned was considered a no-go.

Then a bit of precision: the actual client needs... nothing. Well, no, it needs a browser, and nothing else. You do not need Node.js, or to know what systemd is, etc. For the user, it is meant to be dead-simple, so that everyone and their mother can use it without having to be versed to the IRC world first. Clear UI, simple and intuitive UX. And this is what you experienced when you tried the demo: just need for a browser and 💥 you're on IRC.

It is true however that The Lounge needs Node.js to run (actually, that's all it requires, systemd, nginx, and others are just integration sugarcoating), but it's on the server side, i.e. maintained by an administrator. Just like to run a website, you'll need an admin to install Apache/nginx, etc., but to use it, users will just need a browser.

So in the end, typical usage looks like this:

[     IRC Server     ] <----> [The Lounge server] <----> [   The Lounge client   ]
e.g.: irc://irc.w3.org         Requires Node.js           Requires a web browser
                               Sits on a server           No administration at all
                               for ex. managed by
                               systeam

Does this help? The reason why there is a server running between the IRC server(s) and the actual end-user client is mostly for user management: by having an account on that server, all my networks and channels are kept when my client is closed, I can see the scrollback in the morning, etc. Essentially, this acts like ZNC bouncer. And since The Lounge is fully an IRC client, anyone not using The Lounge can still interact with users of The Lounge, it does not tie you into anything.

Now that I have clarified this: your feedback is totally useful! This clearly shows me that the documentation entirely focuses on administration and completely fails to advise the end user. This is great feedback because the documentation is being completely redone, immediately followed by the website (which is mostly a landing page). While the former primarily informs admins how to set it up, the website should much much better explain and inform the user. Also, the app (the client) itself has a Help section to guide users, and we are constantly improving it.

You rightfully noted the wiki is a mess: the website is meant to be the official source of truth, and the wiki a community effort that everyone can augment. As we have some wiki content that is true enough to be officially rubber-stamped, part of it is being moved to the main website. And we should indeed make it clearer that wiki is a community, unofficial, potentially outdated effort, and direct to the main website/documentation more clearly.

@liamquin, is that any clearer? Let me know if you have any questions, I would be more than happy to answer them :)

[iherman]

I cannot answer for @liamquin, but it is certainly much clearer to me, @astorije, thanks.

So my question is: what do I get if I run this as opposed to a lambda IRC server? My answer, based on what I see is

1. the client is sexier:-)
2. the client runs in a web browser, ie, I do not need to install yet another application and, hopefully, it also runs the same way on my iPad/iPhone
3. when I log in, I see whatever happened on my channels, it is not lost (in this respect it behaves a bit like Slack)

Out of these, #3 is, obviously, the most important aspect.

Did I miss something?

thanks...

[tripu]

For those interested in Matrix, these are some W3C-related rooms atm:

• #w3c:matrix.org
• #_w3c_#w3c:matrix.org
• #_w3c_#webassembly:matrix.org

IRC bridges:

• #freenode_#w3c:matrix.org (the channel of all W3C friends, alumni, traitors)
• #freenode_#html:matrix.org (HyperText Markup Language)
• #freenode_#swig:matrix.org (Semantic Web Interest Group 24x7 publicly logged hack-'n'-chat)

about.riot.im is a good place to create an account and get started.

[xfq]

Mozilla is switching to Matrix: https://matrix.org/blog/2019/12/19/welcoming-mozilla-to-matrix/

[plinss]

FWIW, the TAG has been running our own Matrix server for some time. We also have a Matrix to IRC bridge that, while not yet perfect (it's not quite at 1.0), is good enough that I have replaced my IRC client with it. (The primary missing feature is the ability to initiate direct chats with other IRC users.)

Anyone with an account on any Matrix server can currently join W3C IRC rooms by joining the matrix room: #irc.w3.org_#<irc-room-name>:w3ctag.org. Feel free to use it.

(The majority of the TAG currently prefers Slack, because they have other teams that use Slack and it saves them from running yet another chat client. I'll be brining a Matrix to Slack bridge online sometime soon that should hopefully eliminate the need to run Slack.)

[Valodim]

@plinss fyi, the slack bridge is excellent and reached 1.0 earlier this year. very much worth a shot.

As for w3 bridging efforts to pick up IRC users from irc.w3.org, with a homeserver running on irc.w3.org that's only responsible for bridging but carries no native matrix users, those rooms could be joined as #room:irc.w3.org. That said, in my experience once people go native matrix, they don't look back to irc :)

[plinss]

@Valodim I have played with the Slack bridge in the past but found it lacking, I know it's gotten better but just haven't had the bandwidth to set it up again. Will do soon.

If the W3C sets up a matrix homeserver with an IRC bridge they certainly will allow native Matrix users to participate in existing IRC rooms, as well as allowing those that continue to use IRC to participate in any new Matrix rooms (might take a custom bot to keep new rooms bridged, but that can easily be written). The shift from IRC to Matrix can happen on an individual basis based on each user's needs and preferences. The rooms could simply be #<existing-irc-room-name>:w3.org on Matrix.

[frivoal]

I'm running my own matrix server, with an IRC bridge to w3c's IRC as well, and it's been working fine, including the ability to initiate direct chats with other IRC users. The bridge does have a few rough edges, but basically it works.