DiSo Groups

[Chris Messina]

Following on my last email, I want to bring up the subject of DiSo Groups -- or ad-hoc collections of folks coming together to do something collectively...! ;)

We started a brainstorming page on the wiki for this:

http://diso-project.org/wiki/groups-brainstorming

I'd be interested in other people's thoughts on how to make Groups work from a distributed perspective. Like OpenID works for People, I think we need to move to a model of canonical groups... meaning that the "NIN Group" should probably live on NIN.com... and it pulls in services and content from remote sites, but that people JOIN the ONE TRUE GROUP on one (or more) domain where member lists are federated.

I think XMPP has a model for this, but I'd like to lead with conceptual use cases... For example, if you're collaborating with a team on a documentation project, and you're using screenshots, screencasts, a wiki, file attachments, but you're all using slightly different technology or services... how would you be able to bring all your content from different sources into one central location, where the only requirement was that members had to sign in with their OpenID and then authorize the group site to push activities back to their ActivityStreamAggregator?

Chris

--
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
factoryjoe.com # citizenagency.com # diso-project.org
This email is: [ ] bloggable [X] ask first [ ] private

[Josh Patterson]

I'm not sure if this is the same thing, but I've often wondered about
using an openID-like decentralized group to power a permission system;
ie, "My Family" is a group, and they can view this album of photos.
The auth process might be different in that the user would have to be
authenticated as a member of that group, and then the permission
system would have to recognize that. Maybe this can already be done,
I'm not quite sure.

Josh

On May 14, 1:49 pm, "Chris Messina" <chris.mess...@gmail.com> wrote:
> Following on my last email, I want to bring up the subject of DiSo Groups --
> or ad-hoc collections of folks coming together to do something
> collectively...! ;)
> We started a brainstorming page on the wiki for this:
>

> <http://diso-project.org/wiki/groups-brainstorming>http://diso-project.org/wiki/groups-brainstorming

[Steve Ivy]

Conceivably, a group-implementing site might implement Oauth, so that
members of that group can be given access to protected assets outside
the group site...

--
Steve Ivy
http://redmonk.net // http://diso-project.org
This email is: [ ] bloggable [x] ask first [ ] private

[Josh Patterson]

It also might be brought up for consideration in DiSo, along these
same lines, for the ability to use the XFN data that defines the
relationships as a basis for inferring permissions;

ie: "Share this photo set with only my immediate family", and have
openID, groups, and OAuth work that out in terms of detecting the
relationship, checking the group status, etc, and then allowing the
access.

Josh

> Steve Ivyhttp://redmonk.net//http://diso-project.org

[Chris Messina]

On Wed, May 14, 2008 at 12:04 PM, Josh Patterson <jpatt...@floe.tv> wrote:

It also might be brought up for consideration in DiSo, along these
same lines, for the ability to use the XFN data that defines the
relationships as a basis for inferring permissions;

I'm generally -1 on this idea because XFN semantics aren't necessarily portable. What is a "friend" in one context may not be a "friend" in another. 

For example, all contacts on Metafilter are marked as "colleague". If I imported my "colleagues" to LinkedIN, I don't think I'd want them treated as "colleagues" in the LinkedIN sense. See what I mean?

I'm more in favor of personal tag groups -- which may overlap with XFN -- but really help people make better decisions about how to broker access to certain groups/sets of people (see Pownce).

ie: "Share this photo set with only my immediate family", and have
openID, groups, and OAuth work that out in terms of detecting the
relationship, checking the group status, etc, and then allowing the
access.

Yes, I would use OAuth for this, or a set of whitelists, which the admin(s) (i.e. creator) of the group could set up. You could certainly create portable permissions lists, but we just haven't defined how yet -- maybe a XOXO list of URL identifiers?

Chris

factoryjoe.com # diso-project.org
citizenagency.com# vidoop.com

[Joseph Holsten]

If you intend to have group members queriable through a service,
please use this:
http://wiki.openid.net/Group_Membership_Protocol

For creating feed planets, image pools, or action rivers, I'd recomend
using gmp enumerate behind oauth to find the identities of members,
then xrds or manual scanning for services and usable data. (here xfn
is okay, if semanticly awkward, & xmpp is bad)

But there are many uses where you just want to know if someone is a
member, & don't deserve to know the entire list of members. gmp also
handles this. (this is where xmpp is good, xfn is bad)

Beware, I don't know that anyone besides livejournal is using the
protocol. It reinvents a number of things. But it is extremely
minimal. We might be able to reinvigorate the protocol (make it a real
boy^H^H^Hstandard) and align it with other needs.

http:// Joseph Holsten .com

[Steve Ivy]

Looks interesting to me. How does this win over portable contact
lists? Perhaps that it can optionally be protected via oauth?

--
Steve Ivy
http://redmonk.net // http://diso-project.org

[Stephen Paul Weber]

On Wed, May 14, 2008 at 5:37 PM, Joseph Holsten
<jos...@josephholsten.com> wrote:
>
> If you intend to have group members queriable through a service,
> please use this:
> http://wiki.openid.net/Group_Membership_Protocol

Or just rel=member ?

--
- Stephen Paul Weber (Singpolyma)

Web: http://singpolyma.net/
Twitter: http://twitter.com/singpolyma
IM: singp...@gmail.com

--
- Stephen Paul Weber (Singpolyma)

Web: http://singpolyma.net/
Twitter: http://twitter.com/singpolyma
IM: singp...@gmail.com

[Joseph Holsten]

Steve Ivy wrote:
> Looks interesting to me. How does this win over portable contact
> lists? Perhaps that it can optionally be protected via oauth?

It's over http, so why not?

[Joseph Holsten]

Stephen Paul Weber wrote:

> Joseph Holsten wrote:
>> If you intend to have group members queriable through a service,
>> please use this:
>> http://wiki.openid.net/Group_Membership_Protocol
> Or just rel=member ?

Blackbox Querying. You can say if an id is a member without saying
every member of the group. If you don't need that, it's overkill
rel=member+oath ftw. If you need it, you've got to have it.

One use case: flickr want to know if I'm authorized to view your photo
pool. I authenticate via oauth, it believes I really represent my
identifier. Flickr then queries your "Allowed to see me in a bathing
suit" group to find out if I am allowed to see you pasty and
sunburned. Flickr isn't entitled to know everyone on that list. Since
the response is affirmative, I finish oauth and am granted access.

What openid is to your username & password, gmp lets you do with friends lists.

But again, don't waste your time just for the full list. rel=member is _fine_

PS I suck at http://five.sentenc.es