Hacker News new | comments | ask | show | jobs | submit login
Using Slack through an IRC client (eduardobautista.com)
53 points by EduardoBautista 7 days ago | hide | past | web | favorite | 95 comments





I can also recommend you to look at: https://github.com/wee-slack/wee-slack

I came here to say this exact same thing.

It has some quirks (like not linking to pictures that are posted in chan, I did try to fix that myself) but generally it's the most full featured cli slack client I've used. You can even upload files.

Highly recommended.


Seeing a lot of comments on the thread to the tune of "just use IRC; I don't use the features that Slack et al offer on top of IRC, so neither should anybody else".

You can have your opinions about Slack, about its apps being rubbish, about it being proprietary, whatever. But imagining that your personal use case, and those of your peers who probably are of a similar technical inclination, should represent the be-all and end-all of real-time online communication for groups is really unhelpful.

Yes, Slack and its ilk aren't perfect, but neither is IRC. What would be really great is if the IRC protocol could evolve to support some of these new features, perhaps with some sort of minimum specification for graphical clients that want to implement these new features — and graceful fallbacks for those that don't and text-based client users.


> Seeing a lot of comments on the thread to the tune of "just use IRC; I don't use the features that Slack et al offer on top of IRC, so neither should anybody else".

Where I work, the argument is reversed:

"just use Slack; I can't deal with some of the limitations of IRC because I'm not willing to, so no one should use IRC."

This effectively happened once Slack discontinued the IRC gateway they provided.


Good news; https://ircv3.net/irc/

Now if only we had millions in VC money to create nice new clients.


I've seen this before. The changes look rather modest as far as the gap between IRC and things like Discord and Slack go.

Isn’t that kind of the point. A conservative approach to adding features so that they can be at least implemented well and understood?

What are the main, real benefits slack has over IRC;

* resilience to network disruption

* onboarding of new users.

* inline media (clients, not protocol, should implement this)

You could argue threads or SIP/VOIP but my admittedly anecdotal evidence suggests that these are seldom used. And, there’s no reason IRC could not expand to relay those.


> A conservative approach to adding features so that they can be at least implemented well and understood?

Well, sure. But while IRC slowly proposes and implements relatively basic features of modern clients, the world will go on without it. That's already happening.

Not that this is a problem for existing IRC users, evidently. But if this is the case, and it's accepted, then it would be great if some HN users would stop trying to pretend that IRC has everything that people want — if that were the case, we'd not have all these alternatives.

> * inline media (clients, not protocol, should implement this)

Which is why part of what I said, and I know you didn't specifically reply to it but I must restate it, is some sort of minimal specification for graphical clients to present the user-facing features that people expect of a modern chat client, voluntarily entered into but with the potential as a great feature to advertise the modernity of a client.

My thinking is that otherwise someone will just make their own Slack knock-off IRC client, bundle it with their own IRCd, and we'll re-enter the IRC wars again. Proprietary IRC with a proprietary client — not that much different from any other proprietary solution other than IRC users reaping none of the benefits.

Going on to the main benefits of Slack, I can't really speak to Slack. However, I'm a Discord user, and I know Discord is inspired of Slack. What I'd like from Discord is:

- persistent session without needing a bouncer, or a simulation of such (e.g. when I connect, show me the last few messages on the server; when I scroll up, keep showing me more)

- an easily customisable role-based permission system rather than the relatively simplistic op/hop/voice, with customisable symbols (as opposed to colours)

- channel categories

- consistent and predictable text formatting, including a subset of Markdown — if I show a code block, I want everybody to see it as a code block (even if all that means is forcing a fixed-width font for a given block of text)

- separating a user's identity from their username, allowing multiple users to use the same nick differentiated by a discriminator

- avatars!

- push notifications!

It's all the little things that add up to a pleasant experience with things like Slack and Discord. I'm sure many will see many of those things as quite separate from an IRC, but these are the things to which people are now accustomed.


Slack is trash because it's bloated. Some people just need text chat and external urls are sufficient for sharing other media.

Slack's implementation is bloated. Yes, _some_ people just need text chat; the problem is when people believe that the same requirements extend to _everyone_.

For those people with the need for text chat, sure, use IRC, go right ahead. But for those who need or are accustomed to more, let's stop pretending that things like Slack or Discord don't have things to offer.

