Identi.ca implements the Twitter API

[Chris Messina]

Hey all,

It's been silent for awhile but lots of exciting things have actually been going on...!

One thing that showed up today is that Identi.ca has implemented support for Twitter's API:

http://www.scripting.com/stories/2008/07/18/identicaImplementsTheTwitt.html

The docs are here:

http://laconi.ca/Main/Twitter-compatibleAPI

What's useful to note about this, like the Delicious API, is that there is value in brain-dead APIs like this that we can commoditize once they've achieved enough traction. This means that all the existing apps out there that work with Twitter today can be tweaked to work with any Twitter API-compatible endpoint... so if you advertise such an endpoint your XRDS-Simple discovery profile, and sign in with or point to that document, the client application should work, automagically.

One deep problem with the Twitter API, however, is its lack of support for OAuth:

As with Twitter, the API uses HTTP Basic Authentication. Note that this means that users with only an OpenID login cannot use the API; they have to add a password to their account using the control panel on the site. 

This is a major downer, but at least we have compatibility and can work on this problem over time (you'll note that OAuth was originally developed to solve this very problem with the Twitter API! Gah!).

The gotcha section in the docs are particularly interesting, because they quickly point to problems with decentralized social networks, where usernames are no longer useful as GUIDs... (so your @replies might not actually go to the person you intended to talk to). It'll be curious, now that we have this API, to see how these kinds of problems can be resolved in a longer term way.

Chris

--
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is: [ ] bloggable [X] ask first [ ] private

[Nathan Bell]

> The gotcha section in the docs are particularly interesting, because
> they quickly point to problems with decentralized social networks,
> where usernames are no longer useful as GUIDs... (so your @replies
> might not actually go to the person you intended to talk to). It'll be
> curious, now that we have this API, to see how these kinds of problems
> can be resolved in a longer term way.
>
> Chris

It seems one way to approach this that straddles the
usability/technical-feasibility fence is to treat the nicknames of who
I'm following (or who follows me, or who replied to me) as lookups to
URIs. Smart clients or smart services would allow me (as a user) to
type "@factoryjoe" in my post and grab your URI from my personalized
list and embed that in the protocol/format used for the micro-blog post
(something like "<a href="http://www.twitter.com">@factoryjoe</a> blah
blah blah post text here...". That way other services would know
exactly who I am talking about, but I wouldn't ever need to care what
your full URI is.

[Nathan Bell]

Sorry, in my example I meant to type
<a href="http://twitter.com/factoryjoe">@factoryjoe</a> ....

but you might have assumed that ;)

--
Nathan Bell
Senior Partner; Lead Developer
Intrigo LLC
Mobile: 520 631 6131

[Chris Messina]

That only works if each person only uses one account... curiously you could use full Jabber IDs and hide the domain, as in:

@facto...@twitter.com

would become

@factoryjoe

And if there's a link, you could mouseover to see the domain of the person...

Yes/no?

Chris

[Nathan Bell]

Yeah that would work, too. It seems like it's two questions really,
what happens in the format/protocol and what happens in the interface?

I assume there's no way around including fully qualified (globally
unique) user ids in the format/protocol. If that's true, it's up to
each individual client to come up with clever ways of making that easier
for their users.

Maybe that assumption is wrong though?

Chris Messina wrote:
> That only works if each person only uses one account... curiously you
> could use full Jabber IDs and hide the domain, as in:
>

> @facto...@twitter.com <mailto:facto...@twitter.com>

> factoryjoe.com <http://factoryjoe.com> # diso-project.org
> <http://diso-project.org>
> citizenagency.com <http://citizenagency.com> # vidoop.com
> <http://vidoop.com>

> This email is: [ ] bloggable [X] ask first [ ] private
>
> >

--
Nathan Bell
Partner; Special Projects

[Steve Ivy]

In a conversation with Evan, he told me that there is a hierarchy to
figuring out where an @reply goes:

* If you follow a remote user by that username, link that
* If there's a local user by that username, link that

I don't know about linking to remote users you don't follow. Evan,
have I got this right?

--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Chris Messina]

Obviously doing a look-up in the context of the poster's friend makes the most sense... for example, (I'll pull this example out of my ass), say there are two "redmonks", one on Identi.ca and one on Twitter. If I follow the the redmonk on Twitter but see @redmonk on Identi.ca which was intended for the non-Twitter redmonk user, you can see how this problem is easier to solve when considered from the point of view of the original poster.

So, as in OpenSocial, this demands the distinction of "owner" and "viewer"... The owner or original poster knows which @redmonk they're replying to; the viewer may not, associating the @redmonk they're familiar with with the username. So this is a little more tricky.

I mean, it might be lame and burdensome, but it's conceivable that we could prefix the username with a favicon from the intended user's context... still better, and less obtrusive, would be linking to the intended friend's profile, wherever it might exist -- suggesting that in places where rich UIs are available (i.e. with javascript), when you begin to type @... you get a type-ahead box of your friends' names... And when you create a link, it's a human friendly name, as in "@Steve Ivy"...

Perhaps the problem is that Twitter has taught us to replace real names with usernames -- but I think we can do better. Thoughts?

Chris

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com

[Steve Ivy]

I actually have a UI mockup that relates:

http://flickr.com/photos/redmonk/2261368892/in/set-72157603899426561/

I could see this being used to show the user's real name, remote site, etc.

[Nathan Bell]

This is the behavior I personally prefer in rich environments (using a
selector with real names). I actually really like Facebook's full name
friend selector that they use in their search box, it's my primary mode
of navigating their site.

But if we're talking about distributed microblogging then these UI ideas
aren't mutually exclusive, right? Especially as long as the underlying
format always specifies a URI. I agree with Chris that it's the "owner"
and not the "viewer" that should decide which fully-qualified user
they're addressing to ensure there's no ambiguity on the viewer's side.

So how does that model differ from what's possible with
identi.ca/laconica? Can users meaningfully inject URI's into their
@replies? Does the underlying format used allow <a/> links?

[Matthew Terenzio]

It's an interesting discusion. On http://twitter.im I aggregate Identi.ca and Twitter posts and assume the @user is is from the context of the incoming post.

My outgoing posts however get sent to both services and that is confusing since @hardaway is not the same person in both services and yet they are treated as relative when the posts get displayed on either.

My only guess from the client perspective is that you need to explicity reply to a post so that the context and thread are understood, but that doesn't even begin to solve the problem since the @replies convention is even used to start a conversation with someone.

The answer? @username sucks and should be abandoned.

The real life answer? Clients do a best guess and maybe even display ambiguities when they are present but realize that they will fail some small percentage of the time.

HTML wasn't perfect. RSS was far from perfect. But I love 'em.