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

Candidates for Mozilla's IRC Successor

exple.tive.org

Post reply on HN
Print view View original

171–180 of 219 posts

Re: Candidates for Mozilla's IRC Successor

#171

Post by dole »

zingmars wrote: post #88
jjcm wrote: post #57

Earlier quoted context omitted.

Die? No, but it is slowly degrading. More and more the people in my old freenode chatrooms are idle or simply leaving. We've gotten so used to phone notifications and a persistent history, that IRC has fallen behind purely from a convenience factor. It's rock solid in what it does, I have zero doubt about that or your 15 year claim. But even if the protocol works, if the user base isn't being added to it will die eve…

> We've gotten so used to phone notifications and a persistent history, that IRC has fallen behind purely from a convenience factor. I have that with a bouncer (znc) and a plugin. I've not used it, but it is my understanding that IRCCloud does this too. Problem is that there aren't many easily usable options for this apart from IRCCloud and even IRCCloud itself isn't all that well marketed. Always seemed kind of weir…

IRCv3 is still moving forward and gaining momentum.

Re: Candidates for Mozilla's IRC Successor

#172

Post by johnisgood »

Dylan16807 wrote: post #147
johnisgood wrote: post #129

Earlier quoted context omitted.

You can have both notifications and a persistent history with the majority of IRC clients. Many public channels keep logs, even. If someone pings me (hilight), then I get an urgency hint. Most window managers handle urgency hints. I use openbox + xterm + irssi. I do get notified if someone pings me, and I can also add any arbitrary words for which I would get notified. With a small Perl script I could use notify-send…

Persistent history including things that happened when you weren't connected . Obviously logging is easy, this isn't about client logs. With phone notifications, you not only need to work for things that happened while not connected, it's bad form to require a permanent connection on android and you can't do it at all on an iphone.

Perhaps what you need is a bouncer?

Re: Candidates for Mozilla's IRC Successor

#173

Post by johnisgood »

Krasnol wrote: post #162
Dylan16807 wrote: post #147

Earlier quoted context omitted.

Persistent history including things that happened when you weren't connected . Obviously logging is easy, this isn't about client logs. With phone notifications, you not only need to work for things that happened while not connected, it's bad form to require a permanent connection on android and you can't do it at all on an iphone.

We have https://thelounge.chat/ running. I don't miss anything.

Yeah, there is https://www.irccloud.com/ as well, and probably many other alternatives.

Re: Candidates for Mozilla's IRC Successor

#174

Post by corndoge »

Avamander wrote: post #112
corndoge wrote: post #6

Earlier quoted context omitted.

Keybase chat doesn't have a server client available. It is nothing like IRC.

Actually there's a bot available https://github.com/keybase/bot-sshca in addition to the regular CLI API keybase has.

What does this have to do with keybase chat?

Re: Candidates for Mozilla's IRC Successor

#175

Post by woodrowbarlow »

EamonnMR wrote: post #154
techntoke wrote: post #68

Earlier quoted context omitted.

You must really dislike GitHub then.

I can more or less easily get my data out of github (I can host a repo elsewhere, write a script to scrape the issues, etc.) I don't like using the non-git parts of it for much (ie why write a wiki when you can just make a repo full of markdown files?) Discord is a whole other level of walled garden. It's a black hole of information, and that information isn't owned by you. Discoverability is nonexistent.

> why write a wiki when you can just make a repo full of markdown files?

fyi: github wikis are just a repo full of markdown files. you can clone down your wiki, make changes, write commits, etc.

Re: Candidates for Mozilla's IRC Successor

#176

Post by fluffything »

buboard wrote: post #116
lima wrote: post #94

I'm sad to see Zulip excluded from the list. It solves the #1 issue with large group chats - proper threading. Nothing worse than waking up to a 1000 message backlog you have to sort through to filter out the information relevant to you. Except for Slack, all of their other choices have very poor threading. They said they had trouble to get it working behind IAM, but Zulip is just a Django application. Surely there's…

> but Zulip is just a Django application. Yet again: > The installer expects Zulip to be the only thing running on the system; it will install system packages with apt (like nginx, postgresql, and redis) and configure them for its own use. We strongly recommend using either a fresh machine instance in a cloud provider, a fresh VM, or a dedicated machine. If you decide to disregard our advice and use a server that hos…

