Reverse otherme

[Paul Tarjan]

Is there a way to get inbound me links recursively? I'm trying to
build a trust graph that given one page finds the other pages that
link into it with rel="me" recursively.

I would rather not have to call the loopkup API for each node I see on
an edi=1 call.

Thanks
Paul

[bradfitz]

No, that's not supported. You'll have to do multiple requests.

(I'm a little reluctant to add support for that, as it'd only add
complexity and confusion for what I can't imagine being a common
query... I'm not even totally sure what you're wanting to use it
for...)

[Joseph Smarr]

Brad-this came from a conversation that Paul and I had at Mozilla last week. We were talking about how to build up a set of trusted identifiers for a user after they log in with an OpenID (e.g. for building up an online reputation based on activity on multiple sites). The insight was that just using the standard fme=1 outbound rel=me links isn't really what you want, since I could claim to be any profile, but that if you could find all the inbound links, there's less incentive to game the system because why would someone pretend to be me, especially when I'm the one making the ultimate decision about whether to use that profile. But the more I think about it, that doesn't really work by itself either, since random sites could just link to me and I'd have to be able to say which I really trust. So probably the best answer really is to look at bi-directional (or more generally, circular) loops where the links are both outbound and inbound. And IIRC if you do fme=1 then for each of the downstream links, you compute all the downstream links for those nodes too, so you can just iterate through all the returned nodes and see which reference the original node, and that's your set of connected links right?

 

Thanks, js

[Paul Tarjan]

Joeseph hit the nail on the head. Adding a little bit :

I cooked up a YQL call:

http://paulisageek.com/yql-tables/socialgraph/socialgraph.trustsme.xml

http://query.yahooapis.com/v1/public/yql?q=USE%20%27http%3A%2F%2Fpaulisageek.com%2Fyql-tables%2Fsocialgraph%2Fsocialgraph.trustsme.xml%27%3B%20SELECT%20*%20FROM%20socialgraph.trustsme%20WHERE%20q%3D%27http%3A%2F%2Fpaulisageek.com%27&format=xml&env=http%3A%2F%2Fdatatables.org%2Falltables.env

And wrote a little blog entry :
http://blog.paulisageek.com/2009/06/equivalent-openids.html

And posted on stackoverflow (not much discussion) :
http://stackoverflow.com/questions/1054384/openid-equivalence

I personally can solve a lot of these problems with openid delegation
on my own URL, but most people in the world (I assume) will go with an
out of the box default provider (like Yahoo!, or myOpenId, or Google)
and then have the exact same problem as now with email migration and
account management. We're just trying to nip this problem in the bud,
and not end up with the same problems of email equality.

Paul

[Brad Fitzpatrick]

Correct.  A single fme=1 request will return that nodes and each downstream node's transitive closure of "me" nodes, from which you'll be able to find the fully connected subset, the subset which has some me-path to every other node in that subset, be it via a hub-and-spoke topology, a ring, or otherwise.

On Tue, Jun 30, 2009 at 8:07 AM, Joseph Smarr <jsm...@gmail.com> wrote:

[Paul Tarjan]

I don't think outbound transitive closure is what we need for
permission delegation. Rather, it's inbound transitive closure. I
might not link from my blog to my livejournal account, but if my
livejournal links to my blog it is giving permission to my blog. Check
out the "trustsme" api that I made up and see if you agree.

[Brad Fitzpatrick]

Sorry, looks like I never replied to this.  (inbox cleaning day!)

But yes, I can see why fme inbound instead of outbound could be useful.

I'll use the SGAPI's code hosting project to use its issue tracker:

   add fmein=1, like fme=1, but following inbound me links

   http://code.google.com/p/socialgraph-resources/issues/detail?id=2