Twitter API v1.0 / v1.1 support

[jeffehobbs]

Needs API key authentication...or maybe not. In light of the new API rules from Twitter, will tweet.js require an API key? The way I'm reading the new rules, it seems like Twitter is going to want to know who we all are, which connotes "API key".

~Jeff

[purcell]

To which new rules are you referring? I haven't read of anything.

[purcell]

Found what you're referring to. Will read and respond.

[jeffehobbs]

Right. https://dev.twitter.com/blog/changes-coming-to-twitter-api . "required authentication on every API endpoint".

[jeffehobbs]

Also, I could see "Display Requirements" being a PITA.

[purcell]

I've tweeted 'em to find out. We're likely to need to make changes, but I'd hope that whatever plumbing they use to support their own widgets could also be used by ours... sigh.

[purcell]

No response. Given the general discussion around this topic, I wouldn't say things look good for the future of jquery.tweet.js.

[raideus]

This is probably the best place to get answers: https://dev.twitter.com/discussions

Picked up the following tidbit from a Twitter rep:

"There are no client-side only solutions besides what we offer in our Twitter for Websites family of products at this time. If you want to use the API itself, you'll need to use server-side OAuth. If you want to engage with the platform client-side, you'll need to use the Tweet Button, Follow Button, Embeddable Timelines, Embeddable Tweets, the tweet, follow, favorite, and retweet web intents, and their accompanying javascript events. We're still working on this client-side family of products and there may be further enhancements to the API's auth model in the future that would make client-side development more palatable."

Not sure if that is relevant in any way to jQuery Tweet?

[purcell]

@bootsz Yes, it suggest that jQuery Tweet will no longer be able to work in its current form. However, if Twitter is providing its own widgets which presumably have unauthenticated access to backend data, it's possible that Tweet can make itself look like the official widgets and continue to access that same data.

[raideus]

Got it. In terms of Tweet "making itself look like the official widgets", any idea how that would be accomplished? I've played around with their new widget a bit and it doesn't seem like they allow hardly any customization from the front-end.

[purcell]

@bootsz I just meant from a network point of view -- while the appearance of Tweet wouldn't be identical, it could perhaps be made to make network requests in a manner indistinguishable from the official widget. However, it might still be in violation of the UX guidelines.

[danielkorte]

So just for clarity's sake, right now at it's current state, jquery.tweet.js would not be a solution if say a large chunk of your site's visitors are visiting from the same IP address where rate limiting would occur very often (and very quickly)?

[purcell]

@danielkorte Correct. But neither would Twitter's official widgets be a solution, for the same reason. At least currently. It's unclear what the situation will be with rate limiting after the unauthenticated 1.0 API is disabled.

[StanScates]

Howdy, I'm rather fond of jquery.tweet.js, so due to the impending deprecation of Twitter API v1.0, I created a simple OAuth / caching layer designed to interface with a slightly modified version of jquery.tweet.js. Set up a Twitter App for your feed, use the customized jquery.tweet.js provided and plug your OAuth credentials into the index.php file included.

Hopefully someone will find this useful. I'm converting all of our production sites which currently use jquery.tweet.js to use this henceforth.

https://github.com/StanScates/Tweet.js-Mod

Feel free to contact me with questions/comments. Thanks -Stan

[raideus]

Stan, THANK YOU for this! Looking forward to trying it out.

[StanScates]

Let me know how it goes :smiley_cat:

[purcell]

