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.
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.
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.
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.
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.
I didn't make the decision. Slack started to appear and I didn't know that IRCCloud had apps (which seem to have great reviews). If I had known, I would have suggested it as an alternative. As it was, I just kept quiet as Slack seemed great - even better than HipChat, which I used to use for the same purpose.
Perhaps IRCCloud could be sold as a rebranded Enterprise app as an alternative to Slack? I'd love to see some competition as it looks like only HipChat and Slack are getting talked about.
* Front end engineering (on site or remote)
* Design (on site)
---------
IRCCloud is an IRC client and bouncer without all the baggage.
We keep you connected all the time. Stay in sync and get notified wherever you are with our web and mobile apps.
We also host private IRC servers for teams and have a self-hosted version for enterprise.
Plus, upload code snippets and files (soon!), search your logs (soon!), and images, videos, tweets embedded inline
--------
FRONT END ENGINEERING
IRCCloud is a long running rich web application with real time performance needs. If you're up for the challenge of making a website feel like a desktop app and have deep experience with the following then email your CV to jobs@irccloud.com
IRC has a reputation as a chat tool for hackers, and a long history to go with it, but it's not always been associated with brilliant design. We've set out to fix that by giving IRC a beautiful and intuitive home on the web and mobile devices.
Our focus is on functional elegance, clarity, and making complex things obvious. And it's time to step it up a notch. We're looking for someone to help us make IRC more appealing to those who've never used it to collaborate before, while still making sure the old hands feel at home.
We need to respect the IRC community, and the limitations of the medium, while making bold decisions that question the conventions of the last 25 years. We're not building something completely new, trendy, and unproven. IRC is still thriving for a reason, and you'll be responsible for better aligning it with the way people communicate online today.
Ideally, you'll have several years of experience designing for the web and mobile, with a strong graphic design background. A working knowledge of HTML/CSS for in-browser prototyping would be a significant bonus.
Email a portfolio and CV to jobs@irccloud.com to apply
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.