- From: Michiel de Jong <michiel@unhosted.org>
- Date: Sat, 7 Jul 2012 19:05:39 +0300
- To: Melvin Carvalho <melvincarvalho@gmail.com>
- Cc: Flemming Bjerke <web@bjerke.dk>, public-fedsocweb@w3.org
On Sat, Jul 7, 2012 at 5:22 PM, Michiel de Jong <michiel@unhosted.org> wrote: > 1 - it must be a scheme that given some sort of human-memorable ASCII > string, always produces the same structured data object. > 2 - the human-memorable ASCII string should be understood by users to > have a one-to-one mapping to online identities > 3 - there should be no centralized control on minting these strings, > other than DNS which we are sort of bound to already any way, by > virtue of being on the web. > 4 - the person who operates a specific online identity, or (in case > DNS is used) the sysadmin of the domain this online identity belongs > to should have control over the contents of said structured data > object. > > So facebook open graph does 1, 2 and 4, but not 3, so it doesn't > qualify as an alternative to webfinger. > You could use URLs of foaf documents directly or in client-side certs, > which would satisfy constraints 2,3 and 4, but not constraint 1. actually, i should be more specific there - http URLs do, strictly speaking, qualify as human-memorable ASCII strings, and can be understood to map one-to-one to online identities, but http://host/can/be/any/path is simply harder to remember and use than user@host. That is why webfinger was invented. So should probably mention the option of http-based identity separately. then the options are to identify users on fedsocweb by: - no universal scheme, each silo use its own system (i wouldn't recommend this) - http URLs (i wouldn't recommend this) - xmpp disco (that's an option i would say) - webfinger (would be my preference). Melvin, which one would you think is the best path to a successful fedsocweb? do you see more options than these?
Received on Saturday, 7 July 2012 16:06:07 UTC