To clarify, the changes detailed here are to do with IRC as a low level protocol. While these enhancements do have user benefit, many of the user experience improvements we work on aren't necessarily at the protocol level.
For instance, things like file sharing, persistent logging, synced mobile clients, push notifications etc can all be built as extra infrastructure on top of the protocol. In the same way that the Slack protocol doesn't give you file sharing without somewhere to host hose files, IRC as a protocol is less useful without services built around it. And that's the main benefit to using a service like IRCCloud.
However, it's worth noting that an important aspect of the IRCv3 effort is around introducing new data types to the protocol. Things like message tags and metadata, that will enable client developers to offer new features that would be hard or impossible to implement without breaking a lot of the existing ecosystem around IRC. And it's the existing open communities on IRC that represent a major advantage over closed proprietary chat systems.
Some examples of things that could be achieved with these new data types and mechanisms:
* If you wanted to add avatars, there isn't a standard place to put it that all clients will know how to access. A metadata key enables that.
* A bot that supports some form of rich payload, e.g. a quoted snippet from a linked website, with a favicon and preview image. You could provide this with message tags.
There are also interesting opportunities with the -notify capabilities. Being able to receive status updates (e.g. if someone goes away or identifies) lets clients present useful presence indicators for people you're chatting with.
I can imagine these being combined in interesting ways. For example, label a message with an id tag and then receive fave-notify messages for it, to allow a "starring" feature.
For IRC to be a competitor to modern chat alternatives it needs a combination of these improved protocol features as well as a support infrastructure.
Well, I think the argument is to increase the number of people who do use IRC - I'd say that Slack has proved people want features like that. If existing IRC users don't want to use the features, they don't have to.
why wouldn't they be? svgalib and directfb allow irssi to display avatars in full color. You could use libcaca to reduce them down to ascii, if needed.
Either way, the point of an extension is that it degrades gracefully if the extension is not supported. Users that can see avatars get to see avatars. the ones that don't care don't lose the rest of the experience.
>why wouldn't they be? svgalib and directfb allow irssi to display avatars in full color. You could use libcaca to reduce them down to ascii, if needed.
Yes for both of the people running irssi in a framebuffer console, libcaca would obviously need ridiculously large avatars.
>Either way, the point of an extension is that it degrades gracefully if the extension is not supported. Users that can see avatars get to see avatars. the ones that don't care don't lose the rest of the experience.
Yeah, but the ones that do don't see any avatars either, because they're the only ones that support it.
Beyond things like ACTION, CTCP is not widely or consistently supported. This is partly because no one is advancing the specification, and partly because it isn't well specified in the first place. Not to mention the syntactic issues with hacking the payload into IRC's 512 byte limit using invisible meta characters. Metadata and message tags (which support an extra 512 bytes of data) are much more suited to this sort of feature, are better specified, and have more backing from client developers.
If the interests would have aligned better, Google Wave could have been this. A better protocol that allows mixing of synchronous and asynchronous communication. It's so sad that opportunity wasnt used with more passion and adopted by a larger ecosystem of players.
are you guys ever going to have a stable service? i've been on the verge of dumping irccloud multiple times because of the extremely frequent "ddos" attacks that make your service unusable for hours at a time, despite every other IRC client still working just fine with Freenode.
I think that at least some of the point of IRCcloud is that you shouldn't need to set up e.g. a bouncer, possibly on a VPS, just to get reliable group chat.
IRCCloud will be happy to support this as a client in due course. We also run our own custom IRCd for teams, which gives us a nice testing ground for implementing new bits of the server spec.
I think IRC won't support offline messages as it somehow conflicts with the whole protocol. You can achieve this with your own setup via ZNC, but then you need a server running 24x7.
IRC will hopefully stay as the preferred option for technical discussions, but we will need something else for personal communication (with increased privacy too).
We have XMPP, which is complex, lacking and has too much client fragmentation. And emerging things such as Signal, Tox, Ring or Matrix.
It's a challenge to implement offline messages and P2P. Even server federation is not easy if you want really nice crypto. E.g., see Signal.
Perhaps I configured it wrongly but when I forget to close my IRC client at work then ZNC is not buffering and showing me anything on the other clients when I log in.
Yep, you would have to change the settings a bit if you want that behaviour.
Connect to your ZNC’s web frontend, and then go to:
ZNC » webadmin » Edit User [the name of the user you’re editing] » Edit Network [the name of the network you’re editing]
Then checkmark the following:
• awaystore¹ (Adds auto-away with logging, useful when you use ZNC from different locations)
• simple_away² (This module will automatically set you away on IRC while you are disconnected from the bouncer.) [You probably already have this checked]
I really wish IRC and other open protocols had a chance against Slack and the entire walled-garden ecosystem. Personally I'm highly willing to do some extra-setup in order to at least own the history of all my messages (not to mention the ridiculousness of separate Slack groups requiring separate logins) - of course this is a developers take, which excludes all the other employees..
Ultimately the Out-of-the-box some setup required has in as much doomed IRC as desktop Linux. The obvious problem being that the people that are interested in working on these things for free are nerds who are okay with the setup -- which just perpetuates a closed-cycle.
We are providing an option to bring together walled gardens with matrix.org: an open standard for federated distributed and persistent communications. It does give you the option to run your own server and bridge to other services like IRC (and Slack actually).
We're also building Vector.im as a glossy client on top of Matrix to precisely address the fact that non techy users need something easy to use.
So all this might answer your concern :)
SASL is a protocol that allows you to mix several different schemes. You could (if the server supports it) use GSSAPI (e.g., authenticate using Kerberos or Active Directory, i.e., the backend for enterprises). You could instead use, say, EAP. Or you could use OAuth 2. Or you could use SSL certificates. Or you could forgo any of that and just use CRAM-MD5 or SCRAM-SHA-1 or SCRAM-SHA-256 for regular password authentication. Or, if you're really lazy, you could just use a plaintext user/password combination.
User and password management? With client X.509 certificates it's difficult,
e.g. issuing them is not fun. Moving them around is more troublesome than with
a login+password pair, too.
Also, try explaining client certificates to non-technical people, who probably
are among the target audience of IRCv3 initiative.
First time heard of irccloud today and I was interested since I've been running cheap-o VPS server mainly for irssi for past few years and this seemed like good alternative, but with quick testing this isn't a solid product.
First problem I had is the same as every single cloud platform for stuff we have on desktop already (like cloud IDEs) why can't I customize things? Why can't I do simple stuff like hide my channel list/tree? I saw someone asked this feature via Twitter 2 years ago and Irccloud account replied "request accepted" or something and still nothing.
Second more serious issue is chat history. It simply doesn't transfer from one device to next. If I have it open in one machine and open it on another the last instance will lose ALL latest chat history (in my testing at lest 30 minutes worth). This to me breaks the whole concept, you have no product. Whole point of this service is to provide easy access to the same IRC instance from anywhere, but if there is no chat history/log it doesn't provide that, it would be the same if I just joined with another client which I can do for free from multitude of different web based IRC clients.
It's cool that you try to improve IRC, but first you really should probably get your product in working order.
The issue of the missing chat history is actually a rare bug we have at the moment combined with bad timing.
When we're under heavy load (e.g. Freenode is netsplitting) our cache can get backed up. The cache is where your logs are served from when you reconnect a client.
At the moment we don't do a good job of detecting a slow cache and re-requesting from the primary log storage, but we're working on a fix for that, as well as improving cache performance so it doesn't get backed up as much.
It just so happened that there was a large split on Freenode earlier today, around the time you posted this message.
It's not that "rare" if my buddy was able to replicate it just by opening irccloud in a browser on another computer. So is it rare that it happens, but when it happens it happens to everyone in one network?
Your systems have to be seriously fucked up if freenode netsplitting causes "heavy load" this is super easy to parse text data we're talking about.
Edit: 4 downvotes but nobody interested in explaining why it makes sense for freenode netsplits to break the entirety of irccloud (which they do, regularly).
>My guess is you're being downvoted for profanity and negativity, nothing about technical explanations.
The negativity is very well deserved, shit code is shit code.
IRCCloud is a service with less than 200k registered users (being optimistic here, realistically the number is closer to 143578) out of which maybe 10% are active (that's being super optimistic too) so that brings us to about 20k users.
With ~20k connected users the service can barely manage to remain operational when any of the bigger networks experience netsplits, which happens all the time. IRC networks are constantly getting DDoSd.
If their service can't even deal with normal everyday load, that's a sign of serious issues.
The only conclusion is that IRCCloud must be very badly implemented and suffers from serious technical deficiencies, I believe "fucked up" is appropriate here.
This isn't a daycare, if someone finds "fuck" offensive they should probably just pull out their ethernet cord.
It's not about the word itself. It's that people here can express their opinions in better ways typically. Every service has bugs. This is one of theirs. Whatever software project you create will have bugs. That's the world we live in.
"fucked up" blames the developers - did you really intend to say they fucked up, by providing a non-critical service that's very usable almost all the time and has cache coherency issues occasionally. Missing chat history is not a serious technical deficiency if it can be simply re-requested. If you really wanted to rant at them and say their service is fucked up, then downvotes are deserved.
>"fucked up" blames the developers - did you really intend to say they fucked up, by providing a non-critical service that's very usable almost all the time and has cache coherency issues occasionally. Missing chat history is not a serious technical deficiency if it can be simply re-requested. If you really wanted to rant at them and say their service is fucked up, then downvotes are deserved.
I'm guessing you don't use IRCCloud very much then?
It's not just cache coherency issues, IRCCloud slows to a crawl/stops working entirely when there's bigger splits.
And when are the developers not to blame? If you write code that doesn't work it tends to be your fault that it doesn't work, unless of course management forced you to write bad code.
>If you really wanted to rant at them and say their service is fucked up, then downvotes are deserved
No, I'm just annoyed by how he completely sidestepped the actual underlying issues, e.g their service being unable to support their current user counts.
As a web app, it's actually a lot easier to make modifications than desktop software, without needing an unwieldy encyclopaedia of settings checkboxes.
For things that are common requests, we work on adding appropriate settings, but it's impossible to give everyone exactly what they want, so custom user stylesheets and scripts are generally the answer.
Loading more backlog doesn't seem to be doing anything, maybe if there is no new messages? But at least it doesn't populate missing messages in the between.
And what is the point of having to download and extract logs from a zip file? That's not good UX. My friends and I are completely baffled that this MOST basic feature doesn't work as expect.
Here is how it should work: I log in at home and I get full history of the channel (or as much as they keep, but at least last 24 hours), so I can see what's been going on. Then I leave for work (I leave my client open at home) and during commute I might popin and see what is going on, again I should get full history regardless what has happened while I was gone (or if nothing had happened). Then I get to work and again I should get full history of all messages and all these clients should get updated history whenever there are new messages.
> Here is how it should work: I log in at home and I get full history of the channel (or as much as they keep, but at least last 24 hours), so I can see what's been going on. Then I leave for work (I leave my client open at home) and during commute I might popin and see what is going on, again I should get full history regardless what has happened while I was gone (or if nothing had happened). Then I get to work and again I should get full history of all messages and all these clients should get updated history whenever there are new messages.
I use IRCCloud every day and this is exactly how it works. History is shared between devices and is still collected even when you're not online. I'm not sure why it wasn't working for you.
Only thing I can think of is that they track your IP and won't send the history if you have two instances from the same IP address. But I don't quite get why they would do that.
But we'll see, I'm willing to give it the 7 day trial and see if it's workable. There also seems to be python lib for it, so if the chat history works itself out I could write my own cli/gui solution and get rid of the channel list/tree thing
>Only thing I can think of is that they track your IP and won't send the history if you have two instances from the same IP address. But I don't quite get why they would do that.
That is not the case.there is something funny going on with his/her client.
I use ircloud for past 6 month and it is excellent.I always use it from home which is basically a one ip address shared between 4,5 device.and I always can load my message from different devices.
Just now I tried to connect with my phone (iOS) and I can get to the channel, but I can not see anything that happened since last evening (when I first tested the app out). I can see the log before (15:30 on Sunday), but nothing from then on (I moved to desktop) until now (7:45 on Monday morning). Thats over 12 hours of missing logs and I can't find a button that would load more logs and swiping directions doesn't load either. I can't check on browser because for some reason (I'm guessing corporate proxy) the site doesn't load, but I'm not really holding my breath.
So far this product doesn't really provide me any value over free solutions on the go and at home/work changing between machines just ssh-ing to my ircbox and attaching to irssi session seems more reliable.
I'm so confused as to whether Mozilla Thunderbird utilizes ChatZilla itself as the irc backend or if the developers simply re-wrote irc support from the ground up...
ChatZilla is by far my favorite client and I would love if it could support new IRCv3 features.
IRC is kind of an IETF standard. That is, there are RFCs for the IRC protocol that are a useful introduction, but they don't cover basic user-visible things like `/me` or formatting codes (colour/bold/etc), and even the non-IETF specs that cover those things aren't necessarily reliable (the CTCP spec has a whole thing about how to encode metacharacters in payloads that in practice everybody ignores).
At least these IRCv3 guys are writing down what they're doing.
There are unofficial extensions, yeah, but that doesn't make IRC not be standard. I think it just needs to happen that someone gets the various extensions finally standardised.
There is an effort[1] to unify these changes alongside a revised IRC spec that reflects real world implementations and improves upon the existing RFCs, but it's a longer term plan and still a work in progress.
IRCv3 is a working group consisting of many different IRC developers and operators http://ircv3.net/participation.html that produces specifications by consensus, and there is a longer term effort to propose a unified RFC that improves upon 2812/1459.
IRCCloud as a company is an active member of the working group. I'm not sure how we would be co-opting any standard, but we implement them, and yes, we do sell a service.
It's closed in the sense that we provide a proprietary API on top of IRC and you need to sign up to our service to enjoy any benefit from it. But it's open in the sense that you can connect to any open IRC server, and if you choose to no longer use our service, you can download your logs, pick up any other client and continue to use IRC without having to recreate your community from scratch.
How suspicious you should be of all the above is entirely up to you.
On one hand, anything that can run on top of an encrypted connection "supports encryption". IRC is no exception, IRC servers have had SSL support for a long time now.
However, the messages you send over the SSL connection will arrive in plaintext form at clients who chose not to use SSL when connecting to that server. Logs are also stored plaintext by many clients.
There are servers which no longer allow non-SSL connections to cope with that.
Edit: this debate is pretty long-winded, it was a pretty hot topic in a lot of circles even 10 years ago. I've heard proposals of adding encryption on top of IRC. The advantage being that even peers over unencrypted connections would still get encrypted data. I vaguely remember toying with some perl scripts for doing that over irssi.
It's pretty pointless IMHO. People rely on IRC logs, and IRC in general has largely been for open forums and open collaboration.
If someone needs to discuss sensible stuff over IRC, it's fair to assume that they don't want it discussed with anyone who happens to join their channel. In that case, it's perfectly acceptable to set up an SSL-only server with strong authentication (or even better, to ensure that you don't leak logs, to have everyone connect over SSH to a machine that runs a local-only IRC server).
It's also worth noting that many clients now have LibOTR (Off The Record - end-to-end encryption) plugins available.
For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc).
> For group chat, the best option seems to be a TLS only server and an agreement with all parties to avoid publishing logs on sensitive channels. Whatever technical measures or protocols are in place, you always rely on your correspondents' cooperation (no logging, no bots, only use secure terminals, etc).
Exactly, at the end of the day you're still depending on people not to leak these things anyway.
This is the thing that's gets me about encryption on public communication platforms. On the one hand, I do want my authentication to be secured, but as much as we might discuss securing chat, it's all posted in the public anyway. It's like standing on a street corner and shouting your personal details and hoping that's every stranger adheres to the implied NDA.
At the end of the day, as long as your authentication is secured, then that keeps your password safe. The fact that your communication to the server is also secured is a bonus as it means that any eavesdroppers can't tell which user your are not even which channels you hang out on. But anything more than that is just pointless given you can't trust all clients to be secure.
I'm not entirely sure this is a problem that can be solved in any way either. If the text can be read, then it can be ripped and logged. Much like the Snapchat problem and how ineffective DRM is at stopping piracy. (OK, not exactly the same, but definitely some overlap)
Encryption isn't just about keeping secrets. When correctly deployed it also prevents tampering; when your comms are insecure, it's quite easy for a MITM to inject or remove content.
This is not hypothetical, although most of the large-scale attacks of this nature have focused on the web. What sort of havoc can someone cause in your organization by injecting fake chat messages? :-)
Indeed. However my point wasn't that we shouldn't have TLS connection to the server, but rather than end-to-end encryption (ie client to client) doesn't make a whole lot of sense on public channels since the comms are public.
That argument is made in the context of IRC networks, where the same server can have clients over both encrypted and unencrypted connections. If your own connection is encrypted, an eavesdropper listening at your router's exit can't see what you're typing. However, clients over unencrypted connections will get your message -- unencrypted! -- so an eavesdropper can just as well listen there, and he'll get your messages. He won't get your password, but will get your data.
The argument holds for every similar system. E.g. TLS connections to a SMTP server mean that an eavesdropper won't see what you're asking the SMTP server to send, but if that server then relays your message over an unencrypted connection, all that TLS mumbo-jumbo won't help a bit, because the server just published your data in plain sight. Your password is safe, sure, but your data is in plain view, so if someone wants to spy on you, they don't even need your password anymore.
So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections.
Some ircd's implement channel mode +z which only lets SSL clients join.
> So if you're sending plaintext data over an encrypted connection, you are trusting that the server won't reveal that data by relaying it over other unencrypted connections.
Yes I'm saying that if you have confidential conversations you need to trust everyone to not publish the logs (and use SSL/set +z). No matter how good the crypto is.
It's a case for having end to end crypto in IRC if anything.
That's the problem though, you simply cannot trust other clients. If you need end-to-end encryption then you need secure clients as well, otherwise an attacker could:
1) just hack the PC and read the logs straight from the file system / messages from RAM
2) impersonate a trusted user (since clients don't send fingerprints beyond the basic ident information)
3) and there's no guarantee that even if the client is connected to the server via SSL (eg set +z on the channel) or end-to-end encryption is builtin, that the "client" still isn't anything more than an IRC bounce (eg ZNC) that users primarily connect to via clear text.
So while I'm all in favour of encrypting IRC comms, the other links in the chain are so weak that pragmatically end-to-end encryption wouldn't offer you any significant privacy guarantees. So as much as I do love IRC, I honestly don't think it makes practical sense trying to leverage it as a secure platform for confidential conversations. There's better mediums for that; just as IRC excels in other areas where many other communication platforms fall short (eg openness, protocol simplicity, automation via IRC bots, etc).
> And even if all these things were solved, you'd still trust the others to not publish the logs.
But those things aren't solved. That's my point. The fundamental design of IRC makes these points hard to solve; and even if you did set out to solve them, you'd ultimately end up with a new protocol that was originally based on IRC but now not compatible with it. So it wouldn't be IRC any longer.
IRC is about open chat and it does that very well. There's better protocols for sharing sensitive information. I just don't get this modern obsession with shoehorning features into every piece of software or protocol and expecting everything to work perfectly. Even with chat protocols, there's a multitude of different paradigms - many of which aren't necessarily compatible with others. Why can't we just concentrate on making secure communication platforms better instead of bastardising an open platform to behave like a crappier implementation of a secure platform?
> It's not a case against crypto. You're actually proving my point.
That makes no logical sense. Crypto wouldn't solve the issues I raised and you've completely glossed over the part why I say privacy is only as good as the weakest link.
It's easy to argue about how to harden IRC from snoopers, but a great deal harder to actually fix those problems in practice since you only need one weak link in the design of the platform and the whole security model falls flat on it's face. Simply put: in terms of privacy there are far too many weak links in IRC. It just not a good protocol for secure conversations. And frankly I think it's best left that way as changing IRC to be secure would detract it from what makes IRC so great to begin with. eg it's openness, hack-ability and so forth.
Honestly, I think you're chasing an impossible vision. Sure, in an ideal world you could fix all those issues, but then it wouldn't be IRC any longer since you've now broken support for ZNC, bots, and so on.
[2] There are lots of plugins that add mircryption compatibile encryption to IRC clients on all platforms, e.g. for modern mIRC there's FiSH 10 https://github.com/flakes/mirc_fish_10
>However, the messages you send over the SSL connection will arrive in plaintext form at clients who chose not to use SSL when connecting to that server. Logs are also stored plaintext by many clients.
On most sane servers you can enforce SSL with channel flags and usermodes.
TLS (to the server encryption) is supported, if the server supports it. There are plugins for most IRC clients to do OTR (which is end-to-end, future-secret and reputable (meaning that the receiver can't prove to anyone other than themselves that you sent it) encryption).
kinda. If one thinks that SSL is secure (with CA's like Commodo existing), and that broken encryption is still encryption, then yes. IRC supports encryption.
To clarify, the changes detailed here are to do with IRC as a low level protocol. While these enhancements do have user benefit, many of the user experience improvements we work on aren't necessarily at the protocol level.
For instance, things like file sharing, persistent logging, synced mobile clients, push notifications etc can all be built as extra infrastructure on top of the protocol. In the same way that the Slack protocol doesn't give you file sharing without somewhere to host hose files, IRC as a protocol is less useful without services built around it. And that's the main benefit to using a service like IRCCloud.
However, it's worth noting that an important aspect of the IRCv3 effort is around introducing new data types to the protocol. Things like message tags and metadata, that will enable client developers to offer new features that would be hard or impossible to implement without breaking a lot of the existing ecosystem around IRC. And it's the existing open communities on IRC that represent a major advantage over closed proprietary chat systems.
Some examples of things that could be achieved with these new data types and mechanisms:
* If you wanted to add avatars, there isn't a standard place to put it that all clients will know how to access. A metadata key enables that.
* A bot that supports some form of rich payload, e.g. a quoted snippet from a linked website, with a favicon and preview image. You could provide this with message tags.
There are also interesting opportunities with the -notify capabilities. Being able to receive status updates (e.g. if someone goes away or identifies) lets clients present useful presence indicators for people you're chatting with.
I can imagine these being combined in interesting ways. For example, label a message with an id tag and then receive fave-notify messages for it, to allow a "starring" feature.
For IRC to be a competitor to modern chat alternatives it needs a combination of these improved protocol features as well as a support infrastructure.