So why is that a problem ? I expect Mozilla IAM to handle VMs just fine.

Re: Candidates for Mozilla's IRC Successor

#177

Post by fluffything »

dsr_ wrote: post #125
buboard wrote: post #116

Earlier quoted context omitted.

> but Zulip is just a Django application. Yet again: > The installer expects Zulip to be the only thing running on the system; it will install system packages with apt (like nginx, postgresql, and redis) and configure them for its own use. We strongly recommend using either a fresh machine instance in a cloud provider, a fresh VM, or a dedicated machine. If you decide to disregard our advice and use a server that hos…

Mozilla is large enough that they could go over to the Zulip developers and ask nicely for what they need, and stand a good chance of getting it.

Zulip is open source, and the community is both large and very active. So at least they can open a github issue explaining the problem. And if they want to use the tool, they can just submit PRs like everybody else.

Re: Candidates for Mozilla's IRC Successor

#178

Post by [deleted] »

EamonnMR wrote: post #154
techntoke wrote: post #68

Earlier quoted context omitted.

You must really dislike GitHub then.

I can more or less easily get my data out of github (I can host a repo elsewhere, write a script to scrape the issues, etc.) I don't like using the non-git parts of it for much (ie why write a wiki when you can just make a repo full of markdown files?) Discord is a whole other level of walled garden. It's a black hole of information, and that information isn't owned by you. Discoverability is nonexistent.

[deleted]

Re: Candidates for Mozilla's IRC Successor

#179

Post by tabbott »

olah_1 wrote: post #168
lima wrote: post #94

I'm sad to see Zulip excluded from the list. It solves the #1 issue with large group chats - proper threading. Nothing worse than waking up to a 1000 message backlog you have to sort through to filter out the information relevant to you. Except for Slack, all of their other choices have very poor threading. They said they had trouble to get it working behind IAM, but Zulip is just a Django application. Surely there's…

It's $7 per user per month unless you are a favored open source project that they want to bless. Unless I'm reading the pricing info[1] incorrectly, it seems like the free plan wouldn't be even close to being usable for a project of more than 2 people... [1]: https://zulipchat.com/plans/

Our plans page reads:

"Zulip Cloud Standard is free for open source projects and affiliated institutions."

which I thought was unambiguous that our paid plan is free for open source projects.

The intent of our pricing model is to charge businesses $80/employee/year for use by full-time staff. If you're a business that can afford to hire people, you can definitely afford $80/employee/year (under If there's something we could do to be more clear in our pricing page, I'd love to hear it.

Re: Candidates for Mozilla's IRC Successor

#180

Post by tabbott »

ori_b wrote: post #138
dsr_ wrote: post #126

Earlier quoted context omitted.

Zulip uses three classes of communication: Streams which are like IRC channels; each stream has named threads (users are encouraged to reuse or start new ones as appropriate); and private messages can be 1:1 or multiparty. Zulip doesn't do anything with github other than the regex-based integration -- you can create links more easily, that's it. Nothing avoids etiquette or enforces etiquette except people. Muting can…

> Nothing avoids etiquette or enforces etiquette except people. So why is it listed as an IRC specific problem? > Zulip defaults to full archiving of everything, and making it searchable as well. I have IRC logs from dead networks dating from over 15 years ago, and I still sometimes look things up in them. I don't want to trust Zulip to survive 15 years.

> I don't want to trust Zulip to survive 15 years.

You don't need to, we have an official tool that generates an HTML archive: https://github.com/zulip/zulip_archive. We recently adopted it from the great folks at the Lean Prover community, but we have plans to make it a lot nicer over the next couple months.

That said, one of Zulip's central technical design principles is to invest in making a codebase that is easy to understand, well-documented, and readable, with the goal of ensuring Zulip is able to thrive for the next 15 years and beyond.

I've been meaning to write a series of blog posts on the topic, but check out the 150K words of mostly Zulip developer-facing documentation on our ReadTheDocs:

https://zulip.readthedocs.io/en/latest/overview/readme.html

Post reply on HN