Candidates for Mozilla's IRC Successor(exple.tive.org) |
Candidates for Mozilla's IRC Successor(exple.tive.org) |
Personally I don't think IRC will ever be replaced. Well, it will, but it'll happen when my generation dies and gets fully replaced with the New Shiny.
I _hope_ that some sort of real, proper standard, that doesn't endlessly reinvent itself, that isn't subject to some for-profit bollocks, that on a very basic level, has like, a standard, has _clients_ (not just one wanky proprietary web frontend) that just sits and gets the job done like TCP, comes out of all of this.
Meanwhile, I'm fairly sure IRC will still be there in another fifteen.
Hell, at this point, IRC has been a constant in my life for longer than everything other than family. It actually feels like a friend. A portal to another quirky world, just as it did all those years ago.
I think it's almost two decades now since I first logged in. My my. The years are short, indeed.
Ideally you should be able to build a Matrix client in something like a Python REPL and like 20 lines of code with an `input` loop at the end. I don't know if that's the case at the moment.
USERNAME='@whoever:matrix.org'; SERVER='https://matrix.org'; ROOM='#test:matrix.org'
read -s -p "Password for $USERNAME:" PASSWORD
TOKEN=`curl -X POST $SERVER/_matrix/client/r0/login --data "{ 'type': 'm.login.password', 'login': '$USERNAME', 'password': '$PASSWORD' }" | jq .access_token`
ROOM_ID=`curl $SERVER/_matrix/client/r0/directory/room/$ROOM | jq .room_id`; curl "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN"
(while true; do SYNC=`curl -s $SERVER/_matrix/client/r0/sync?access_token=$TOKEN&timeout=30000&since=$SINCE`
echo $SYNC | jq ".rooms.join.$ROOM_ID.timeline"
SINCE=`echo $SYNC | jq .next_batch`; done) &
while true; do read -p "<$USERNAME> " INPUT; `curl -s -X POST $SERVER/_matrix/client/r0/rooms/$ROOM_ID/m.room.message?access_token=$TOKEN --data "{ 'body': '$INPUT', 'msgtype': 'm.text'}"`; done
# set your matrix ID & server URL, and the room you want to chat in:
USERNAME='@whoever:matrix.org'
SERVER='https://matrix.org'
ROOM='#test:matrix.org'
# prompt for a password; log in and grab an access_token
read -s -p "Password for $USERNAME:" PASSWORD
TOKEN=`curl -X POST $SERVER/_matrix/client/r0/login --data "{ 'type': 'm.login.password', 'login': '$USERNAME', 'password': '$PASSWORD' }" | jq .access_token`
# resolve the room alias (#test:matrix.org) to a room ID (!vfFxDRtZSSdspfTSEr:matrix.org)
ROOM_ID=`curl $SERVER/_matrix/client/r0/directory/room/$ROOM | jq .room_id`
# check that you're joined to the room (redundant if you know you're already there)
curl "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN"
# set a background loop running to receive messages, and use jq to filter out the
# messages for the room you care about from the sync response. For now we print them
# as JSON pretty-printed by jq, but that's not too bad.
(while true;
do SYNC=`curl -s $SERVER/_matrix/client/r0/sync?access_token=$TOKEN&timeout=30000&since=$SINCE`
echo $SYNC | jq ".rooms.join.$ROOM_ID.timeline"
SINCE=`echo $SYNC | jq .next_batch`
done) &
# set a foreground loop running to prompt for your own messages and send them
# into the room as plaintext.
while true;
do read -p "<$USERNAME> " INPUT;
`curl -s -X POST $SERVER/_matrix/client/r0/rooms/$ROOM_ID/m.room.message?access_token=$TOKEN --data "{ 'body': '$INPUT', 'msgtype': 'm.text'}"`
done
Needless to say, this'd be much prettier on Python - and you'd prolly want to use a nice SDK like https://github.com/poljar/matrix-nio (see https://matrix.org/blog/2019/07/03/usage-of-matrix-nio/) so you get things like E2E Encryption for free. But doing it in plain bash hopefully gives more of an idea.
I do prefer my chat client to not be a part of my browser. That way I can close my browser, start my browser and chat client on login ie from i3/sway etc. A tab in a browser runs the risk of getting closed.
I love using weechat (weechat.org) and have used it for decades. The Matrix plugin for Weechat is really well done https://github.com/poljar/weechat-matrix
Other people who want to use Riot can if they want at the end of the day I think matrix is probably the best option as it will cater for many people's needs.
But that should also be an option too. Matrix could be great to integrate with for both private and public web communities , and that would incentivize people to create more homeservers. There is currently a lack of such solutions for communities and matrix could fill that gap. It's just sad that we have to end up sending people to sign up to discord .
It was less than 500MB of plaintext irssi logs.
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 eventually.
If you are really referring to phone notifications, well, you can use an IRC client on your phone, then you would get notifications on your phone. I use irssi even on my Android phone.
Let us not forget that there is the other side of the story: many people report that they have been enjoying life more without those phone notifications.
I love IRC. I have been using IRC ever since I was 11. It made me a more technical person. I find that IRC is not that easily accessible to the majority, which is a good thing, because of this, the conversations tend to be of higher quality, and technical in most channels. I would also like to add that IRC is the reason I understand English, and a zillion other things. :)
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 weird how while IRC is full with FOSS people who are willing to use their time on various projects they're not getting paid for, most of whom also seem to worry about IRC dying out, nobody is really doing anything about it. A lot of the conveniences we miss could mostly be solved by making modern clients that are actually good.
Which is, sadly, a lost cause. We had a simple, reliable, open, decentralized base that simply did not adopt to the needs of a changing userbase of the internet enough. Non-technical users have expectations that are incompatible with the text only format and they prefer platforms that feel more like their other social media tools. Technical users don't fix that and get riled up about nonsense instead, like non-TLS connections and other points that were addressed a decade ago, alongside people that just prefer a more decentralized system.
It feels like xkcd #927 is also relevant [0]. The open source world in chat/social platforms often looks like Googlers looking for a promotion instead of addressing real needs and most efforts seem to be drowning in irrelevance. Even technically sensible projects like Matrix, who's going to use that? Not the instagram crowd that's for sure, heck, many technically inclined people cannot be bothered with IRC when the alternative is convenient. I'd be really surprised if we see a widely adopted open messenger in 10 years, it's more likely that people just settle on a new random walled garden every 3-5 years.
I noticed myself using IRC less for this reason. I'd always run weechat on servers so I had the history but never thought to look for notifications these days.
I signed up for IRCCloud and it's been nothing but excellent so far. I can even connect weechat to it like a BNC.
My freenode nick was registered in 2005, and I know that's the "new" registration since I accidentally confused the nickserv RELEASE and DROP commands once, and had to re-register the nick I had just mistakenly unregistered. It had a few years of history prior to 2005, but I don't know the details anymore.
And prior to Freenode, I was on a few other networks going back to '94 or so. But moving networks meant it wasn't a "constant" in terms of being the same environment, just the same interface.
We're not the only ones who feel that IRC will be around until we're gone... https://xkcd.com/1782/
I'm partial towards Matrix/Riot.im - the progress made on those projects is awesome and they really have a highly usable product, with bonuses such as e2e encryption and federation.
There's a lot of alternatives, but until they provide a good user experience, I don't see a point in purposefully making peoples' lives suck.
I'm confident that alternative's to discord will get better with time, but they're really not there yet.
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 a Django authenticator for Mozilla IAM? I would be very happy to help set it up.
Implementing a protocol in Rust is one thing, the choice in protocol is another. I for one hope they choose a standard that's backed by the OSS community (not slack), so we can all have fun with Rust implementations in peace.
Second that there is a perception of plain text as an antiquated medium of communication (and yet we persistently reinvent markdown as a way of simplifying rich text).
Third and most importantly, the issue is not that IRC is old or is missing features, it is that IRC encodes a specific model for running a communication network (hubs, leafs, operators, etc). When we try and replace IRC with a system like Matrix we are giving up the old model of "owned" nodes and the decentralised nature of it to instead bow to a centralised model where certain people wield absolute power. Is this really the right way? what if I want to write a bot to perform some unusual administrative function? do I have keep updating it every time the API changes? that's why IRC is good, I don't need to do that.
There should be a petition to get them to use ( and thus improve) an open source one, maybe matrix or even rocketchat.
Just want to say that I adore Keybase. I think it needs a password manager like bitwarden/lastpass/1password, but a lot of the features are compelling to me. I really hope it gets widespread adoption because the app and the company deserve it, in my opinion.
Based on your earlier article, you mentioned the issue of spam. Slack is even worse than IRC for spam controls, I've seen spammers be hugely disruptive when the admins aren't around. It could be partially solved with bots, but that doesn't stop PM spam.
I looked at the docs for mattermost, riot.im, and rocket.chat.
Seems like rocket.chat has the best docs and lots of fine-grained control about permissions and also has rate limiting. Mattermost also has rate limiting (but API level only?) but their docs are horrible. Riot.im doesn't seem to have any controls.
Personally I'd prefer XMPP.
When Matrix as a protocol settles more, we'll start seeing optimised versions of the server, I'm certain of it.
to me (i'm not a developer, so pardon me while i speak out of turn here) it would make a lot of sense to take the solid, well known foundation of IRC and build upon it, instead of reinventing the wheel over and over again, no?
Setting up a Matrix server is a lot harder than you might think, especially when you start talking about federation and identity management.
The mxisd[1] project has recently disbanded due to what I believe to be philosophical differences with the Matrix maintainers vision of identity management.
I like a lot of things about Riot/Synapse, but I would suggest you try setting up your own Matrix server if you haven't yet. It's not what I would call highly usable.
Mind you, I have only tried setting up the reference implementation (Synapse/Riot). I would be interested in seeing a write-up/comparison done by Mozilla as part of these trials.
That said, I went in with pretty low expectations since it's a reference implementation - I think one of the great advantages of the open-source protocol is that anyone can design/build their own implementations with better UX on the sysadmin side. There are already projects in the works written in golang/rust, and I'm sure if the protocol takes off other languages will follow.
I do agree that the identity server piece is weird. I didn't set one of these up, so I haven't really looked into it (I don't have any 3rd party IDs connected to my matrix username, which from my cursory research is what the identity servers are for) but the philosophy behind them seems to go against the federation narrative the rest of the protocol is designed around. If anyone has done more research into this part of the protocol I'd love to be corrected on this point.
sorry that setting up a homeserver was hard; we’ve been doing a lot of work recently to improve this (eg https://github.com/matrix-org/synapse-config-generator/tree/... is a graphical installer which should be released very shortly).
You have to either make a venv for a binary or just install a package, then reverse proxy 2 ports from your http daemon, and finally also hook things up to your Postgres database. After all that it's just a matter of configuring your homeserver's config (which is large, but you can easily get support via the community for any poorly documented options)
The documentation could definitely be improved, though.
Don't forget Slack also bans people who they think are from sanctioned countries:
https://www.theverge.com/2018/12/20/18150129/slack-iran-deac...
I would like to see a neutral platform be chosen to be honest.
> I would like to see a neutral platform be chosen to be honest.
Exactly, and if one of the FLOSS options are chosen, Mozilla could self-host and not need to rely on any third party.
[0]:https://gist.github.com/maxidorius/5736fd09c9194b7a6dc03b6b8...
The linked gist is loudly complaining (amongst other things) that Riot's default config points at a centralised one by default.
We've already fixed this (https://github.com/vector-im/riot-web/issues/10553) by simply removing the concept of default identity servers entirely and instead prompting the user to select on demand whichever one they want to use, if they actually try to look up a user based on email/phone. It should be released in Riot 1.4 (on Web, and equivalent ones on mobile etc) in the coming weeks.
You can see our response to that original gist at https://matrix.org/blog/2019/06/30/tightening-up-privacy-in-..., and you can track progress over at https://vector-im.github.io/feature-dashboard/#/plan?label=p... (which has a cache from yesterday published at https://matrix.org/~matthew/privacy-sprint.html).
The "IAM problem" is apparently that Mozilla's IAM is based on SAML, which Zulip doesn't have native support for today. There are two possible technical solutions:
* One could use https://zulip.readthedocs.io/en/latest/production/authentica... with https://github.com/Uninett/mod_auth_mellon to integrate SAML authentication for Zulip without any code changes.
* One could add native support for it, using our `python-social-auth` integration. Generally adding an authentication provider supported by `python-social-auth` takes about 50 lines of mostly boilerplate code plus some tests -- not a big effort.
As I mentioned elsewhere in the thread, I sent OP an email yesterday offering for the Zulip core team to do any work required for Mozilla to evaluate Zulip over the next week so they can evaluate Zulip. He replied that it's too late to revisit their decision :(.
For other folks involved in open source projects, you should absolutely consider Zulip! We provide our paid plan completely free to open source projects, can import history from Slack and other tools, and are actively prioritizing features specifically for open source communities (like the ability to search the complete history of all public streams even as a user who just joined).
Open source projects that have switched consistently tell us that Zulip's topic-based threading is a way better model for a distributed community with a lot of volunteers than Slack/IRC/Gitter/etc., making it easier for maintainers to manage the community and helping more new contributors stick around. A few links:
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...
"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 <0.1% of that employee's all-in cost to the company) for a productivity tool. Our pricing is free for open source projects and highly discounted or free for situations where the users aren't full-time staff (e.g. education).
If there's something we could do to be more clear in our pricing page, I'd love to hear it.
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 hosts other services, we can’t support you, but we do have some notes on issues you’ll encounter.
- hmm, I have to download a client? maybe I can access a web interface?
- okay, I have this connection string/url
- how do I join a channel?
- how do I set my nickname? is this persistent?
- oh someone else is using my name? is this for the channel or the server??
- what's the etiquette of this particular channel? (I realize this is probably the case for any chat, but it seems like etiquette is much more vaunted in IRC)
vs. zulip
- enter url in browser
- login with my github credentials
.... that's it
irccloud.com
> okay, I have this connection string/url
No? What clients are you using that don't have an exhaustive network list in them?
> how do I join a channel?
The same way you do in Slack and other alternatives: you look at the channel list
> how do I set my nickname? ...
A good client, such as IRC Cloud, makes setting your nick name easy. Don't be lazy. Learn to use tools.
> ... is this persistent?
Yes, if you register it, and it's easier to register an IRC nickname than it is an account on virtually every other platform - no email/verification required.
> oh someone else is using my name? is this for the channel or the server??
lol?
> what's the etiquette of this particular channel?
That's an actual, serious reason you're put off from IRC?
- What does it replace channels with?
- How does it keep my github account separate from the identity I'm using in chat?
- How does it avoid etiquette in channels?
- Does it let me ignore or mute annoying people?
- Is it possible to easily archive communication for posterity?
Up until slack appeared on the scene. I was a heavy IRCer from '96 to '13, and then switched almost immediately to slack.
Slack sucks in a lot of ways but it happens to hit the sweet point of convenience. It allows me to be a purely 'casual' chatter, I can close and open slack anytime. I don't have to keep irssi running in a screen in the background. I don't have to have a bouncer.
Anyways I think that if a new version of IRC came out with extra convenience for the pure 'casual' user, then we'd all go back to IRC.
By some odd twist of fate, WSL is what enables my IRC use. My only 24/7 PC is my HTPC/Plex server, which I also run ZNC on via WSL.
What's the barrier to a SaaS IRC solution like irccloud?
I personally really dislike using IRC. I am in several IRC channels because some open source projects I use and upstream code to are on IRC. I dislike it very much.
You keep justifying it. If it weren't broken, you wouldn't spend all that time justifying it.
I am over forty, I have used IRC professionally, and have not encountered it with any regularity in the last decade (that is to say exactly 0 times in the last six years). I can understand it's a non starter for younger developers as it is an unusable mess compared to other stuff they use. I suspect that part of the reason Mozilla is switching is that they realized people in their community were working around it already.
The real thing people should be asking about IRC is why attempts to fix, improve, or modernize it consistently get rejected by IRC users. It has not kept up and it isn't for a lack of trying. There have been many attempts to keep it alive and they all keep failing. E.g. slack had an IRC gateway for a while and this proved so unpopular that removing it was barely noticed by anyone. It was there but mostly unloved by IRC users. People voted with their feet by not using it. Now it's gone because apparently it was an unimportant/redundant/irrelevant feature with no commercial value whatsoever for Slack.
The statement I just made sounds like an absurd product but they exist. The weird part is everyone is trying to build it completely in javascript.
Stuff like multi-line posts and markdown are nice, but none of that is worth all the good stuff you lose from irc.
- difficult to monetize
- designed only as a communications medium, not a social medium
- doesn't work like other phone apps
- does not support multimedia or cat ears
That's a common fallacy. Nobody is going to do for free this crucial work for a protocol that is practically unused. Teams should focus more on a strong implementation so the protocol gains ground
Great documentation and sane defaults. I have only 6 lines of custom config.
For context, the background for that advice is that most folks who want Zulip to share with other systems are running a cheap "shared hosting" server with 5 different apps on it and without root access. Before we added that advice, more than 50% of requests for help installing Zulip were problems specific to that type of environment where the user wasn't going to succeed in any case (e.g. because they had an insufficient RAM quota from their hosting provider anyway).
There are reasonable use cases that would benefit from our investing in making this possible, but container technology is convenient enough in 2019 that it doesn't feel worth it over other high-value investments in making Zulip accessible to a wider audience.
It may help to just add a third box up top for Open Source or something. I didn't think that there would be a totally different tier listed below in the FAQs.
I felt as though getting Matrix 95% up and running was relatively straight-forward, but I spent far too long trying to configure self-registration, email verification and domain whitelisting through mxisd that I gave up. These don't seem like uncommon scenarios for organisations wishing to run their own Matrix instance.
In contrast, a Mattermost instance that supported self-registration and domain whitelisting was up and running in almost no time.
The config generator will be a welcome addition. I will probably revisit Matrix some time in the future.
ma1sd is considered stable and works afaik, and is already part of the matrix ecosystem.
On the other hand, the same usage pattern with other chat apps such as Zulip/Slack/Mattermost and others requires no specialized knowledge.
irccloud.com looks great, except for the fact that you have to pay if you don't want to be kicked off after 2 hours of inactivity.
Yes, people need to eat. Sorry about that.
They've been knowingly and willingly violating the GDPR since it came in to force despite constant reminders of that fact.
That's quite the inflamatory statement to throw out there without at least providing a source or two.
* General instability - I got plenty of notifications that the connection to Freenode had been dropped
* A couple of channels outright banned me for connecting from an IRCCloud host.
fyi: github wikis are just a repo full of markdown files. you can clone down your wiki, make changes, write commits, etc.
You realize we’re talking about Mozilla, right?
> requiring social media
They’re explicitly choosing between social media platforms...
And Mozilla, more than perhaps anybody else, should be aware that web browsers facilitate surveillance of users.
I have no idea why you think browsers are a tool to facilitate surveillance to a greater extent than dedicated clients. If a nation state or corporation can compromise your browser, they can realistically compromise your entire OS.
After seeing this blog post, I emailed the OP yesterday offering to add whatever they need to evaluate Zulip (which sounds like is just SAML authentication work that's was already on our near-term roadmap). He replied that they're too late in their evaluation process to consider Zulip :(. I really wish they'd thought to get in touch with us about this concern.
I think it also dampens the same for traditional paid software in a lot of areas, incidentally.
It works very well now, and the Android client is pretty great too, but there are still some gaps. Mainly, the surrounding ecosystem is quite sparse, e.g.: - There is basically only a single web client for it (node-based, which is a con from my perspective) - There are only a handful of semi-functional log searching/browsing utilities around
I think it’s important to not be “using a library” since the test case is hopefully that the protocol is easy enough to get something barebones with even super baseline tools. Your bash script obviously matches this requirement
My reference here is the excellent Haskell Wiki “Build tour own IRC bot”. Really captures the simplicity of the protocol
> I used bashtrix for about 4 hours this morning. Why, you ask? I didn't have the bandwidth, latency or reliability to use Riot. I ended up using bashtrix on one of my servers through mosh...
> Could have done with scroll back (the screen fills up with 'null' and '[]' – the latter, I started to recognise as marking read receipts and/or perhaps presence) but shrank the font size down and made the most of it :p. Worked Rather well considering
This seems to indicate it's missing a register step, and then it fails to be as simple as IRC where you just set nickname and connect to a server. Sometimes the server asks you to identify yourself, but that's up to the server, not the protocol.
That said, Matrix also supports guest accounts (which are quite locked down to prevent abuse, but would work for this example) - so the /login request could be replaced by calling /register with type=guest which would then do what you want.
edit: it would look something like this (7 lines now!):
SERVER='https://matrix.org'; ROOM='#test:matrix.org'
TOKEN=`curl -X POST $SERVER/_matrix/client/r0/register --data "{ 'kind': 'guest' }" | jq .access_token`
ROOM_ID=`curl $SERVER/_matrix/client/r0/directory/room/$ROOM | jq .room_id`; curl "$SERVER/_matrix/client/r0/join/$ROOM_ID?access_token=$TOKEN"
(while true; do SYNC=`curl -s $SERVER/_matrix/client/r0/sync?access_token=$TOKEN&timeout=30000&since=$SINCE`
echo $SYNC | jq ".rooms.join.$ROOM_ID.timeline"
SINCE=`echo $SYNC | jq .next_batch`; done) &
while true; do read -p "> " INPUT; `curl -s -X POST $SERVER/_matrix/client/r0/rooms/$ROOM_ID/m.room.message?access_token=$TOKEN --data "{ 'body': '$INPUT', 'msgtype': 'm.text'}"`; doneDo take a look at https://gitlab.com/darnir/matrix-shell-suite
It's a basic matrix client written in pure POSIX sh.
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.
I don't miss anything.
>I have no idea why you think browsers are a tool to facilitate surveillance to a greater extent than dedicated clients.
Because that's simply factually the case? IRC networks do not give my IRC client proprietary tracking scripts to run. With an IRC client if any third party code execution occurs, it's due to an exploit in the client. On the other hand with web browsers, servers sending malicious scripts for the browser to run is par for the course.
Typical modern web browsers (even Mozilla's own) are total disasters, particularly in their default configuration. Why the hell aren't they shipping with resist-fingerprinting turned on by default? Because it would mildly inconvenience some users, and despite all their good intentions and positive words, they still prioritize user perception of convenience over privacy.
It might or might not be well managed in the years to come. Case in point, Skype. It was "the" tool to use for office communication. Hardly anyone I know uses Skype nowadays.
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 be applied to people or named threads.
Zulip defaults to full archiving of everything, and making it searchable as well.
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.
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:
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.
> Zulip doesn't do anything with github other than the regex-based integration
I see. The parent poster implied that there's no need to pick a username, and that he logs in with GitHub. That implied that it used your GitHub account name, since I don't see another way to enforce unique names.
https://zulipchat.com/help/restrict-visibility-of-email-addr...
Seems extremely minor. I'm very far from disturbed.
(I also have issues with how slow the ICO are at investigating, but that's a different story)
cough Mozilla cough Slack cough
I won’t be able to say more than that, but I can’t stand by suggesting that we don’t care about this issue. I’ve been personally advocating for these things longer than that issue has been open.
When it's intentionally simple to sit in 50 rooms 95% of the time, it's pretty stupid for a disconnection to make you lose out on random chunks, or for you to miss events because you wanted to turn off your computer.
When you intend to be always in a room, and the only roadblock is the inconveniences of modern tech, the logical state of "inside a room" should be decoupled from "has an active TCP connection". So sure you'd miss what people talk about if you left, but a disruption to your TCP connection would not trigger leaving.
Or you're trying to have a normal conversation on a phone connection, or a flaky connection. Or switch to your phone in the middle.
Or you want to link something to a group of friends and you only want to send one message.