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.macfadden@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
>
|