portablecontacts-unofficial: PortableContacts for Facebook and Twitter

[Ryan B]

hi all! i've just finished and posted a little side project:

https://github.com/snarfed/portablecontacts-unofficial
http://snarfed.org/2012-02-22_portablecontacts-for-facebook-and-twitter

From the blog post:

"I've just published portablecontacts-unofficial, a stand-in
PortableContacts server for major sites that don't implement it
themselves. It currently has implementations for Facebook and
Twitter, deployed at these endpoints:

http://facebook-poco.appspot.com/
http://twitter-poco.appspot.com/

They complement the unofficial WebFinger providers
(http://snarfed.org/2012-01-16_webfinger_for_facebook_and_twitter )
I published last month, which I've updated to include Link elements
pointing to the new PortableContacts endpoints.

Both are just little side projects, and they may not be hugely
useful on their own, but together they're another step toward
implementing OStatus bridge apps
(http://snarfed.org/2011-07-27_facebook_app_for_ostatus ) for
more of the major social networking sites.

Feedback and pull requests are welcome!"

here are example links to plaxo's poco test client that consume output from
these two sites:

http://is.gd/xME355 (facebook)
http://is.gd/OB3SnV (twitter)

--
http://snarfed.org/

[Joseph Smarr]

Looks great! This is something we've wanted for a long time, and your implementation looks really clean and easy to extend over time. Thanks for taking the time to build this and write it up!

Next step is to build some useful tools that consume PoCo data, and let people hook up all the sources they use in the real world--natively if available, and via these proxies otherwise. :)

--
http://snarfed.org/

--
You received this message because you are subscribed to the Google Groups "PortableContacts" group.
To post to this group, send email to portable...@googlegroups.com.
To unsubscribe from this group, send email to portablecontac...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/portablecontacts?hl=en.

[Tom Holder]

I tied this in to our new product (which has a POCO compliant API on
it), took me 20 minutes :) awesome.

Really great to see more movement with POCO.

Will try and give something back to this project as soon as possible.

Tom

On Feb 22, 8:25 pm, Ryan B <goo...@ryanb.org> wrote:
> hi all! i've just finished and posted a little side project:
>

> https://github.com/snarfed/portablecontacts-unofficialhttp://snarfed.org/2012-02-22_portablecontacts-for-facebook-and-twitter

>
> From the blog post:
>
> "I've just published portablecontacts-unofficial, a stand-in
> PortableContacts server for major sites that don't implement it
> themselves. It currently has implementations for Facebook and
> Twitter, deployed at these endpoints:
>
>    http://facebook-poco.appspot.com/
>    http://twitter-poco.appspot.com/
>
> They complement the unofficial WebFinger providers
> (http://snarfed.org/2012-01-16_webfinger_for_facebook_and_twitter)
> I published last month, which I've updated to include Link elements
> pointing to the new PortableContacts endpoints.
>
> Both are just little side projects, and they may not be hugely
> useful on their own, but together they're another step toward
> implementing OStatus bridge apps

> (http://snarfed.org/2011-07-27_facebook_app_for_ostatus) for

[Joseph Smarr]

Cool! Wanna share more about this project of yours? :)

[Tom Holder]

Hi Joseph,

Yeah sure.

We have a product called ContactZilla.com - we're rebuilding using
Poco as the foundation. It's currently built on MySQL and as I know
you're aware, contact data doesn't map very nicely in to a relational
model.

The new version now uses MongoDB which lets us actually store contact
data in Poco format without an manipulation. In fact, our import does
very little validation or manipulation which makes it very fast (a
serious problem we have with the current version).

We are also using sgnodemapper but running it server side in node.js
as part of the add/edit contact pipeline. It seems to work pretty
well.

One of the areas Poco has caused issues is with the account block and
mapping back and forth to social urls (as most people will just paste
in a URL). But, using sgnodemapper we think we've probably sussed it.

It will be a few months before we launch, but it's very open and we
want to make it as easy to get data in and out as possible.

Tom

On Feb 24, 4:56 am, Joseph Smarr <jsm...@gmail.com> wrote:
> Cool! Wanna share more about this project of yours? :)
>
>
>
>
>
>
>
> On Thu, Feb 23, 2012 at 4:50 PM, Tom Holder <tahol...@gmail.com> wrote:
> > I tied this in to our new product (which has a POCO compliant API on
> > it), took me 20 minutes :) awesome.
>
> > Really great to see more movement with POCO.
>
> > Will try and give something back to this project as soon as possible.
>
> > Tom
>
> > On Feb 22, 8:25 pm, Ryan B <goo...@ryanb.org> wrote:
> > > hi all! i've just finished and posted a little side project:
>

> >https://github.com/snarfed/portablecontacts-unofficialhttp://snarfed....

[Joseph Smarr]

You've got it exactly right--the accounts block is meant to mirror SGNs, and sgnodemapper is how you parse normal URLs to figure out what the SGN is (and vice versa).

[Tom Holder]

In my mind, whilst this is good to separate them out, anyone
'consuming' the POCO data needs to use SGN to map to URLs.

It would be good if the spec could allow for the URL to be stored
against the account as well, otherwise everyone needs to sgnodemap and
this might be over kill.

For example, if I was to write an app that just shows me social
accounts for a contact I've got a few options:

1. Sgnodemap and convert in to the URL I need to link for (if
sgnodemap tools were ubiquitous this would be fine).
2. Also store account links in urls plural block and then check domain
and account/id for a match (quite a lot of application level code at
the consumer).
3. Extend spec for accounts block to also support a url.

The third option is what we are opting for, it's the only place we've
broken the spec. Which is a shame, but otherwise our consumers need to
do too much to get logic to get the URLs.

The actual process we're taking behind the scenes is, when a user adds/
edits a contact, we look over the URLs block and where we can map them
with sgnodemapper, we remove the url and convert in to an account.

Tom

[Joseph Smarr]

Just put the URLs in the urls fields that correspond to the accounts values. No need to put a URL in accounts, but it's a good idea to put the corresponding URL in urls if you have it, since as you say it makes consumption easier. The idea is that urls is what you want to read from if you ultimately just want to display a link, whereas accounts is more useful if you want to do account matching (e.g. which of the people I follow on twitter also use site X?) since you don't have to parse the URLs to figure this out. 

We do this for instance in Google's PoCo endpoint--see my public profile data http://www-opensocial.googleusercontent.com/api/people/jsmarr/@self?fields=@all has both accounts and urls for all the links on my profile.

[Tom Holder]

Ok, I guess that will work. But, It means, for example, when I output a list of accounts (and not URLs) I need to also loop over URLs in the background to map to actual web addresses by checking url with a regex for domain for any url that is of type profile.

The only other option is to sgnode map client side which isn't ideal either.

On another issue I notice you have linkText for each url. This doesn't seem to be in draft c? Am I missing something?

Cheers

Tom

[Joseph Smarr]

That's an extra field Google added because they let users put custom link text in when displaying links to other profiles. PoCo lets you add whatever additional fields you want, so this is fine (and it also happens to be a standard field for URLs in OpenSocial, which is wire-aligned with PoCo for the overlapping fields).

[Tom Holder]

Ah ok, that's pretty cool. I can see that being useful.

Tom