Getting RSS Feeds For Twitter Users

Want an RSS feed for a particular Twitter user? This used to be linked off the profile page(s) but since disappeared. It’s still available if you know where it is:

http://api.twitter.com/1/statuses/user_timeline.rss?screen_name={username}

Replace {username} with a username (example).

You could also put a bunch of users into a list and query that using:

http://api.twitter.com/1/lists/statuses.atom?slug={listName}&owner_screen_name={username}&include_entities=true

Replace {username} with the list owners username and {listName} with the list name (example). Strangely that’s only available in atom format.

I still find RSS handy for those accounts I don’t want in my stream but want to keep an eye on, as well as those I want to programmatically access or manipulate.

Notifications For Better Engagement

One thing I’ve learned repeatedly over the years is that good notification systems create great engagement and encourage habitual users.

The biggest problem with any product/service is getting people to come back. “Drive by” users aren’t terribly difficult. Google will bring you those with a little work. However your business comes from users coming back repeatedly. Those are you’re true “users”. They are the ones who will bring others.

Today, I think Facebook and Twitter are the perfect example of companies who understand and utilize this strategy in a way that amazes me. Lets look at this:

Facebook

They are the biggest, so I’ll go through it first. The first method of notification is the obvious alerts when logged into the site. You can keep it open and use it as a client, it works great. Facebook also has one of the best email notification systems on the net. You can reply to a comment or message by simply replying to the email. No “app” to install. Even an old Blackberry can participate. Even people where Facebook is restricted but email works can participate (stereotypical corporate office). Email is the worlds greatest API. They take full advantage of it.

On top of that Facebook apps have push notification for smart phone users. Facebook also supports SMS notifications. They additionally support XMPP (Jabber) so you can use a desktop client with their messaging service.

One thing I never understood is why they don’t officially support and continue their desktop notification service. With a trivial amount of work it would be an even better retention method. However the API’s are clearly there for client support (several use it).

Facebook doesn’t exploit this system for marketing or PR. It’s just a useful way to interact with their system. It’s an interface. It’s an API.

Twitter

Twitter is another company that gets notifications. The most obvious again is their website. Secondly their apps support push notifications. Twitter is also pretty good about email notifications however they don’t accept replies over email. They also support SMS (i.e. “Text follow raccettura to 40404”).

Twitter lastly has an open API and even supports desktop apps like Twitter for Mac and TweetDeck. They encourage their users to stay on constantly and keep up. It’s part of what keeps users addicted to the service.

Again, they don’t market. They just keep users interacting.

Google+, Quora, etc.

I won’t judge Google+ just yet, they are pretty new still. Quora does a pretty good job with notifications however the balance between annoying and useful hasn’t quite been met, at least in my opinion.

It’s easy to overlook this “detail”, but for many users, this is the interface, realize it or not.
I won’t

What Facebook Apps Know About You

The ACLU put together a clever quiz on Facebook that lets you see what a Facebook application knows about you.

I doubt most people realize how much they are giving an application, and how unnecessary the information is to the application. There is no legitimate need for something as simple as a quiz to require that much information. And yes, if your friend takes a quiz, your information is shared too.

I mentioned the other day that that Facebook changed the data retention policy. So this gives a little more context regarding what is actually at stake here.

I’ve been unable to confirm if Facebook gives applications the same data for minors (those under 18) as they do for adults. I know they restrict information shared via the website, but not sure if that extends to the API level. If anyone has a minor child and can shed some light on that, I’d be interested to see how they treat privacy of children in Facebook applications. I’m also not sure if they adjust what data is shared for users, in particular children in other countries where laws may be different. If you know, please share. If you can share a few screenshots of what’s revealed contact me (I won’t share unless you explicitly say so).

Yes, I know this is my third Facebook related blog post in a week. I promise to go back to ignoring them soon enough, but the privacy implications of their applications is pretty interesting to say the least. This is especially true if online privacy and security have long interests of yours.

On Facebook Permitting Longer Storage Of User Data

Previously the rules only permitted storage of some data for 24 hours. Notice I said “rules”. The truth is that there is no technical means of enforcement that I can find. This is done on the honor system. Facebook in theory could look at usage and wonder “how are they doing this without refetching data?”, but monitoring all the apps in that way seems highly impractical. You’d need good knowledge of how the every app actually functions to make that decision. That still doesn’t cover the case of not deleting data when a user removes the application or changes privacy settings.

I’m sure there are some shady application vendors who have forever ignored this requirement. I’m sure some have also captured data they weren’t supposed to store. It seems naïve to think otherwise. That’s not to say everyone does it, or even a sizable number. I suspect most companies are honest and follow the rules. The change to remove the limit is actually more honest and straight forward. It is a step closer to reflecting reality.

Facebook should really have some sort of audit policy for apps over X number of users, or make it clear that there’s no real technical means limiting what an application can store once you share data with it. They don’t know for certain that just because a user deleted an application that the application has purged the data. There’s no technical means behind it, and that’s not something that’s easy to fix.

