IRC.com outlines its roadmap(irc.com)
irc.com
IRC.com outlines its roadmap
https://www.irc.com/
6 comments
Full disclosure: i'm being paid to work on InspIRCd for use on the IRC.com network. This is my personal opinion not an official statement on behalf of my employer.
The IRC server software used by Snoonet, InspIRCd, does not contain any functionality for message interception (it doesn't even tell server operators the contents of a message that has matched a spam filter) and at least on the infrastructure I have access to Snoonet does not have any message interception capability either.
The IRC server software used by Snoonet, InspIRCd, does not contain any functionality for message interception (it doesn't even tell server operators the contents of a message that has matched a spam filter) and at least on the infrastructure I have access to Snoonet does not have any message interception capability either.
As an InspIRCd developer you must also be aware that it only takes minutes for anyone to patch an IRC daemon to log chats. I don't think the lack of such a feature in core inspircd indicates anything.
Whilst that is true as I have explicitly stated there is no intercept capability on the infrastructure that I have access to. If you're willing to believe some completely unverifiable logs dumped on a paste site over someone with access to IRC.com infrastructure then i'm not really sure what I can say to convince you otherwise.
You can use OTR for private IRC chats and an IRCv3 contributor is currently working on an end-to-end encryption system suitable for use in IRC channels so if you're concerned about your privacy you are welcome to use those.
You can use OTR for private IRC chats and an IRCv3 contributor is currently working on an end-to-end encryption system suitable for use in IRC channels so if you're concerned about your privacy you are welcome to use those.
That's pretty damning. Glad I never went to Snoonet. Something seemed off about the network as a whole, and it appears that my assumptions were correct...
"Oh and PIAs support site and customer DB were compromised using a deserialization vulnerability in kayako."
Can you please detail when this was? I would assume based on your example in December 2016, however PIA Support wasn't using Kayako in December 2016. For clarity, I run PIA Support and one of the first things I did when I joined the company was replace Kayako.
Can you please detail when this was? I would assume based on your example in December 2016, however PIA Support wasn't using Kayako in December 2016. For clarity, I run PIA Support and one of the first things I did when I joined the company was replace Kayako.
That cookie isn’t from PIA. It was a random example of the really obviously vulnerable fusion cookies I pulled by googling the cookie name.
Looking at some file timestamps on my laptop, I guess this was around feb or april 2015?
Looking at some file timestamps on my laptop, I guess this was around feb or april 2015?
Even if you removed every other part of this comment, Mark Karpeles as CTO is more than enough by itself to stay very far away from this. Might as well hire Bernie Madoff as CFO of your new investment startup.
As the CEO of IRC.com, I can say that Mark Karpeles has nothing to do with the project nor does he have access to any of the infrastructure IRC.com runs on. His work goes towards other projects that London Trust Media has running.
I’ve been running the open source kiwiirc.com project for around 7 years and have always been very careful of who has access to what and so far has been clear of any issues. Hopefully I can now bring the same scrutiny and planning to IRC.com too!
I’ve been running the open source kiwiirc.com project for around 7 years and have always been very careful of who has access to what and so far has been clear of any issues. Hopefully I can now bring the same scrutiny and planning to IRC.com too!
Thanks for the information. I guess I just don't see how he's employable at all after what happened (even if you assume he had no malicious intent, which is still pretty unknown).
I use kiwiirc.com regularly and love it, by the way. Great work.
I use kiwiirc.com regularly and love it, by the way. Great work.
[deleted]
What's the "IRC Foundation"? As a long-time IRC user, this sounds like a scam after reading through the the 'article', I don't know what exactly they are doing besides throwing all the buzzwords and trendy web design out there.
On the other hand, I want to give the benefit of the doubt that they are somehow improving the IRC protocol in some meaningful way.
On the other hand, I want to give the benefit of the doubt that they are somehow improving the IRC protocol in some meaningful way.
For the most part, the Foundation's just a project to support existing projects and developers who use the IRC protocol. This can mean providing financial support, access to more business-oriented resources like designers/legal/etc, as well as simply improving the quality of protocol documentation out there (the part I'm handling).
In terms of strict protocol improvements, the IRCv3 WG is the real place where that's going on, the most authoritative thing in terms of introducing new stuff across the IRC infrastructure these days: https://ircv3.net/
But, for new developers looking to get into IRC today, the resources aren't as available as they could be. Sure, there's a bunch of code to look at, libraries you can use to get started that seem to work fine. But when you wanna start digging into the wire protocol, how particular commands or functions work, how to actually approach writing a client/server from scratch, all you have are either the RFCs, some newer resources like the ircdocs/IRCv3, or stuff spread across 20+ year-old textfiles and pages all across the net. My intention for the documentation side of the Foundation is to build up information on how to use/parse commands and numerics, how widely they're used (in terms of software support), and how to really dig into and approach development with the protocol – since that feels like the more valuable information to be out there right now for new devs. It'll be linked to and public sometime soon, it's just that building up a swathe of documentation large enough to show we're serious about it takes some time (if you want those docs to be decent-quality, at least).
For what it's worth, I'm both the primary writer/maintainer of the Foundation's developer docs work, and the maintainer of the more community effort https://ircdocs.horse/ , so hopefully I'm on the right track with supporting devs in the protocol documentation sense.
If there's any questions or suggestions for directions to take on this (stuff that you, as a dev, would find useful for writing IRC software), please let me know! Even if it's not there for initial launch there's a fair backlog of stuff I'm looking to make up with this project.
In terms of strict protocol improvements, the IRCv3 WG is the real place where that's going on, the most authoritative thing in terms of introducing new stuff across the IRC infrastructure these days: https://ircv3.net/
But, for new developers looking to get into IRC today, the resources aren't as available as they could be. Sure, there's a bunch of code to look at, libraries you can use to get started that seem to work fine. But when you wanna start digging into the wire protocol, how particular commands or functions work, how to actually approach writing a client/server from scratch, all you have are either the RFCs, some newer resources like the ircdocs/IRCv3, or stuff spread across 20+ year-old textfiles and pages all across the net. My intention for the documentation side of the Foundation is to build up information on how to use/parse commands and numerics, how widely they're used (in terms of software support), and how to really dig into and approach development with the protocol – since that feels like the more valuable information to be out there right now for new devs. It'll be linked to and public sometime soon, it's just that building up a swathe of documentation large enough to show we're serious about it takes some time (if you want those docs to be decent-quality, at least).
For what it's worth, I'm both the primary writer/maintainer of the Foundation's developer docs work, and the maintainer of the more community effort https://ircdocs.horse/ , so hopefully I'm on the right track with supporting devs in the protocol documentation sense.
If there's any questions or suggestions for directions to take on this (stuff that you, as a dev, would find useful for writing IRC software), please let me know! Even if it's not there for initial launch there's a fair backlog of stuff I'm looking to make up with this project.
The IRC Foundation, as it says on the linked page, doesn't exist yet. That's a goal of irc.com to do.
irc.com is a domain purchased by Andrew Lee of Private Internet Access last year. Formerly, irc.com had a letter written from him about his goals hosted on it:
https://web.archive.org/web/20180622180151/https://irc.com/
irc.com is a domain purchased by Andrew Lee of Private Internet Access last year. Formerly, irc.com had a letter written from him about his goals hosted on it:
https://web.archive.org/web/20180622180151/https://irc.com/
The letter is still on the site, click on "Let's take IRC further" in the upper right corner.
At the bottom of the page opening there is a link to "London Trust Media Holdings":
Some of the brands listed:
* Private Internet Access
* Linux Journal
* freenode
* snoonet
and others
At the bottom of the page opening there is a link to "London Trust Media Holdings":
Some of the brands listed:
* Private Internet Access
* Linux Journal
* freenode
* snoonet
and others
Went there to check if Twitch was listed. Twitch chat runs on IRC, or at least can be connected to with an IRC client - are they involved with the ecosystem?
Twitch have their own custom IRC servers and not part of IRC.com/London trust media. They have been watching out on the IRCv3 group to ensure they implement IRC correctly though in the past.
Ah! Thanks for the additional info. I found the current site to be hard to parse for someone who has never heard of this foundation.
IRC is, and always was a walled garden. yes, IRC servers can be distributed, but they can't be federated. IRC hails from a time of the internet when it was so small that everyone pretty much could trust everyone else. someone who controls one IRC server is more or less able to control the entire network.
if there are IRC servers that can't be trusted, they can't join the network, and hence will form a network of their own. there are dozens of networks out there (hundreds if you include smaller ones), and each one is an island. if i am on a different IRC network than you, then we can not talk to each other.
the only worthwhile improvement of IRC would be to turn it into a federated protocol to rival XMPP or other alternatives. i am not sure that is even possible though, but i wish it is, and i wish that this is where irc.com will be going.
i do look forward to see IRC brought into the modern age.
if there are IRC servers that can't be trusted, they can't join the network, and hence will form a network of their own. there are dozens of networks out there (hundreds if you include smaller ones), and each one is an island. if i am on a different IRC network than you, then we can not talk to each other.
the only worthwhile improvement of IRC would be to turn it into a federated protocol to rival XMPP or other alternatives. i am not sure that is even possible though, but i wish it is, and i wish that this is where irc.com will be going.
i do look forward to see IRC brought into the modern age.
I don't think it can be. Everything irc does is better done centralized. The big problem is leaking of user iP's. Ip's regardless of how they work technically are treated by police and courts as a unique identifier. As sad as it may be, Discord thrives far more than IRC ever did for that very good reason. All content has to be proxied, and that costs big bucks.
One way around it would be to stick to embedding of content only from a small number of known sites, but even then things like YouTube can still show geography of viewers iirc. Plus if those sites get tired of your bandwidth they can just block you, no negotiation of money if you don't have big bucks.
But regardless of how it's done, when you host your own actual server, you're now liable. You're identifiable, and In the U.S. identity is all that's required for any civil case, which could be thrown at you by anyone for any reason. When you host yourself you're taking on legal liability for your users, too, such as underage users that get access to pornography through it.
One way around it would be to stick to embedding of content only from a small number of known sites, but even then things like YouTube can still show geography of viewers iirc. Plus if those sites get tired of your bandwidth they can just block you, no negotiation of money if you don't have big bucks.
But regardless of how it's done, when you host your own actual server, you're now liable. You're identifiable, and In the U.S. identity is all that's required for any civil case, which could be thrown at you by anyone for any reason. When you host yourself you're taking on legal liability for your users, too, such as underage users that get access to pornography through it.
I think the best approach to the issue of IRC not being federated is to create a separate protocol that can not only do that, but also learn from the mistakes of IRC. By design IRC is not very extensible, and because of the initial limitations of the protocol and the divided opinions on what IRC should be, we have each software vendor proposing different standards and clients that have to support all of these differences. While IRCv3 is making efforts to standardise everything, there are still very large networks that will never switch from the old-style IRC and we still have that backwards-compatibility kludge in our way when we try to build modern clients. Creating a new, modern protocol from scratch hopefully allows us not to repeat these issues and have some foresight about extensibility, elegance, and standardisation.
And before anyone proposes Matrix to fill in that blank, I do not believe that it is at all suitable for the goals it is trying to accomplish.
And before anyone proposes Matrix to fill in that blank, I do not believe that it is at all suitable for the goals it is trying to accomplish.
They say they're sponsoring an IRCd, which one it is ? InspIRCd ?
Yes, currently we’re putting full time dev resources into Inspircd to bring it up to date with newer IRCv3 features so that we can showcase what IRC is capable of these days. Once the Foundation has been setup further down the line then we plan to open that up to other projects.
Awesome :)
My current favorite ircd is ngircd. Super easy to install with just an apt-get install away. I usually hide everyones IPs on it cause nobody should just randomly know everybody elses IP. My only issue is making an IP count exception for connection bouncers. I had a server wide bouncer setup for a good number of my users.
As the maintainer of InspIRCd i'm biased towards it but ngircd is a pretty solid piece of software if you only want something which is simple and easy to set up without a bunch of fuss.
I have to look through the source code of other IRC server implementations regularly when checking for cross-server compatibility and looking through ngircd's source code is always a pleasure. Its extremely well written and easy to follow unlike the irc2-based IRC server implementations (UnrealIRCd, etc) which usually are a pain to find out what they're even doing.
I have to look through the source code of other IRC server implementations regularly when checking for cross-server compatibility and looking through ngircd's source code is always a pleasure. Its extremely well written and easy to follow unlike the irc2-based IRC server implementations (UnrealIRCd, etc) which usually are a pain to find out what they're even doing.
Charybdis and ratbox are both installable in that fashion and easy to configure, not to mention they are also more stable, better-programmed, and better optimised for large networks than ngircd. With ngircd it's trivial to cause a netsplit by flooding; also, the dev Alex Barton admitted a while ago to neglecting proper input validation from server-to-server links, claiming servers are "trusted" ... I think after a while he finally agreed that it wasn't best practice and that all incoming data should be considered untrusted and hostile, but the fact that he didn't care at one point speaks volumes for the rest of his code which is probably still unsafe and unidiomatic to a degree. Meanwhile, ratbox and its charybdis successor both practise proactive defensive coding for untrusted input and I have witnessed no crashes with either, and I have been able to modify both their sources with relatively little trouble.
IP spoofing is possible on ratbox and charybdis; host cloaking is possible on charybdis but I would not depend on it. Personally I believe IP addresses are public information, but for those who don't agree with me, it's super easy to spoof hosts. Not to mention, both ratbox and charybdis support alternate I:lines (connection classes) for bouncers and the like.
IP spoofing is possible on ratbox and charybdis; host cloaking is possible on charybdis but I would not depend on it. Personally I believe IP addresses are public information, but for those who don't agree with me, it's super easy to spoof hosts. Not to mention, both ratbox and charybdis support alternate I:lines (connection classes) for bouncers and the like.
Yep ngirc is awesome! It’s so easy to set up a quick server without setting up Anope and all the services separately. The only problem is that I sometimes accidentally restart nginx instead of ngirc because of auto-complete :P
> But we still need to make it much easier for the general public to use. People understand WhatsApp and Messenger, not servers, ports and commands.
Please don't do that. I like the fact the IRC is controllable in plain text via commands. Also, what is wrong with knowing about servers and ports? Why is it that IRC should be changed to appeal to the masses?
Please don't do that. I like the fact the IRC is controllable in plain text via commands. Also, what is wrong with knowing about servers and ports? Why is it that IRC should be changed to appeal to the masses?
Full disclosure: i'm being paid to work on InspIRCd for use on the IRC.com network. This is my personal opinion not an official statement on behalf of my employer.
Everything IRC.com is working on usability-wise is happening on top of the existing protocol. If you're an advanced user you'll be able to connect to the server with your IRC client of choice just like you always have to any other IRC server.
Everything IRC.com is working on usability-wise is happening on top of the existing protocol. If you're an advanced user you'll be able to connect to the server with your IRC client of choice just like you always have to any other IRC server.
Because 99% of the people don’t know what a port is. If they want to rethink the way things work and make the protocol more attractive you have to rethink some assumptions that were maybe correct in the early days.
Nobody is going to stop you from just using the “old” protocols. Maybe it’s even backwards compatible in the way that right now you can also add port 80 to a URL but you don’t have to.
Nobody is going to stop you from just using the “old” protocols. Maybe it’s even backwards compatible in the way that right now you can also add port 80 to a URL but you don’t have to.
And when I was in high school 99% of people didn't know what a disk drive was, much less something fancy at the time like a pen drive.
Now everyone including grandmothers knows what a pen drive is.
And people are using a chat application 99% of the time. Anything they need to know to chat with their friends, they will learn, fast.
IRC did not die because it used ports and servers. That actually had nothing to do with its decline.
IRC was replaced by something without the feudal structure of founders, SOps, and Ops, and the medieval control they had over normal users, muting and kicking people off channels all the time.
It was a social issue, not a technical one.
Now everyone including grandmothers knows what a pen drive is.
And people are using a chat application 99% of the time. Anything they need to know to chat with their friends, they will learn, fast.
IRC did not die because it used ports and servers. That actually had nothing to do with its decline.
IRC was replaced by something without the feudal structure of founders, SOps, and Ops, and the medieval control they had over normal users, muting and kicking people off channels all the time.
It was a social issue, not a technical one.
> Because 99% of the people don’t know what a port is.
And at the rate things are going, that percentage is only going to be going up. We're tunneling more and more over HTTP(S) -- lately, DNS over HTTPS has been unleashed upon humanity --, so ports as a concept are kind of an endangered species at this point.
And at the rate things are going, that percentage is only going to be going up. We're tunneling more and more over HTTP(S) -- lately, DNS over HTTPS has been unleashed upon humanity --, so ports as a concept are kind of an endangered species at this point.
I don't know if I'd trust IRC.com.
[1] https://bpaste.net/show/932b93fc2dce
PIA decided to hire this person AFTER other network staff called him out for spying on users.
Oh and PIAs support site and customer DB were compromised using a deserialization vulnerability in kayako. They never bothered to publicly acknowledge this, clearly a very "privacy oriented" business.
Kayako seems to have taken down their page detailing this particular vulnerability. Their helpdesk product used to store users sessions as serialized objects in user-controlled cookies, allowing attackers to execute arbitrary code by just sticking an appropriate php object into their cookies.
Any automated auditing tool would've immediately discovered this bug, so clearly PIA just didn't bother.
The cookie looked like this, it's impossible to miss the serialized php object:
But hey, maybe their new CTO - Mark Karpeles - runs a tighter ship ;P