Expose Email Addresses via Twitter API
Posted on in api, twitter, twitter apiOne of the most popular posts that I wrote previously for my blog was regarding the Twitter API and email addresses. That post has since been permanently archived and is no longer available It seems as though this topic is very popular among new developers to the Twitter ecosystem. In this post, I’m going to revisit that topic once again.
How do I get the email address of a user using the Twitter API?
This is a very simple question to answer. You can’t.
Why are email addresses not available via the Twitter API?
There is not a single reason why Twitter should hand over the email addresses of its users to anyone. Any application that you develop should explicitly ask the user the input their email address, clearly stating why you believe you need it.
User addresses are private, just like telephone numbers. The only need for email addresses to be exposed via the API is for spam harvesting which is a big no-no.
I want to keep my application users informed about changes
This is a reasonable thought, but consider the viewpoint of your users. The will follow the account associated with your application for news and updates. Users will also expect to find news, updates and important content via your application.
Will Twitter ever open up the API to disclose email addresses?
No, and that’s a good thing.
Twitter API and Email Addresses
Posted on in api, twitterOne thing that appears to be a recurring theme on the Twitter API development mailing list and in the IRC channel of Freenode is the question of getting access to a users email address. I’ve always found this frustrating and have never seen a good reason why a users email address should be given out via any API method. The following list contains the reasons that are most often given when you ask why an email address is desired:
- I’d Like to Contact the users of my application:
See below. - Auto-Notices & Spam:
Not a chance.
It really is that simple. If you need a users email address then provide a settings page and ask them to enter it. Don’t think you can systematically fetch it from the API because you can’t, more to the point: I don’t think you’ll ever be able to.
And that’s a good thing.
Twitter API Oauth Update Status
Posted on in php, twitter, twitter apiThis PHP script will post an update to Twitter using OAuth. You can download the complete script and library here.
The Actual Script
1
Running the Script
The End Product
Moving Forward for Tweekly.fm
Posted on in lastfm, tweekly.fm, twitterIn January this year when I first undertook the Tweekly.fm project in ran in a very different way than what it does now. I’ve completely rewrote the code base that the system works from. It now runs a lot faster and we can support more users than previous. I now run both statistics for Twitter (tweekly.fm) and for Facebook (laststat.us). The past few days I’ve pushed changes out that change the way the system interacts with Last.fm and how we store your data.
A major change in the way the system works has been added. Instead of providing your Last.fm username to us now we use the Last.fm Webauth (very similar to OAUTH in fact) to interact with your Last.fm data. Even if you protect your data within Last.fm we can collect and publish your data for you (should you wish to do so). Protected user support is now live within the Facebook application and will be coming to the Twitter version very soon.
The larger problem that we encounter now is capacity. We’re taking on average between 280 and 550 new users per day. Over our platform we currently sit at just over 55,000 users. The entire platform is being financed independently by me which isn’t the best form of business model. Simon and I have discussed recruiting for venture capital but to do that we would need to develop a sound model to work from that could provide a return on any investment. Anyone interested in discussing this, please get in touch.
Platform vs Web Site
Posted on in amazon, api, facebook, google, modern web, platform, twitterOver the past six years we’ve seen major developments around the world in online services and computing. Traditional web sites such as Google, Amazon and eBay have now transformed into multinational platforms offering more than just a site to use. All of the services I’ve just named still provide their main web site, but isn’t it about time we started referring to them as platforms rather than sites. In my opinion, it is.
You can do so much more than simply search with Google or buy with Amazon and eBay. I don’t see the naming and references changing any time soon, but this is a thought I’d like to see come to fruition. The traditional roots of each of these large platforms can never be forgotten but through their own research, development and improvements they’re providing excellent services for the rest of the world to use.
In the more recent history, Twitter and Facebook have provided platforms for people to develop with which in turn created a boom for both enterprises. Its nice to see Facebook referring to their infrastructure and service as a platform, rather than a site. Perhaps others can follow suit, but I doubt it.
Tweekly.fm Featured in a Book
Posted on in tweekly.fm, twitter
Sometime last week I was talking to Simon about Tweekly.fm and he informed me that Tweekly.fm was going to be feature in a book that’s being written by Garin Kilpatrick. Garin’s book will document tools to be used with Twitter and we’re happy that we’re going to be featured. Its nice to see that the service being provided to end users is a good one and that we’re being recognised as a useful tool.
Caching & ADOdb for Tweekly.fm
Posted on in adodb, database, php, tweeklyfm, twitter, twitter apiThe best thing about building a project that gets popular is the same as the worst things about a project that grows rapidly. Tweekly.fm is currently gaining 1,500 users per month most of which decide to publish on a Sunday. This increases the load and run time of the delivery engine that pushes tweets outbound. The other side of an increased user base is that user pages get more popular. Although this is a good thing overall and shows our popularity – it also has its downsides.
The queries to show simple people and shared by counts are expensive to run. We’re indexing just short of 25,000 user records and running the queries in the original way brought the servers down to a sluggish speed. My response to this was to rewrite the entire user pages and introduce caching on a couple of levels.
The diagram below shows the original connections between our servers and our users. As the diagram shows, there was no caching present through the system. This presented problems under load and ended up with the user pages of the site being temporarily postponed.
After a little research and crunching of numbers I came down to the conclusion that caching points at both the database server and the website (abstraction layer). Implementing the ADOdb layer underneath the existing database links has proven to be a great success. Its boosted response times over 300%. The next diagram shows the new caching points added the the system.
Point A is the abstraction layer at the site level. At peak times, the queries issued here are cached for an hour. This scales back to 30 minutes at low load times. Point B is the connection between the web server and database server. Queries are cached at the database constantly via the MySQL Query Cache. Finally Point C is the connection to the Twitter API. All calls are cached for 30 minutes where possible, but due to the nature of the API and service in general I’m not currently caching too much here. What is not shown on the diagram is the connection to the last.fm API because this data is automatically cached and updated when needed.
Effects of Changes for Users
The effects of these changes will be noticeable by all users because the front-end of the site will be a lot snappier and responses should be quicker too. Hopefully this is just one of many changes that can improve the system for everyone.
Social Traffic Alerting
Posted on in stoke, stoketraffic, twitterI spent some time yesterday extending the StokeTraffic platform to include support for eye witness reports provided by users of the service. This now means that the service will include real time eye witness reports of problems and conditions of the roads in and around Stoke on Trent. All users are invited to participate in this extension of the service by using the new feature. If you’re travelling in or around Stoke on Trent and spot a problem then you can alert us by posting a tweet similar to the following:
If your report is accepted it’ll be posted live within a few moments. Please be aware that reports are limited to 100 characters and there are measures in place to prevent abuse to this service. I’m looking for suggestions, features and also of any issues. Get in contact with me here.
Last.fm Auto-Tweeting
Posted on in lastfm, project, twitterThis has been moved to http://tweekly.fm as I’ve rewritten and redeveloped the tweekly system.
Also, there is a Facebook version here at laststat.us
I’ve just finished the beta of my autotweeting last.fm statistics system. It’ll take your last.fm top artists and publish them to Twitter on a day of your choosing.You can sign up for the beta here.
If you have any problems or encounter errors while using the system then please contact me as soon as you can do at scott@dor.ky.