This is an important thing to clarify. Just because they had a policy of a time limit, that doesn’t equate to a technical solution. This is akin to passing a law that says “no identity theft”. It’s a novel thing to do, but it doesn’t prevent theft. It simply clarifies the official position on the activity. If this method worked, we wouldn’t need law enforcement or a legal system, just a few clever people with pens to write laws.

Facebook can obviously shut down anyone who it feels violated their policies, and can likely take legal action against such parties. I’m pretty sure they shut down applications, I’m not sure about legal action.

Bottom line: only share data if you’re willing to accept this risk. Their clarification of warning dialogs before you authorize an application is a good step in this direction.

Another Brick In The Facebook Wall

I ran across the problem recently trying to write to a users wall using the Facebook API. The Facebook documentation is hardly sane as it’s a mix of languages, not entirely up to date, and lacks good examples. The error messages are hardly ideal either. “A session key is required” at least leads me in the right direction. “Invalid parameter” is just unacceptable and makes me stabby.

So here’s some cleaned up pseudocode I pulled together that will hopefully be of use to others who bang their heads against the wall. This “works for me” in my limited testing over several days:

require_once(‘./facebook-platform/php/facebook.php’);
 
$facebook = new Facebook($apiKey, $appSecret);
 
// This gets us the uid
$canvasUser = $facebook->get_canvas_user();
 
// And the session key
$sessionKey = $facebook->api_client->session_key;
 
// You need both of these permission bits
$user = $facebook->require_login($required_permissions = ‘publish_stream,offline_access’);
 
// You’ll likely have an application sitting here and at
// some point in your application be doing the following
 
// Here’s where we actually set the status
$facebook->api_client->call_method("facebook.status.set", array(
    ‘uid’ => $canvasUser,
    ‘status’ => "All in all it’s just another brick in the wall.",
    ‘session_key’ => $sessionKey
));

Getting the right permissions is key.

The thing that ends up being the most confusing is the session_key. After reading the docs, I was inclined to do:

$token = $facebook->api_client->auth_createToken();
$sessionKey = $facebook->api_client->auth_getSession($token);

What you really want is:

$sessionKey = $facebook->api_client->session_key;

You can also use adapt this to use stream.publish if you’d like.

iPhone OS 3.0

I’m rather thrilled with Apple’s iPhone OS 3.0 upgrade. They announced way more than I expected them too.

  • Cut & Paste – Great interface, long long overdue.
  • Push Notifications – Finally! Push notification will make the iPhone a million times more useful. I’m thrilled by this. Way better than background apps since it won’t consume as much power. Background apps sound better than they are.
  • Peer to Peer Support – Oh boy, apps are going “social”. I don’t buy into this too much, though I do think this will make some games much more fun. Wireless Game Link Cable!
  • Landscape Keyboard All Over – This just made Mail much more awesome.
  • Accessories API – This has by far the most potential for innovation. My only hope is Apple isn’t too nasty with hardware licensing. There’s so much room for innovation here it’s scary. Economic struggles will likely put a damper on all the accessory buying though.
  • Search For Built-In Apps – This is a killer feature in mail. I just hope it supports search over it’s own index as well as IMAP and Exchange.
  • Inline (In App) Purchases – Pretty cool but a potential for some serious annoyance. Paying $5 for an app and then realizing it costs you $30 to unlock it to meet the description will quickly become a nuisance. Apple should force developers to note specifically what will be behind a coin slot before the user buys the app. At the very least allow users to document when rating (though developers will hate that and request removal of such comments). This has the potential to be very controversial and abused.
  • Turn By Turn – Apple says it’s BYOM (Bring Your Own Maps). Regardless it will be very good if a large navigation provider decides to participate and plug their data in here.
  • MMS – I’m sure AT&T is thrilled to get to bill users for MMS. Should be a good source of revenue for them.
  • Tethering Support – Cool, but I suspect pricing to use this feature will cross it off the list for all but some business users who can expense it.
  • A2DP – I first mentioned this in 2007. This should be pretty cool but I wonder what the impact on battery life is.
  • CalDAV – Long overdue but I wonder how much use it will get now that Google Calendar can sync via Exchange. How many calendar providers out there support CalDAV other than Apple (Mac OS X Server)?

Lack of video recording is a major bummer. Not that the iPhone is a fantastic video device but it’s still a very cool feature that would be very handy for developers and users.

Gmail Contact Sync

Google released the API for contacts. How long before someone comes up with a Thunderbird plugin to sync up with it? Any takers?

I’d love to know why they decided the API route, rather than use LDAP. It can be secured using TLS, and require a bind DN and bind password. If they did it that way, most email clients would be compatible right out of the gate.

There’s also Google Calendar Sync, but only supports Outlook. Still no CalDAV.

I’m slightly disappointed, but at least with an API thinks are workable. Standards would still be best.

Apple’s API Advantage

