Client side app deployment which follows tweets real time

[Gutzas]

I’m looking for a way to write an open source application that would run client side, and would follow tweets from specific accounts in real time with no third party interference (those are all hard requirements). The app doesn’t need write access – that would be nice to have, but it’s not a requirement per se. I would also like to avoid asking each user to create their own Twitter App; I assume that’s not something Twitter intends, anyway (a single “real” app should map to a single Twitter App).

I looked into the Streaming API’s OAuth thing, but it seems that’s not deployable client-side, since it would require me to publish my consumer secret. Am I wrong? If I’m right, is there another way to achieve my objective in a different manner?

See also:

1. My question on the same topic on Stackoverflow
2. Another user’s similar question on this forum

[andypiper]

This is not straightforward.

The Streaming APIs are mostly being deprecated in favour of webhooks (account activity API) but the filter / track functionality will remain. All of Twitter’s standard APIs require OAuth and yes, that’s something where you’d want to protect the secret values in the client-side context.

You’re right that users should never be asked or expected to create their own apps and to provide those keys to a third party - that’s essentially an attempt to circumvent our limits and system and it is definitely not OK.

Sorry to be the bearer of bad news but this is not something that we currently support.

[Gutzas]

Bad news is better than no news – I kept poking at this for the past couple of days, and I started to feel like I was punching in the dark. So yes, it is bad news for my app, but at least I now have an authoritative answer – so thank you for that!

Having said that, the app I’m trying to deploy would be profoundly meaningful to a lot of people, could easily be isolated, and wouldn’t affect Twitter’s servers in any substantial manner. Is there any way I could contact someone within your company who’s willing to listen, and able to look for a technical solution – if only for this isolated case? I realize I’m asking for a favor, but the favor is just being listened to.

[andypiper]

Thanks for being so constructive in your approach.

The truth is that we’re really unable to build “one-off” solutions that talk to these kinds of scenarios - we have to optimise for scale and breadth rather than individual requests like these. I understand that’s a disappointing statement as a developer, but I don’t want to misrepresent our resources or outlook here.

The PowerTrack realtime APIs - which are an expensive enterprise scale product - could potentially offer you what you’re requesting, but again I wouldn’t like to state that it is “security safe” to run directly from a client device or app to the server - you’d want to think about that piece.

[Gutzas]

Andy, I appreciate your personable approach to an anonymous guy’s rather strange request. I am disappointed that you’re basically telling me your company is not even willing to listen to what I have to say – which is a bit ironical, given your specific line of business. But it is what it is, and I do appreciate you took the time to answer both of my queries. Please let me know if you reconsider giving me a chance to present my case. Cheers!

[andypiper]

Listening and understand. It’s simply not practical or possible for us to make exceptions or to modify our systems for “one-off” cases because the numbers of developers on the platform are just huge. I certainly understand your disappointment, this is not unwillingness, just practical.

Thanks for your interest in working with us, we really appreciate everyone that builds on our developer platform. I’ll certainly circle back if circumstances change on our side in the future.

[Gutzas]

Ok, here’s the next best solution I’m considering; please let me know if this does respect the spirit of your policies.

I’m thinking about storing both the consumer secret and the token secret on our side, and signing the request on our side as well. I would however have to let the end user’s equipment initiate the direct, long lasting connection to your servers for real time data. This means their hardware would have access to all headers needed to make the request.

The most sensitive values in the header seem to be the application’s consumer key and the user’s access token. I don’t think those should be any real concern, but I thought it would be better to ask before implementing.

Is this a sound approach, according to your best practice guidelines?