I know a lot of this audience are pretty bullish on IRC and so we're also busy testing an IRC bridge for Gitter. Once you've signed up, feel free to go to https://irc.gitter.im and give it a whirl.
Any idea if GitHub will ever alter the way that works so you can avoid it giving you write access. I was all ready to give Gitter a go until I saw the permissions that would be granted. Sure you're trust worthy but us IT types can be paranoid ;-)
And we completely understand. We're waiting on Github to update their OAuth scopes, and we understand that they're working on it.
If you're not comfortable with the OAuth permissions Gitter requires, you could try Gitter's sister product, Troupe https://trou.pe. It's got most of the same features, but with less Github integration and no markdown or syntax highlighting.
The idea that this gives write access to my SSH keys is still scary. Not that I don't trust your service, but what if somebody attacks it and adds malicious keys?
Pretty cool but I can't see having another chat client on top of Hipchat. Wish there was some way to bake this into Hipchat since the features look awesome. Great work!
If you're not comfortable with the OAuth permissions Gitter requires, you're welcome to try it's sister product, Troupe https://trou.pe. It's got most of the same features, but with less Github integration.
Maybe a good solution would be to request a less privileged token if the user doesn't want integration with private repos. Then, if they want to upgrade to integration with private repos they need to get a new oauth token with the relevant privileges.
I'd love to try this service out, but I also don't want to hand out oauth tokens that can read my ssh keys.
EDIT: Just read more comments and saw that my github ssh keys are completely public. I guess that makes sense since they are public keys!
We don't read, not write anything to do with your SSH keys. In fact, we don't write anything to your profile at all. This is a limitation of GitHub's API scope.
I've answered this numerous times in this thread, but I'll say it again, very loudly and very definitively: WE DO NOT WRITE TO YOUR SSH KEYS, EVER. EVER. EVER. We don't even read them.
Unfortunately, as beautiful as GitHub's API is, they've got their scopes for permissions completely wrong and we know they are working to fix this.
I don't want to sound like a parrot here, but I'm VERY excited about the feature set of your product but I'm not going to try it with the current permissions model.
Do you have any communication channel into Github through which you can let them know that their permissions model stands to kill your business?
Yeah we've been talking to them. We've had nearly 10,000 people sign up, given we only launched very recently, I wouldn't say this is killing our business at the moment and we're confident they will deliver a solution in the future.
It would be exceptionally difficult for us to add/delete an SSH key by a bug, because we don't ever call or reference keys anywhere and there's really not much else we do other than GET items.
I see your explanation in https://gitter.im/login/explain and it suggests a business solution that doesn't require me to believe the promises of someone I don't yet trust.
"In order to create a good first-time user experience that allows people to create and join chat rooms for public repositories and organisations... [the rest of the technical explanation]".
Stop doing this.
Make this feature optional. I don't even want a public chat room for my company's private repo.
It has nothing to do with your company's private repo, it has to do with getting a list of ORGS you belong to.
In fact chats for private repos is a completely separate matter and we allow users to upgrade their access to GitHub's repo scope if they want access to private repos.
Otherwise we'd have to do:
* signup (only public repos)
* upgrade permissions -> org chats
* upgrade permissions -> repo chats
And so then users need to understand three levels of permissions and scope and I don't want to burden people with that level of cognitive overload. It's hard enough to explain to people that they need to elevate privileges to get private repo access.
Whilst a few people share your view, we've had nearly 10,000 grant us this access in a very short space of time and so it's not massively affecting our product right now and we have confidence in the future that GitHub will change their permissions and introduce a read-only permission that we will then switch to.
I just integrated with sorl-thumbnail, I don't know if it will be a fully replacement for our IRC channel, however I'm sure most of the devs will give it a try.
I have been using this since the beginning for my open source project https://github.com/pksunkara/alpaca. They provide very good support. And the features are awesome.
It's a really cool service and I think one of the big considerations for us right now is that our freenode channel (#brackets) has 86 people in it as I type this. We've potentially got some inertia to overcome.
39 comments
[ 4.2 ms ] story [ 88.8 ms ] threadI know a lot of this audience are pretty bullish on IRC and so we're also busy testing an IRC bridge for Gitter. Once you've signed up, feel free to go to https://irc.gitter.im and give it a whirl.
Feel free to leave any feedback on Gitter here or get in touch with us via our chat room: https://gitter.im/gitterHQ/gitter or http://support.gitter.im
https://gitter.zendesk.com/hc/en-us/articles/200176672-Authe...
Which is unfortunate, because I'd like to try gitter but I'm not willing to mess around with my github account like that.
We don't ever write anything to your profile. As explained in the link below, this is a standard GitHub permission.
PS your SSH keys are 100% public: https://api.github.com/users/mikexstudios/keys
Mike
Short answer: https://gitter.zendesk.com/hc/en-us/articles/200178961-Why-d...
Long answer: https://gitter.zendesk.com/hc/en-us/articles/200176672-Authe...
So we hope for more to come for other areas of the API.
And we completely understand. We're waiting on Github to update their OAuth scopes, and we understand that they're working on it.
If you're not comfortable with the OAuth permissions Gitter requires, you could try Gitter's sister product, Troupe https://trou.pe. It's got most of the same features, but with less Github integration and no markdown or syntax highlighting.
Or does write access not include SSH keys?
[1] - https://developer.apple.com/library/ios/documentation/AppleA...
If you're not comfortable with the OAuth permissions Gitter requires, you're welcome to try it's sister product, Troupe https://trou.pe. It's got most of the same features, but with less Github integration.
We don't use those permissions, unfortunately as good as GitHub's API is, their scopes are very limited.
short answer: https://gitter.zendesk.com/hc/en-us/articles/200178961-Why-d...
long answer: https://gitter.zendesk.com/hc/en-us/articles/200176672-Authe...
I'd love to try this service out, but I also don't want to hand out oauth tokens that can read my ssh keys.
EDIT: Just read more comments and saw that my github ssh keys are completely public. I guess that makes sense since they are public keys!
We don't read, not write anything to do with your SSH keys. In fact, we don't write anything to your profile at all. This is a limitation of GitHub's API scope.
Short answer: https://gitter.zendesk.com/hc/en-us/articles/200178961-Why-d...
Long answer:https://gitter.zendesk.com/hc/en-us/articles/200176672-Authe...
PS, your SSH keys are 100% public: https://api.github.com/users/masom/keys
Mike
I've answered this numerous times in this thread, but I'll say it again, very loudly and very definitively: WE DO NOT WRITE TO YOUR SSH KEYS, EVER. EVER. EVER. We don't even read them.
Unfortunately, as beautiful as GitHub's API is, they've got their scopes for permissions completely wrong and we know they are working to fix this.
Short answer: https://gitter.zendesk.com/hc/en-us/articles/200178961-Why-d...
Long answer: https://gitter.zendesk.com/hc/en-us/articles/200176672-Authe...
Mike
Do you have any communication channel into Github through which you can let them know that their permissions model stands to kill your business?
It would be exceptionally difficult for us to add/delete an SSH key by a bug, because we don't ever call or reference keys anywhere and there's really not much else we do other than GET items.
"In order to create a good first-time user experience that allows people to create and join chat rooms for public repositories and organisations... [the rest of the technical explanation]".
Stop doing this.
Make this feature optional. I don't even want a public chat room for my company's private repo.
In fact chats for private repos is a completely separate matter and we allow users to upgrade their access to GitHub's repo scope if they want access to private repos.
Otherwise we'd have to do: * signup (only public repos) * upgrade permissions -> org chats * upgrade permissions -> repo chats
And so then users need to understand three levels of permissions and scope and I don't want to burden people with that level of cognitive overload. It's hard enough to explain to people that they need to elevate privileges to get private repo access.
Whilst a few people share your view, we've had nearly 10,000 grant us this access in a very short space of time and so it's not massively affecting our product right now and we have confidence in the future that GitHub will change their permissions and introduce a read-only permission that we will then switch to.
I hope that Github is reactive enough to get permissions setup in a failsafe manner so I can give this a spin.
I just integrated with sorl-thumbnail, I don't know if it will be a fully replacement for our IRC channel, however I'm sure most of the devs will give it a try.
Gitter Room: https://gitter.im/mariocesar/sorl-thumbnail
https://irc.gitter.im
Let us know you get along with it: https://gitter.im/gitterHQ/gitter http://support.gitter.im
Mike
Any chance of BitBucket integration?
[1] (http://slack.com/)
Short story, Gitter is awesome!
https://gitter.im/pksunkara/alpaca
In fact, Gitter uses Pavan's excellent Octonode library (https://github.com/pksunkara/octonode) for all it's communications with Github.
https://gitter.im/adobe/brackets
It's a really cool service and I think one of the big considerations for us right now is that our freenode channel (#brackets) has 86 people in it as I type this. We've potentially got some inertia to overcome.