convos VS Zulip

Excellent idea! You'll have a mature, open standard protocol under the hood, with no vendor lock-in, excellent extensibility, and great modern frontends like The Lounge (https://thelounge.chat/) or Convos (https://convos.chat/) to choose from (and you can choose).

And UnrealIRCD still rocks. For a quick-and-dirty setup I've deploy ng-ircd but Unreal has always been my go-to for anything serious. If nothing else it can be useful as a backup or internal platform during the rare events that Slack or Discord are having an incident. The common complaint is a lack of channel back-log but it can be front-ended with TheLounge [1] or Convos [2]. I personally prefer to handle that with gnu screen or tmux and WeeChat [3].

[1] - https://github.com/thelounge

[2] - https://github.com/convos-chat/convos/

[3] - https://weechat.org/

For the other layers one can front-end IRC with TheLounge [1][2] or Convos [3][4]. TheLounge only persists history in private mode meaning that users are created in that front-end and chat messages are in Redis. For small networks or groups of friends this is probably fine.

Notably missing is voice chat. I use the Mumble client [5] with the Murmur or uMurmur [6] server which is light-weight enough to run on ones home router. I use it on Alpine Linux, works great. It's not a shiny and attention grabbing as Discord but probably fine for everyone else. For people to create their own voice channels would require the full-blown Murmur server.

[1] - https://github.com/thelounge

[2] - https://thelounge.chat/

[3] - https://github.com/convos-chat/convos/

[4] - https://convos.chat/

[5] - https://www.mumble.info/

[6] - https://github.com/umurmur/umurmur/wiki/Configuration

FWIW TheLounge [1] and Convos [2] can front-end an IRC server giving it much of the look of a modern client and also chat persistence when using TheLounge in private mode. The trade-off in my opinion is scalability. With a bog standard IRCD I can handle tens of thousands of clients per node. Adding web persistent chat adds memory usage.

[1] - https://github.com/thelounge https://thelounge.chat/

[2] - https://github.com/convos-chat/convos/ https://convos.chat/

IRC is a mature, extensible, open protocol, with a wide variety of server and client implementations to suit many use cases, servers can be self-hosted and federated, and modern web-based clients like The Lounge or Convos offer a user experience equivalent to Discord, Slack, etc.

Standard IRC with a web interface like The Lounge or Convos

And there are some great web-based clients like the Lounge and Convos that offer an equivalent UX to Discord or Slack, are open-source, self-hostable, and based on a mature, reliable, and extensible open protocol.

Take a look at convos to see if it fits your needs: https://convos.chat/

There are web front-ends to IRC that can mitigate message loss without having to run bouncers. Convos [1] and TheLounge [2] come to mind but there are others [3]

[1] - https://convos.chat/

[2] - https://thelounge.chat/

[3] - https://www.ilmarilauhakangas.fi/irc_technology_news_from_th...

Zulip — Real-time chat with a unique email-like threading model. The free plan includes 10,000 messages of search history and File storage up to 5 GB. also, it provides a self-hostable open-source version.

(1) Zulip Chat - https://zulip.com/ - seems to be reasonably popular, but more people should know about it

I’ve been using it for over 5 years now [1], and it’s as good as ever. It’s way faster than any other chat app I’ve used. It has a good UI and conversation model. It has a simple and functional API that lets me curl threads and write blog posts based on them.

(only problem is that I Ctrl-+ in my browser to make the font bigger – I think it’s too dense for most people)

(2) re2c regex to state machine compiler - https://re2c.org

A gem from the 90’s, which people have done a great job maintaining and improving (getting Go and Rust target support in the last few years). I started using it in 2016, and used for a new program a few months ago. I came to the conclusion that it should have been built into C, because C has shitty string processing – and Ken Thompson both invented C AND brought regular languages to computing !!

In comparison, treesitter lexers are very low level, fiddly, and error prone. I recently saw dozens of ad hoc fixes to the tree-sitter-bash lexer, which is unsurprising if you look at the structure of the code (manually crawling through backslashes and braces in C).

https://github.com/tree-sitter/tree-sitter-bash/blob/master/...

These fixes are definitely appreciated, but I think it indicates a problem with the model itself.

(based on https://lobste.rs/s/endspx/software_you_are_thankful_for#c_y...)

[1] https://www.oilshell.org/blog/2018/04/26.html

A few more truly in the vibe of open source projects not advertising their hosting providers: https://plane.so/ , https://element.io/ , https://www.loomio.com/ , https://zulip.com/ , and it keeps going... Very few open source projects, in the FOSS sense, are advertising their hosting provider.

I was so excited to see this happen!

I'm not a customer of yours, but your blog posts inspired me a lot. Your journey through quitting caffeine is a great and heartening read.

I've got two things to say;

1) Will you consider source-availabling the web portal (app.keygen.sh) too? Some enterprises could use it for easy management/support for custoner's licenses. Although now that I think about it, it could also discourage custom, more suitable implementations for each use-case... I'm torn on this one. I would like to see it available on GitHub too just out of curiosity too. It's very beautiful.

2) For a team + customers' chat, I cannot recommend Zulip enough. It's a joy to use and has the most innovative chat system I've ever seen. https://zulip.com

I hope your business keeps prospering!

Zulip | Senior Flutter Engineer | REMOTE or San Francisco | Full-time | https://zulip.com/

At Zulip, we’re out to build the world’s best collaboration platform, and we’re committed to keeping it 100% open source. Zulip is the only modern team chat app that is designed for both live and asynchronous conversations. Our product serves as the communication hub for businesses, open-source projects, educators and communities around the world.

We're building the next generation of Zulip's mobile apps in Flutter. We're looking for a senior engineer with Flutter experience to join our small core team and help define the future of team chat. Our Flutter prototype is just a few months old, so this is a greenfield opportunity to help shape the app's architecture from early on.

For full details, check out https://zulip.com/jobs/. Apply at [email protected].

Anyways, I'm an internet stranger, not a social media expert. So let me know what you all think. And if we make a discord or zulip or something to make this a reality, let me know and I'd love to help any way I can.