Vlad wrote about his work on improving Mac OS X performance (which is awesome by the way), and his findings from looking at WebKit code. To summarize WebKit utilizes some undocumented API’s (ironically from the same company that makes Mac OS X 😕 ) that give it an advantage over other software which can’t use them. This is pretty anti-competitive, and Microsoft-like in behavior. For a company that built it’s modern OS on an open source core, and it’s flagship browser (which is key to their mobile initiative) on an open source rendering engine (KHTML), you would think they would be a little more understanding about crippling platforms. Then again, look at the iPhone controversy regarding it being a closed platform (though that’s supposed to change next week, and I’ll be sure to blog about that).

Robert O’Callahan’s got a got a great blog post on some of his observations of things Mozilla would likely make good use of. He also mentions one thing worth quoting:

It’s worth reflecting that if Microsoft was doing this, they’d likely be hauled before a judge, in the EU if not the US. In fact I can’t recall Microsoft ever pulling off an undocumented-API-fest of this magnitude.

This is a very valid point which I 100% agree with. Microsoft wouldn’t get away with this.

Safari developer David Hyatt (former Mozilla developer from when Lizards roamed the earth) commented about this issue. Essentially he justifies the decision based on it not being a good practice to use some of these methods, and other aren’t even used anymore. This of course raises the question: Should Apple be deciding what other software developers can do, when they themselves can’t follow the same standards? I’d say that if WebKit feels it has to use it, there’s likely others out there in the same situation regardless of “best practice”.

See, I’m not too much of an Apple fanboy to criticize them 😉 .

Thunderbird Sync With iPhone/iPod touch

I’ve gotten quite a few emails over the past several months from people who want to know how to sync their iPhone (or iPod touch) with Thunderbird. Quite a few are disappointed to find mozPod doesn’t support these newer devices. It’s not quite my fault as I’ve yet to see any indication that it’s practical to implement.

I should note I do not own either device, but from what I’ve read, it doesn’t matter. Hopefully by 2nd or 3rd generation when I’m on the market Apple will have come to their senses.

The problem is that Apple hasn’t provided a good method for anyone to provide sync with the iPod. Even on older devices it wasn’t pretty, but it was workable. There is no real sync API outside of iSync, which is Mac only and not a public API. Instead what was done is mount the iPod file system and send it your data. While not awesome, this has been workable and provided many Thunderbird users with mobile data.

On the iPhone and iPod touch it’s not even possible to easily mount the filesystem. The best method I’ve heard of is hacking it so you can mount your phone using sshfs with something like FUSE. I know myself and some Linux and Mac users (horray for MacFUSE!) could manage, but I wouldn’t dare try to explain to someone how to do that. From what I’ve read the iPhone manages data using SQLite 3. Therefore it seems possible to use mozStorage to interface with it. Perhaps someone with more experience with mozStorage and db’s generated outside mozStorage would know better about any potential compatibility issues.

Calendar:
/var/root/Library/Calendar/Calendar.sqlitedb

Address BookL
/var/root/Library/AddressBook/AddressBook.sqlitedb
/var/root/Library/AddressBook/AddressBookImages.sqlitedb

Seems to me Apple could turn this into an API pretty easily by re-creating the old iPod style USB storage device mounting and give us access to these files.

In my mind the ideal implementation would be for Apple to just have a iTunes embed a mini web server locally accessible (obviously) and create a REST api to work with all data on the device. That would open up a whole new way of interacting with the device. Essentially you would interact with 127.0.0.1:[port#] and GET/POST your way through the interface. Perfect for Calendar, Address Book, Notes, or whatever else Apple comes up with.

To get a vCard for someone:

  GET /contact/vcard/?last_name=Jones HTTP/1.1
  Host: localhost
  User-Agent: mozPod/0.3

vcard can also be done as xml (ooh DOM parsing for iPhone!), so there’s lots of possibilities.

To add a contact:

  POST /contact/add/ HTTP/1.1
  Host: localhost
  User-Agent: mozPod/0.3
  Content-Length: 450
  Content-Type: application/x-www-form-urlencoded

  fname=John&lname=Doe&address=1%20Large%20Road...

Though it would likely make sense to go with a more vcard like naming structure.

For calendar iCalendar or vCalendar would make most sense:

 GET /calendar/ical/?start=1-1-1970&end=1-19-2038 HTTP/1.1
  Host: localhost
  User-Agent: mozPod/0.3

You get the idea. Dead simple access. You could then use something likecurl to manipulate the iPhone’s address book via your existing application. It would be only accessible locally, so it’s as secure as your system. It would actually make things more secure since it would be one less reason for tinkering on the actual device, and it would open up a whole new market of iPod/iPhone software to go with all those accessories that have helped boost Apple’s market share. SyncML is cool, but SyncML is also a beast and reminds me of SOAP, WSDL etc.

Google Gears

In case you were wondering what Google Gears meant to the planned support for Offline Web Applications in Firefox 3.0, here’s an article you may be interested in. No definitive answers, but does mention the possibility of combining ideas.

Google Gears is pretty cool, but I’d be much more comfortable if Google submitted the API as part of WHATWG and it were standardized. Google Gears would then be the way to use it without a browser having native support. I personally don’t like the idea of competing implementations.