Since the implementation is where the bloat exists, it's a fairly simple fix: make open servers and better clients.


> Since the implementation is where the bloat exists, it's a fairly simple fix: make open servers and better clients.

So when is Slack going to do that? If they were open source, then anyone could do it based on the protocol specification. But since they're not, then it's up to the employees at Slack and they don't seem to be going in that direction.

The gateway solution they had that got around those problems with their clients was discontinued.


I didn't necessarily mean better clients for Slack. I meant in general, which is why I said open servers.

We've got things like Mattermost and Matrix now, we might see others coming forth, and perhaps one day there'll be extensions to IRC to support some of these niceties.

And yes, there'll always be the lovely Slack-like web frontends, and someone will inevitably package those up as native apps with React Native or Electron or whatever. But there's also room for good, high-quality, optimised clients for those platforms as well.


My “mixed reviews” probably have more to do with slack being scatterbrained from a product direction. Look how poorly threading works nearly all of the time, with half of the conversation buried in a thread, the other half leaking out. Another example is how social link previews push the entire conversation up.

I love a lot of the tech work being done at Slack, but a lot of the product doesn’t feel particularly thoughtful.


I never really found threading very useful in a live group chat. Most people would either mention the nick of the person they were responding to, or they would quote part of the text they were responding to and append their response. That's actually a lot easier to follow compared to having to click on a link and have it open in another window panel.

Though I do find it interesting that there are those who want threading in a group chat setting, yet they aren't interested in threaded discussions via email or usenet. Modern email clients/platforms actually use a limited threading model that's known as conversation view (where you only have a single thread of messages rather than a tree view like one sees on this website or reddit).


I agree on quoting. I think my problem is slacks product design isn’t very opinionated. There are many ways of calling back to an earlier conversation, but slack users don’t really have guidance on what they should do. So conversations past a few interactions get hard to connect together, continue, and discover.

Flowdock does a pretty good job of threaded communication. But Flowdock is pretty feature sparse and barely functioning mobile experience.


> Hopefully open standards will improve enough so that people who are not tech savvy are able to use them in the future.

The problem is not standards. The problem is apps.

Jabber has been an open standard for god knows how long. Its standard slowly caught up to the modern world of mobile phones and multiple devices [1]. The apps? Not so much.

One of the appeals of Slack is that you have the same functionality across all your OSes and devices (and there’s quite a lot of functionality).

[1] https://gultsch.de/xmpp_2016.html



Looks interesting but I admit I haven't really used it. Is its goal to ultimately replace IRC?

Not necessarily to replace IRC but to provide a common protocol which can bridge to IRC, Slack, XMPP etc.

Matrix provides free (free as in beer /and/ free as in speech) gateways to Slack and IRC, so you could use it for your purpose here if you wanted.


It rather is a "better XMPP" in my opinion.

I use a Slack plugin [1] for Textual IRC I wrote. It uses SlackKit [2] which needs a bit of work.

[1] https://github.com/rectalogic/TextualSlack [2] https://github.com/SlackKit/SlackKit


Well done! Looking forward to trying it

Or one can use bitlbee, which has been around forever and connects an IRC client to anything that works with libpurple. The full list of what it works with is here: https://wiki.bitlbee.org/

Matterbridge seems interesting as well but I haven't had time to play with it yet. https://github.com/42wim/matterbridge

In view of those more-complete, non-proprietary solutions, you have to be a chump to pay for a Slack IRC bridge.


> you have to be a chump to pay for a Slack IRC bridge

Or part of a network that doesn't want to issue generic API tokens to random users. Since this irccloud is implemented as a specific app integration, if I understand correctly this would be more appealing to administrators and moderators.


I used to stay in contact with a group of friends who now exclusively communicate via slack, until slack eliminated the IRC gateway. Now I've lost contact with that group, it's quite irritating.

Do any of the solutions mentioned here work well on low-bandwidth connections? I'm limited to 128kbps, and slack via web is absolutely unusable.

Open to self-hosted bouncer/proxy solutions, but not interested in involving a third party.


If you have little bandwidth and lots of time (self-hosted anything implies “yes”!) then you could easily check out a copy of SlackKit and write yourself a tiny API client, or checkout any SlackKit-using app that has a sufficiently acceptable feature set. There are lots (see other comments in this post) and there was an ncurses one a while back too, so options abound. SlackKit would no doubt benefit from your time and attention to it as well!

