+1
On 13 December 2010 17:48, Nathanael Abbotts <nat.abbo...@gmail.com> wrote:
> I know we shouldn't delve into implementation at the moment, but considering
> that profiles will be managed using a Wave(/let) and potentially an Agent,
> It would be a good idea to allow people to make their profile *wave* public,
> allowing anyone to search for public profiles, to meet new people.
> Again, private should be default.
> --
> Nathanael Abbotts
>
> Email: nat.abbo...@gmail.com
> Wave: nat.abbo...@wavewatchers.org
> Twitter: @natabbotts (http://twitter.com/natabbotts)
>
>
>
> On Mon, Dec 13, 2010 at 08:32, Yuri Z <vega...@gmail.com> wrote:
>
>> 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
>> >>>>
>> >>>
>> >>
>> >
>>
>
