IRCv3
blog.irccloud.com
blog.irccloud.com
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.
I hope that someday there's something similar for asynchronous group communication as well as synchronous. Something like Usenet v2.
jwheare2 keeps talking about the existing irc ecosystem and communities, but I really doubt any of the big ones would be switching over.
The spec may be, but I doubt any of the examples you gave would ever be compatible with irssi & co.
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.
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.
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.
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.
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.
instead one currently needs to shell into their ZNC box and start grepping through logs, not pleasant
(there is a backlog module, however it required a bit of silly configuration and didn't support getting anything other than chat lines)
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]
(This is assuming you’re on ZNC 1.6.1 like me).
――――――
[1] https://github.com/silc [2] http://silcnet.org/info.html
Anybody else use screen and emacs erc on a vps for irc? One thing I dont like doing is connecting directly to irc. Also, don't forget about cloaking!
What is the advantage of using SASL over logging in with a client SSL certificate?
Also, try explaining client certificates to non-technical people, who probably are among the target audience of IRCv3 initiative.
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.
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.
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.
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
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.
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.
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.
Check out https://userstyles.org/styles/browse/irccloud for some examples, have a look on our wiki: https://github.com/irccloud/irccloud-tools/wiki or join our #themes channel on irc.irccloud.com for info and help on customising the ui.
Often, the best community extensions get integrated into the app, but we're still a small team so it can take time :)
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.
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).
Try rephrasing your question in a way that the parent is more likely to respond to.
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.
"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.
At least these IRCv3 guys are writing down what they're doing.
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).
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.
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)
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.
> 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.
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).
It's not a case against crypto. You're actually proving my point.
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.
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? :-)
[1] http://www.donationcoder.com/Software/Mouser/mircryption/
[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
On most sane servers you can enforce SSL with channel flags and usermodes.