I don't know how much bandwidth wee-slack uses.

You could run weechat+wee-slack in screen or tmux on a server; the ssh or mosh session to that server would be very low bandwidth.


It's a bit of a shame that there isn't a company that offers corporate IRC hosting with a client as rich as the Slack client.

My problem with Slack (and all the Slack clones) is that they all look the same, and have a style that wastes so much screen space. I like to have a small chat window sitting in the corner of my screen that I can glance at and keep track of without having to interrupt my current workflow . IRC clients were great for this; Nice and compact which just the conversation at the fore. So yes, give me UTF-8, Emojis, Reactions, Inline Replies, but all in a more compact UI please.

Well, originally there was a IRC gateway for Slack. But at the end of the day, it just lessens the experience for everyone. I'm all for open protocols in theory, however I'm yet to see it go well since it only works if every platform implements every feature in almost the same way... and at that point, you might as well just use the same client.

Some of the benefits of Slack are things like:

  - the rich integrations
  - emoji responses + emoji statuses
  - video calls that "just work"
  - good search (for stored knowledge across a company)
  - pinned messages
  - notifications people are snoozed and the ability to force a notification
(That being said, https://grove.io attempts to do this!)

> But at the end of the day, it just lessens the experience for everyone.

Pff, speak for yourself. I used the slack IRC gateway until it was shut down as an alternative to just not using slack. Now I use wee-slack, which works great.

To respond point by point:

  - the rich integrations [don't know what you mean]
  - emoji responses + emoji statuses [wee-slack has this]
  - video calls that "just work" [didn't know Slack had this]
  - good search (for stored knowledge across a company) [Slack doesn't have this]
  - pinned messages [not sure what this is good for; are you familiar with IRC's "/topic"?]
  - notifications people are snoozed and the ability to force a notification [IRC's had the former in many forms for years and I don't think the latter is a benefit]

What do you do when people call you?

- good search (for stored knowledge across a company)

Slack's search is absolutely horrible, in my opinion. It's one of the things I complain about.


Because IRC is old and badly designed. People keep talking about IRC but no one want to go back there because it's just bad compare to Slack, there is no history, no rich text, no integration what's so ever to anything recent.

I'm sorry, but Slack is garbage, and those complaints are silly.

Having to search the entire conversation history in the chat window is a terrible idea because it's slow and difficult to use. Having a separate tool or page to search history is a superior solution, and software exists to do that in IRC.

Rich text is over rated, and 99% of messages don't use it anyway. Believe it or not nobody wants to see your silly gif, and they'd be just fine with :-) instead of an emoji.

Integrating with IRC is also trivial because its a standardized open protocol and there are a ton of tools available. It doesn't need a bunch of pre-fab "integrations" because it's not using a dumb proprietary API.

But having an IT guy spend half a day properly setting up an IRC server is hard and it doesn't have a crappy web UI by default, so lets all use Slack.


> Rich text is over rated, and 99% of messages don't use it anyway. Believe it or not nobody wants to see your silly gif, and they'd be just fine with :-) instead of an emoji.

Many people here want to write about code in their chats so at the very least want to have an option for monospacing parts of a message.

You’re being flippant pretending it’s about GIFs rather than a genuine use case.

> using a dumb proprietary API

Why do you need to insult other people’s work like that?


> Many people here want to write about code in their chats so at the very least want to have an option for monospacing parts of a message.

Most IRC clients (I'm thinking of HexChat) let you choose the font, which you can set to a monospace font.


That everyone has to solve these issues independently is a major issue with IRC's UX and why something like Slack can win the mainstream.

Classic example is the rare power-user running irssi on a VPN so that they can receive messages/mentions while offline. The issue is that nobody else does it. Everyone else parts the second they close their laptop and probably won't remember to rejoin until they have another question to ask. You respond to someone and, whoops, they've already left. The whole community suffers.

Obviously it's true: you can bend your client to your will and that's nice. But what HNers typically do next is wonder why everyone doesn't want to do it. Or they criticize everyone else for not seeing the light. Though I'll admit I'm also responding to multiple sibling comments next to yours, not just you.

Whenever IRC comes up, HN always reminds me of The Simpson's Principal Skinner quote: "Am I out of touch? No, it's the [Slack users] who are wrong."


Parts of a message, though.

> Many people here want to write about code in their chats so at the very least want to have an option for monospacing parts of a message.

Fair enough, but I would still argue that if somebody's posting enough code for that to matter, a link to a pastebin or a Github Gist, with syntax highlighting, is a better solution.

> Why do you need to insult other people’s work like that?

Because it's a poor choice to create a proprietary chat protocol because it allows Slack to control what people can say and how they say it.


Creating the proprietary, unstable API protocol was a great choice for Slack given they want to lock-in customers to their paid service. It's just a poor choice for everyone else.

So a business made a user hostile move that happens to also be a good business decision. Why is that laudable? Why is this something worthy of praise? Why do we like this product or company? Why is criticism of this product being downmodded?

None of this is responsive to my comment; I didn't make any of those claims, nor do I control the collective voting of HN users.

> Fair enough, but I would still argue that if somebody's posting enough code for that to matter, a link to a pastebin or a Github Gist, with syntax highlighting, is a better solution.

Be wary of simply justifying why it's not the end of the world when a feature is missing, which is a much different argument. For example, I bet everyone who uses IRC appreciates some sort of indication for when they are mentioned even though they could ctrl-f for their username every once in a while instead.

I'd argue that you don't need to post "enough code" to benefit from monospace or multiline support. A developer channel in IRC is full of one-liners that would be improved by monospace.

Also, as a heavy IRC user, it's pretty painful following code discussion through a bunch of external links.

Compare that to my developer-centric Slack channels like Elm lang's where short code snippets are used heavily and it's easy to see context, it's so much more convenient. And when someone does have enough code, they can use Slack's snippet feature.

But I feel like you can always respond to any feature someone likes with "but why not just [inferior solution], it's not that bad". These things simply add up. :)


> Be wary of simply justifying why it's not the end of the world when a feature is missing, which is a much different argument. For example, I bet everyone who uses IRC appreciates some sort of indication for when they are mentioned even though they could ctrl-f for their username every once in a while instead.

FWIW, by default my IRC client notifies me when I've been mentioned. A benefit of using an open protocol is that people can develop different clients that cater to their needs.

For code discussions I open a browser and an IRC window side by side. If I'm not paying attention to the conversation I just close the browser and don't have code snippets polluting the chat window.

> But I feel like you can always respond to any feature someone likes with "but why not just [inferior solution], it's not that bad". These things simply add up. :)

I feel that goes both ways, though. Just in this thread people have complained that Slack uses an absurd amount of resources and is proprietary, only to have the concerns sidelined as not important.


Slack has syntax highlighting. Also, monospacing is used in the middle of a message to indicate that something is code, input, or output.

> Having to search the entire conversation history in the chat window is a terrible idea because it's slow and difficult to use. Having a separate tool or page to search history is a superior solution, and software exists to do that in IRC.

I have to disagree with this. Having to search for historical messages right where you can see recent messages is convenient. Using a different tool (potentially with a different UI) increases the context switch overhead. And there's no reason the search must be slow; the current chat window can display a portion of the messages, and the search can be done either on the server, or a background thread searching a database locally. Slack in particular has some bad engineering to make its UI slow and memory-hungry, but many of its copycats are actually functionally similar yet much faster.


While I personally prefer irc and definitely agree that an open protocol along the lines of irc should be the direction we head towards, I think it may be a bit shortsighted to imply users don’t prefer things such as in app searching and it definitely seems they love gifs.

I’m pretty sure asking users to leave their app and go to a separate webpage to search wouldn’t sit well with most users, particularly people who are involved in some kind of deadline for their project—what we might brush off as “it’s just like two extra clicks!” is actually much more disrupting. It pulls you out of your workflow and those extra clicks feel like they add up over time.

While some of us may sneer at chat apps like Slack, it’s obvious their UX/UI heavily resonates with users.

We should be looking at why users absolutely prefer Slack and see if we can build a client based on an open protocol which will give the user experience most users prefer while still maintaining an irc type experience for users like us.


> they'd be just fine with :-) instead of an emoji.

And IRC supports UTF-8 and unicode emojis just fine.

> But having an IT guy spend half a day properly setting up an IRC server is hard and it doesn't have a crappy web UI by default, so lets all use Slack.

I've found my organization uses Slack less because of the buzzy features and more to route around the brain damage of IT.

E.g., IT won't allow standing up communication servers with access allowed from outside the Corp intranet. Especially IRC.

Sales and support engineers frequently need chat access from outside the corp network. Ergo, 3rd party chat solution.

Slack is the worst solution in many ways, but it turns out fixing idiotic 90s security policies in IT departments is hard and you have to completely block the public internet to block Slack.


> People keep talking about IRC but no one want to go back there

Speak for yourself. I never left and I find it very tedious when I'm forced to use anything else. In practice 90% of the justification for any other system seems to be that people want to post inane cat pictures at each other. That just isn't worth the tradeoffs for me. The 'modern replacements' for IRC are even bigger workplace distractions than IRC.


Oh come on can we drop the cat pictures trope?

I use RocketChat for my consulting business for a few reasons that are largely unavailable on IRC without bots:

1) Rich text and syntax highlighting - Small properly fenced off code blocks are a wonder. Contrast that to IRC where it would never look quite right, relies on the other person's client to have monospaced fonts, and usually gets you yelled at for flooding

2) URL expanding - Viewing titles and a snippet of the content is useful. Requires bots on IRC.

