Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Context preview support for URLs #244

Open
kirushik opened this issue Feb 14, 2015 · 7 comments
Open

Context preview support for URLs #244

kirushik opened this issue Feb 14, 2015 · 7 comments

Comments

@kirushik
Copy link

Sometimes I post a github issue URL or a trello card link in the chat.

It would be a really great feature if Let's chat was able to replace long and non-descriptive URL with some context from the target page. (If this would happen on the clientside then even non-public sources can be covered.)

From my experience with HipChat, such snippets significantely increase the context-awareness of all the people in a discussion.

Of course, this can't magically work for all services out there, but GitHub seems to be a great trial one.

@hhaidar
Copy link
Member

hhaidar commented Feb 14, 2015

+1

By the way, right now you can linkify ticket numbers and such by adding a local.yml file in /extras/replacements/

There's an example file in that directory you can copy.

@hhaidar
Copy link
Member

hhaidar commented Feb 14, 2015

Oh, I forgot to mention that we support hubot as well: https://github.com/hhaidar/hubot-lets-chat

@kirushik
Copy link
Author

@hhaidar Oh, that's great, tanks for tipping those out.
I'll see if Let's chat will suit my current team.

Still need to figure out some IRC-public-room-to-XMPP-MUC bridge, though.

@PerfectCarl
Copy link

I haven't found a convenient ready to javascript library to achieve that.
It goes without saying that I'm interested in the feature as well as in the implementation :)

@jotterbot
Copy link

Is there an existing open source/free library/service so as not to reinvent the wheel?

Could this be implemented faster if an api call against embed.ly was used (https://github.com/embedly/embedly-node) or something using oEmbed/noembed (https://noembed.com/) spec?

Maybe a global "enable api embeds : yes|no" switch in local.yml for example.

@PerfectCarl
Copy link

I have asked a question on software recommendation about the technical side

@saranrapjs
Copy link

...I made an extremely simple oembed branch, with provisional support for YouTube and Twitter, but ran into many issues with theoretically supported providers and the default content security policy defined in app.js.

Where did you end up with either implementing either oembed, or something like it? I know embedly supports some proxying (which might get around the CSP) but seems weird to depend on something that costs money.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants