I was reading about webfinger (http://webfinger.googlecode.com, http://webfinger.org recently and it occurred to me that we could consider using that protocol for serving profile data and for discovering profile data. That way a client can look up the profile data for each address that it sees by going straight to each address's domain, thus potentially obviating the need for a mechanism for federating profile data between providers.
Maybe we can even use existing solutions (I don't know what they are) to export profile data with webfinger for existing user stores. Soren On Mon, Dec 13, 2010 at 9:05 AM, Michael MacFadden <michael.macfad...@gmail.com> wrote: > All, > > I am thinking of adding some functionality around user profiles. There are > two main thrusts in the functionality. The first is implementing some user > account / profile API with some sort of pluggable architecture such that the > account profiles could be hooked up to an organizations exiting user store. > The second would be implementing a basic self contained instance for out of > the box functionality. > > The question I have for every one is what information should be in the user > profile. Right now all we have in the Profile API is: > > - Address / User Id > - First Name > - Full Name > - Avatar Image URL > > > I was thinking that to start off we would have: > > - User Id > - First Name > - Last Name > - External Avatar Image (link to an external image) or > - Internal Avatar Image (image uploaded by the user) > - Email Address (assuming we still want email integration) > > Along the way, I would be adding a "My Account" or "My Profile" page. Just > looking for some design input. Thanks. > > ~Michael