3) File sharing in a trivial non-p2p. Nobody liked DCC, and I shudder thinking of going back to opening port ranges for that.

4) Reliability of having a central history which alleviates needing a bouncer, and reduces how important a stable connection actually is.

The only other thing you could come back with is to use yet other external platforms to alleviate those issues like:

For 1) An external public/private pastebin solution

For 2) A bot as I already said

For 3) An external filsharing service: Dropbox, Nextcloud, etc

For 4) External bnc: ZNC, bip, weechat, irssi etc

RocketChat, Mattermost, Slack, et al incorporate all of those things and more and are inherently useful - Plus, if you're the administrator you don't have to enable gifs or cat pictures, yes that shit is dumb.


IRC bots are trivial to implement and run so I don't consider many of these, which are commonly provided by IRC bots, as legitimate arguments against IRC. I don't consider "but you need a bot" to be a legitimate gripe.

Rich text is generally worthless except for code highlighting, but pasting large amounts of code into the channel is generally considered antisocial on IRC anyway, and pastebin services are used for this. It's not unusual for a company to provide their own internal pastebin services anyway, since it's generally useful with other systems like email. Ditto file sharing.

> "Oh come on can we drop the cat pictures trope?"

No, because in my personal experience that is OVERWHELMINGLY the most frequently used feature of slack/etc that's not present in IRC. For every time I've seen pasted code, I've seen easily a hundred inane pasted memes. I wouldn't bring it up if I didn't earnestly believe it's the primary reason people prefer systems other than IRC.


