Re: Question: User Story -- Bootstrapping Facebook

On Thu, Feb 10, 2011 at 4:58 AM, Nathan <> wrote:

> Melvin Carvalho wrote:
>> This is my question.  Is it a problem that they dont currently use
>> fragments.  And can we easily can get around that?
> It's probably the least significant of all the problems tbh, strictly for
> webid all we need to do is prove that somebody had/has write access to the
> "resource", so regardless of whether somebody uses /profile or /profile#me,
> in both cases you'll be looking to see if the persons public key is in
> /profile.

You're making the assumption that each profile document only contains data
about one person, which might be the case for FB, but you can't generalize
this, and the spec cannot contain special casing for FB (how about some URL
regex?). What about pages which contain identity about several people? frags
are there for a reason, I don't think we can just ignore them. If I manage
to leave my public key as a comment on your FB profile page, I can now steal
your identity, right? Profile pages are not necessarily static HTML document
which only the user has access too. In systems like FB, Twitter, or CMS in
general, data is pulled from different places and you have to make sure you
know who authored each snippet of it. That was one of the main concerns
David Recordon and his team raised when I visited them in Palo Alto last
year. The use case we were discussing was about the Web in general wrt
harvesting data for OGP, and the reason why OGP/FB will only consider the
RDFa located in the <head> tag is that it's the only data they can trust to
be authored by the author of the page (or the app), anything else on the
page cannot be trusted and could be a comment left by some random person who
would change the title of the page for example with some well crafted RDFa.
It was not about WebID or how they put their pages together, but I bet they
would raise the same points re. their profile pages.

> <snip>

> Another potential issue, is that sites like facebook don't have "one uri"
> for each person, each person can have several different ones, basically
> whatever is in the address bar when that person is looking at their own
> profile.

Who cares as long as they advertise a unique profile URI in all these pages,
and as long the canonical profile URI dereferences to the right WebID

> It could be worse though, look at twitters URIs for users..
>!/webr3 that would lead to a GET on
> for every user on twitter.

again, no problem, as long as the advertised URI for user profile is The /#!/ is just some javascript sugar, if you
access as anonymous with js off you will see that
you remain on (which is the behavior that a WebID
Verification agent would experience).


> Back to facebook, there are just so many questions - could a user ever add
> their own "webid information" (public key for instance) to their own profile
> page? publicly? in a machine readable consistent way? would facebook block
> it? would facebook add it? would they require open graph? would they only
> show it to identified / signed in sessions? etc.
> Ultimately, there are three questions for facebook here:
>  - would you ever allow users to sign in to facebook using webid(s)?
>  - would you ever allow people to use their facebook uri as a webid?
>  - would you publish users profile data (subject to their privacy settings)
> in a machine readable way, at the profile uri?
> In the meantime though, we can identify what steps facebook would have to
> take to adopt and support WebID fully, without any input from them, and see
> just how easy it would be for them ("not very" would be my opinion on it!).
> Likewise for other sites, is it even possible for them to adopt without
> changing their platform and deployed systems? (Twitters URIs effectively
> means "probably not", likewise facebooks privacy and custom auth* solutions
> + various apis).
> However..
>  I cant comment on why they built their platform the way they did, what
>> they will roll out in future, or in what time line.
>> But I'm interested in the short medium term, to see how easily
>> compatible WebID is with their EXISTING setup?
> If we ask the question "why would somebody want to use their facebook uri
> as a webid?", about the only answer I can come up with is so as to re-use
> their (public) profile information.
> One potentially very fast way to do this is to create a quick service which
> dumps out foaf for each user, gives them a uri and let's them get a webid,
> say something like . Although a service which did this and
> imported info from any number of services (google profiles, yahoo profles,
> twitter, facebook, myspace etc) may be more useful for everyone, i dunno
> something like would be sweet for this.. (.. .....
> ... ... .!!)
>  Right now everyone is developing for the FB platform due to the
>> network effect.  If we can have a hybrid system that easily manages
>> WebID and Facebook account, I can see people using it (I would at
>> least).
> Indeed, we make a hybrid system then :) Unsure if managing a facebook
> account it required, not simply import from the facebook account..?
>  Sorry, there are just too many hypotheticals in your question to make it
>>> possible to give any clear answer. There are many simple solutions to their
>>> problem. They could use redirects for example, if they don't like # urls.
>>> If they are interested in WebID, perhaps we should invite them directly,
>>> then we could answer their questions with more context....
>> I think they would be good people to talk to, yes, if it's possible to
>> get them more interested.  It's the dominant social eco system on the
>> web.  I know from SWXG telecons that David Recordan has at least heard
>> of WebID, so that's a start...
> Fully agree, we have to ask people what their requirements are from webid,
> and what restrictions they'd place on implementing/adopting/supporting
> webid. The people who the SWXG spoke to, like David Recordan, are the key
> people we need to be discussing things with.
> Best,
> Nathan

Received on Thursday, 10 February 2011 13:48:56 UTC