Thanks for the quick reply. Glad to hear that this is not the intent, and I can certainly see the appeal of a webhook based API for certain use cases, but I’m still not sure what this means to me as a desktop userstream client.
[…] and we begin to remove the existing streaming options.
I’ll certainly point out that today’s announcements and the roadmap ahead is focused on the core Twitter data platform so none of the things we’ve specifically talked about so far is aimed at client applications
If it’s not aimed at client applications but the streaming APIs will still be removed, then what is aimed at client applications?
That said, I can think of some architectural patterns that would enable a webhook-based interaction to continue to work with a client application
Theoretically, we could set up our own infrastructure with a web server listening for webhooks of all of users, and provide our own streaming-equivalent server.
But we’re just an open source client application operating on a $0 budget, and we kinda value the privacy of our users, we don’t want to have to add a man-in-the-middle proxy to allow them to have streaming-like functionality.
I also fail to see how this is more efficient - sending outgoing HTTP requests for every single tweet or tweet event received by every user? I just see a ton of extra overhead, in size and in latency.
Of course, if the long term plan is to kill applications that are dangerously close to the core twitter client experience, I can see how that’s not a big concern.