I care about federation, scalability, robustness, access to past messages (history, as you put it) and disconnected operation (e.g., access missed messages on reconnect) -- that sort of thing. Maybe file sharing. The only rich text features I use are: code quoting, and text quoting, and I just don't need those if I'm using a traditional IRC/XMPP client. I don't care about text styling or formatting, or emoticons.

IRC is ancient, and pretty much broken, but it still works fantastically well for some things, and I really like having a text-based client to run in a tmux.

EDIT: IRC, XMPP, and such, support integration just fine via bots.


> I care about federation, scalability, robustness, access to past messages (history, as you put it) and disconnected operation (e.g., access missed messages on reconnect)

Apart from federation you’ve described Slack.

Neither IRC nor Jabber give it to you out of the box. Slack does.


IRC and XMPP are protocols. Slack is a service. I think IRCCloud has all of those features.

A few of these are being discussed as part of IRCv3, and in my experience bouncers (or something like IRCCloud) work alright (though maybe not perfectly) for history. And there's plenty of "integration" if you can use bots.

Hybrid clients like Quassel even have a sort of integrated bouncer you run on a server that provides native offline history for the client-side GUI.

You can write IRC bots in any language you want.


Ironically, IRCCloud does everything what Slack is hated for: inline images and gifs, electron/browser-based client, closed source, paid subscriptions...

I think the main points of criticism about Slack are not the ones you listed. It's that it's a proprietary protocol, a data silo that can't easily be accessed, the bait and switch of first supporting IRC and then killing off the gateway, forced to use the official electron/browser based client.