Hi Stan, that's neat! I'll have a think about how/whether to merge some of that back into this main repo. (Since you didn't start by forking this repo it's not easy to see what changes you've made to tweet.js, but I'm guessing it's limited to the build_api_url function.)

You'd have to be careful that other people didn't point scripts etc at your endpoint -- it'd be very easy to exhaust your twitter credentials' request quota.

-Steve

[StanScates]

Hey Steve, I've just rolled out v1.3, I've made several changes to jquery.tweet.js (feel free to take a look, I would highly value any input you may have), I would certainly be open to forking your repository but I didn't want to jump the gun since this introduces a whole new layer of complexity to your excellent plugin and I didn't want to pollute its simplicity (yet). Please send me an email if you wish and we can discuss how/whether you'd like to package them.

To your second point, although it is theoretically possible, I feel that the effort involved in order to circumvent Same Origin Policy restrictions makes that an unlikely scenario. With that said, I do highly recommend the caching feature, it's enabled by default and very simple.

I very much appreciate your input.

[purcell]

Hi @Mandooox, please file related issues on tweet.js-mod rather than here.

[mohamdio]

hi @purcell , really sorry for that , okay i will delete this comment

but about your plugin , are you will update it or what can we do for [ API 1.1 ] :( ?

and other ask : when search about new API , i found that should any user will use plugin should Create new APP to can use the plugin after update by Stan ... are that right ...?

thanks again for your great work in this plugin.

[purcell]

@Mandooox As discussed earlier in this issue, it's not yet clear whether it will be possible to keep tweet.js working after the old API is disabled. For now, it's still (mostly) working fine.

After the old API is disabled, Twitter will still continue to supply their own (unauthenticated) official tweet widgets, so in theory it would still be possible for tweet.js to use whatever API those official widgets use.

-Steve

[mohamdio]

okay , really i'm not happy with this new API :( , your plugin was perfect and easy to use , and i hope it will be still working..... thanks

[petenorris]

Not being a developer, I'm still unsure if seaofclouds twitter feed is going to work or not. Is there no way to test with the new API1.1? I predict a raft of people who have implemented into their site who have no idea about the v1.0 switch off (Tuesday 5th?), will suddenly inundate you with questions :( (like this one ;)

[purcell]

@petenorris To be clear, tweet.js will not work with the Twitter 1.1 API, because that API requires the use of authentication, and nobody with any sense will put his API authentication key inside a web page so that a widget can use it. So testing with the new API is not a concern.

However, Twitter has its own embeddable widgets, which do not require authentication keys, so it may be possible to reverse-engineer those and make tweet.js mimic the requests they make. This requires a chunk of work which I have not undertaken (so far) because it has been neither urgent nor funded. Note that tweet.js may still fall foul of the user interface guidelines, and therefore not be permitted to use the API.

It's extremely unfortunate that Twitter has declared war on API clients like this.

[petenorris]

Thanks. I really do appreciate your reply and the work to build this in the first place. My client is rather large and I couldn't use the native twitter widget as it's got a minimum height of 300px (and didn't fit the design!). I have applied stanScates (thanks Stan) to our test version of the site, and its working fine on the test site - fingers crossed for Tuesday!

[purcell]

I am also considering building a kind of "proxy" site, which would allow you to enter your Twitter auth details, and then it would sit between tweet.js and the Twitter 1.1 API, similarly to Stan's solution. If there's enough interest then I'll build such a thing, probably payable on a cheap monthly subscription basis.

[asirota]

Hi @purcell - thanks for a terrific jQuery plugin. We've used it on several websites now (www.cloudfingr.ca and www.newpathconsulting.com) and find it indispensable. We'd be happy to pay a monthly subscription cost to support your efforts since this is a feature for certain clients who wish to integrate Twitter. We have only 1 doing this so far, but maybe as Twitter takes off there will be more. The new v1.1 API must have a decent client, jQuery friendly solution that is not tied directly to the Twitter, non customizable v1.1 compatible embeddable widgets.

[raideus]

I second @asirota 's comment. At the agency I work for we have several large clients who would definitely be willing to pay an recurring fee for this type of functionality given the new restrictions.

[ghost]

I wish I could say the same as asirota and bootsz, but it's pulling teeth to get funding for anything from my employers. Even small recurring fees. If you had a free version with branding and link back to your "paid" version, I would be free to use that. I definitely appreciate the work you've put into it and feel that you should get compensated though.

[willisweb]

I'm not sure about a reoccurring fee but we would happily pay a reasonable amount for each website we use it on.

[purcell]

Thanks guys. There's already been some discussion about options. If we put in work to provide a middleman service, we're in danger of being shut off by Twitter for bypassing the Twitter TOS (and helping you guys do it), so we need to think carefully about how to proceed.

(Aside: I've just been playing with the embedded timelines, and apart from the lack of customization supported, it's ridiculous that you have to explicitly create them via the twitter site.)