Regarding the webfinger idea - there's gravatar.com. There are a lot of advantages in using such public shared profile services as gravatar. A user only needs to register - and all his public profile details become available instantly exactly in the format he desires. For businesses it would allow relatively easy option to integrate existing profiles - they would just need to host their own gravatar like web server that would serve profiles. The URL of the "gravatar" like server would be configurable in server startup properties. So this way user should provide on registration only the userid and email address.
2010/12/13 Zachary Jones <keystonef...@gmail.com> > Perhaps the profile could have a record of 'adopted' waves (informally > moderated / active participant). > > A simple wave_adopted table as > wave_id > user_id > date_adopted (could double as a sort column, or make one specifically) > > I'm thinking of this for long-running waves that serve as documentation – > e.g. the proposed development wave(s) for this discussion list. > > This element would provide web structure in a similar format to the link > block in a blog, but provide weight more akin to the follow/friend list > (twitter, fb, etc). Beyond these, additional behavioral data could be > derived regarding activity in 'adopted' waves. > > > Zak > > > > > On Dec 12, 2010, at 3:32 PM, Michael MacFadden wrote: > > Hmm that is an interesting idea, I will go take a look at this >> infrastructure. I definitely think that the account information will be >> abstracted away such that the account store / service is pluggable so that >> we could hook up to just a service like this, or an organizations existing >> infrastructure. Again I think we will need a separate thread on how user >> profile information should work across federated servers. >> >> Still just trying to build the view of what we think the information in a >> profile should be. >> >> ~Michael >> >> On Dec 12, 2010, at 2:27 PM, Soren Lassen wrote: >> >> 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 >>>> >>> >> >