I never heart anyone complain about inline images / gifs (which is also something that most IRC clients support) or that it's paid (which IRC bouncers / clients are often too in cases).


IRCCloud doesn't prevent someone from using another client.

The thing is, all you need is what IRC offers. All I need, anyway. Just plain ASCII is perfect - I don't need or want emoticons or any of the other bloat. Just plain text is so nice.

Problem is that most people want to have reactions, replies in chains etc.

I personally quite like IRC but I understand why people are less keen.

It's not the way of the majority. Probably not the way of the entire center of the bell curve.


I doubt most people care about reactions.

Replies in chains are a mixed bag. It makes it easier to follow that particular conversation, but the UI/UX is godawful to the point of it being more confusing than just in-band discussion, IMO.


Reactions are useful because they provide acknowledgement without clutter or notification.

For example in Whatsapp I often check a notification and find its just a smiley or thumbs-up


What about threads? Mentions? Mentions across channels? Client-independent history? Search? File attachments? Interactive features like polls?

I'm glad that IRC works for you, but it's 2018. We can do better than slate and chalk.


Quassel fixes history and search. Are mentions highlights?

Jodie in HR is going to run Quassel?

With the list of channels on the left, and the chat on the right in the big window? It's pretty different to Slack.

The world is bigger than just USA. Plain UTF-8 is just fine, though, and IRC supports it.

That is exactly what IRCCloud does.

I know it doesn't directly answer your problem, but running thelounge on a node server can do a pretty good job. It supports user-based logins and since it's running as a service, chat history is supported. Currently there's no way to search, but I imagine that could be implemented in the future.

https://thelounge.chat/


v3.0 adds message storage with sqlite, and message search will be built on top of that (there's a proof of concept pull request open with it).

You'd have to extend IRC so much, that it would cease to be IRC.

I don't think it needs to be. Just have the rich content be a URL and the rich client will know what to do with it, and humans using other clients can follow the link.

We actual do this with an IRC client we developed for internal use.


Is that a problem?

Why not develop a new protocol, and not try to call it IRC - there are many things about IRC that suck, specifically its support for push messaging and mobile.

XMPP and Matrix are at least two

How would this be different than Slack?

You could connect to it through a terminal client and save gigabytes of RAM.

Because it would be using IRC, an open protocol.

I honestly don't see the point. If you want to use IRC for company internal purposes with your coworkers, do it fully self hosted and with zero dependency on external hosted anything. ircd-hybrid on debian is not rocket science to set up.

weechat + wee-slack.py works quite well.

Very well - https://github.com/wee-slack/wee-slack

I'm so used to using wee-slack that I try to use commands like "s/" when I use the web browser interface (which doesn't work).


Heh, s/foo/bar/ is about the only Slack extension (vs ordinary IRC chat) I am aware of in weechat. I'm sure others exist, just my use is extremely naive / basic.

One thing I wish wee-slack had (and I haven't updated in months, so it may by now) is the ability to download files attached to messages without opening the URL to webslack. That, and occasionally silent failure to display long notes attached to messages, are the only major hurdles I encounter with wee-slack on a regular basis.


bitlbee[1] + slack-libpurple[2] will work with any IRC client.

[1] https://www.bitlbee.org

[2] https://github.com/dylex/slack-libpurple


If only Discord was so simple.

ctrl-f "wee-slack"... not found.

https://github.com/wee-slack/wee-slack

It works great!


Use matterircd

Relevent XKCD - https://xkcd.com/1782/

IRC is still there while all the other fads are gone.

Has the Slack defense armada already found a good reason why an Electron-based proprietary, vendor-locked-in US version of IRC is even worth a comment?

Man, I really don't like a lot of things about Slack, but this comment is over the top. At least assume good faith on the part of people who like do Slack and defend it. There are differences of personal opinion over which features matter most, and it's valid for people to disagree with you. I happen to agree with some of the implied criticisms in your second clause, but, please tone down the tinfoil hat and aggression by a factor of 100.

Because it works? Because it offers the same capabilities across multiple OSes and devices? Because it has message history and offline communication? Because it has multiple built-in and third-party integrations? Because it supports file transfers? Because it supports seamless ad-hoc communication between several people (with access to offline medsages)? Because it supports video calls and screen sharing?

For XMPP there’s exactly one client that supports may be half of those features. For IRC there are none.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: