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
