ShiftSpace groups and permissions

0 views
Skip to first unread message

Mushon | Shual.com

unread,
Apr 14, 2008, 10:29:34 AM4/14/08
to Shift...@googlegroups.com

Here is the second proposal posted by the newcomer Michael van Schaik and worth of discussion here on the discussion list:


- Design & implement group-structure for collaborations / interactions;
In order to collaborate, users should be able to form groups that can
work together on trails & shifts. Shifts could then be owned by users
and groups, and have permissions set for this like the unix-file
permissions? (owner-group-others: read, edit)
  

What do you guys think?
--

Mushon Zer-Aviv | ע Shual.com - design studio |§ ShiftSpace.org - an opensource layer above any website | +  1-646-283-6057

Mushon | Shual.com

unread,
Apr 15, 2008, 10:15:32 AM4/15/08
to Shift...@googlegroups.com

This is a very interesting idea. The permission model have proved itself well in server level viewing/editing and might work for us here too.

What I am asking myself here is about yet another issue...

We might not want to exclude users from viewing something but would like to address specific users/groups.

Meaning, if in a public space like the subway I am talking to a friend, I might choose to either whisper in her ear or talk in a way that others can listen on if they want. Either way my communication is contextualized by the fact I addressed someone specific and whoever might listen in would know they are not prohibited from listening but might just not find it necessarily interesting. This addressing thing should obviously be emphasized in the interface (both in authoring and in browsing shifts).


So shifts might have 6 levels of relevancy for me as a 'reader':

  1. Invisible - I am prohibited from viewing the shift
  2. Not for me - I am allowed to view the shift but it was not addressed at me.
  3. General - this is a general shift to the wide § user base
  4. For my Group - the shift was addressed at a group I'm a part of.
  5. For me personally - This one was aimed for me, probably a friend believes I might find it relevant (while others might or might not be excluded from viewing it)
  6. Private - Only I can see this shift, a note to self of sorts, or a shift draft.
I think we can make the notifier emphasize these levels of relevancies and by that make shift making a more meaningful communication tool.


Apart from that, I like the idea of group editing of shifts but it might work well with building a whole wiki functionality around it. I currently think group editing is a bit further down the line, while getting addressing, group viewing and shifts comments makes more sense as an earlier step.


more thoughts?

Mushon Zer-Aviv | ע Shual.com - design studio |§ ShiftSpace.org - an opensource layer above any website | +  1-646-283-6057

Michael van Schaik

unread,
Apr 17, 2008, 11:19:08 AM4/17/08
to Shift...@googlegroups.com
I like the example of whispering, whispering could be like talking to a
specific group, others can hear but they know it's not necessarily meant
for them;
In blogging & CMS systems you also see these kinds of solutions; levels
of users with each their own privileges. Still, the Unix-file
permissions might be one of the simplest solutions;

So; if we would have a shift 'myShift' the attributes for it could be:
owner: me
groups: myGroup
permissions for: owner, groups, others

0=none
1=read
2=read/edit

then, taking your scheme;


> Invisible - I am prohibited from viewing the shift

(I'm not in the group, nor owner so 'others'=0)


> Not for me - I am allowed to view the shift but it was not
> addressed at me.

(I'm not in the group, nor owner so 'others'=1)


> General - this is a general shift to the wide § user base

(others=2)


> For my Group - the shift was addressed at a group I'm a part
> of.

(group=2)


> For me personally - This one was aimed for me, probably a
> friend believes I might find it relevant (while others might
> or might not be excluded from viewing it)

(others=1)


> Private - Only I can see this shift, a note to self of sorts,
> or a shift draft.

(group=0, others=0)

I see here that it might seem necessary to create a possibility to
'flag' a post for a specific person or group, but that is not something
I think should be part of the permissions. If we think about ShiftSpace
as an architecture, like the www is, the functionality to tell someone
about a relevant website is not part of the website itself, but done
through eg. e-mail.

Analogue to the classical setup that governs the internet, a shift could
only have 1 group, if others can read the shift the can copy it to their
own shifts and become owner of that copy. Then assign a different group
to the copy.

If we however want to try and embrace a more liberal decentral structure
like the internet was initially envisioned we could have a wiki-style of
editing shifts if 'others' is set to read/edit (2). Then, if a shift is
part of two trails, and edited by one; it will also change for the other
trail.


On Tue, 2008-04-15 at 10:15 -0400, Mushon | Shual.com wrote:
> This is a very interesting idea. The permission model have proved
> itself well in server level viewing/editing and might work for us here
> too.
>
> What I am asking myself here is about yet another issue...
>
> We might not want to exclude users from viewing something but would
> like to address specific users/groups.
>
> Meaning, if in a public space like the subway I am talking to a
> friend, I might choose to either whisper in her ear or talk in a way
> that others can listen on if they want. Either way my communication is
> contextualized by the fact I addressed someone specific and whoever
> might listen in would know they are not prohibited from listening but
> might just not find it necessarily interesting. This addressing thing
> should obviously be emphasized in the interface (both in authoring and
> in browsing shifts).
>
>
> So shifts might have 6 levels of relevancy for me as a 'reader':
>

> 1. Invisible - I am prohibited from viewing the shift
> 2. Not for me - I am allowed to view the shift but it was not
> addressed at me.
> 3. General - this is a general shift to the wide § user base
> 4. For my Group - the shift was addressed at a group I'm a part
> of.
> 5. For me personally - This one was aimed for me, probably a


> friend believes I might find it relevant (while others might
> or might not be excluded from viewing it)

> 6. Private - Only I can see this shift, a note to self of sorts,


> or a shift draft.
> I think we can make the notifier emphasize these levels of relevancies
> and by that make shift making a more meaningful communication tool.
>
>
>
> Apart from that, I like the idea of group editing of shifts but it
> might work well with building a whole wiki functionality around it. I
> currently think group editing is a bit further down the line, while
> getting addressing, group viewing and shifts comments makes more sense
> as an earlier step.
>
>
> more thoughts?
>
>

> Mushon Zer-Aviv | ע Shual.com - design studio |§


> ShiftSpace.org - an opensource layer above any website |
> + 1-646-283-6057
>
>
>
>
> Mushon | Shual.com wrote:
>
>
> > Here is the second proposal posted by the newcomer Michael van
> > Schaik and worth of discussion here on the discussion list:
> >
> >
> > - Design & implement group-structure for collaborations / interactions;
> > In order to collaborate, users should be able to form groups that can
> > work together on trails & shifts. Shifts could then be owned by users
> > and groups, and have permissions set for this like the unix-file
> > permissions? (owner-group-others: read, edit)
> >
> >
> > What do you guys think?
> > --
> >
> >

> > Mushon Zer-Aviv | ע Shual.com - design studio |§

Dan Phiffer

unread,
Apr 18, 2008, 1:08:38 PM4/18/08
to Shift...@googlegroups.com

On Apr 17, 2008, at 11:19 AM, Michael van Schaik wrote:

> I see here that it might seem necessary to create a possibility to
> 'flag' a post for a specific person or group, but that is not
> something
> I think should be part of the permissions.

Yeah, I agree with this. I like both ideas (Unix-style permissions &
gradients of addressability). They are both familiar, simple, and
would provide some badly needed tools for cooperation within §.

-Dan

an

unread,
Apr 20, 2008, 3:12:18 PM4/20/08
to ShiftSpace

Hi,

>
> So; if we would have a shift 'myShift' the attributes for it could be:
> owner: me
> groups: myGroup
> permissions for: owner, groups, others
>
> 0=none
> 1=read
> 2=read/edit

Yes, I definitely like the idea of the Unix-permissions!!
In order to make the distinction between reading a shift, leaving a
comment and use the shift to 'deviate' the trail, it might even be
helpful to opt for the complete unix-permissions:

1 --x execute (leave comments on existing shifts)
2 -w- write (copy/edit/make new trail)
3 -wx write and execute
4 r-- read
5 r-x read and execute
6 rw- read and write
7 rwx read, write and execute


This only makes sense when the comments on shifts are visually
different to shifts that are part of a trail.
And the '0' permission could then be the 'execute only' permission,
which would mean something like seeing/knowing there is a trail, see
what it looks like, but not being able to read the shifts.


So, the permissions are given to the shifts in the same way as they
are given to files in unix (UserGroupOthers), this allows a more
complex use of the shift, because for each shift you can decide
whether it is destined to be seen/read/edited by you/your group/public

>
> then, taking your scheme;> Invisible - I am prohibited from viewing the shift
>
> (I'm not in the group, nor owner so 'others'=0)>

771 or (741 etc)


Not for me - I am allowed to view the shift but it was not
> > addressed at me.
>
> (I'm not in the group, nor owner so 'others'=1)>

774 (or 744 etc)


General - this is a general shift to the wide § user base
> (others=2)

777

> > For my Group - the shift was addressed at a group I'm a part
> > of.
> (group=2)

771


> > For me personally - This one was aimed for me, probably a
> > friend believes I might find it relevant (while others might
> > or might not be excluded from viewing it)
> (others=1)

741

> > Private - Only I can see this shift, a note to self of sorts,
> > or a shift draft.
>
> (group=0, others=0)

711


Best, An

Mushon | Shual.com

unread,
Apr 28, 2008, 5:12:58 PM4/28/08
to Shift...@googlegroups.com

I have discussed it off list with An and Michael (separately), recapping and mainly musing on here.


I think the unix permissions paradigm is a useful one to a certain degree.

As long as we know who we mean by 'group' it works, but we might have multiple groups and then things become more complicated.


I think that before we run to open every aspect of shiftspace, we need to make sense of what we have.

IMHO I believe the current communication model that ShiftSpace offers is flawed as while it does a great job of announcing to whoever wants to listen, it is not very useful when it comes to discussion. For example:

  • I read a shift on the page www.dotnyc.net, which attempted to simply forward users to a more useful url: www.connectingnyc.org
  • I used the opportunity (since I have something to say about the initiative discussed in these pages) and decided to comment to this user, whose obviously a supporter of the initiative.
  • In the abscence of any other tool, I left another note on that same page with my thoughts.
  • End of story.
Two users, each shouted into the desert of the metaweb. One shouted back, the first never heard, end of story.
Why did this interaction fail? Lack of context.

If ShiftSpace is a way for people to shout into the great wide open it repeats the paradigm of web1.0 only with less users.
If ShiftSpace is a way for people to interact on their own terms (/with their own interfaces) in the context of ground-web (as the opposite of metaweb) then we need this interaction scenario to work. Ideally:
  • userA leaves a shift on www.dotnyc.net
  • userB comments on the shift in a way that emphasizes the comment in the context of the original shift
  • userA is notified that her shift attracted a response and views it
  • userA chooses to comment to userB's comment
  • userB is informed of the continuation of the thread
  • ...
Moreover:
  • UserC, userD & userE are informed of a discussion going on on top of www.dotnyc.net in the context of userA's shift
  • Figuring that if a discussion happens, an interest might exist there, they read the thread
  • userC & userE read and move on.
  • userD adds her 2 cents
Moreover:
  • userB in response to userD leaves another shift on another page (lets say a highlight on this page: http://www.icann.org/announcements/announcement-04apr08.htm)
  • userB also notes in the discussion thread started by userA's shift that she added a shift comment to the thread
  • userA & userD check userB's new shift and continue the same thread over at the page under icann.org
  • The full thread (including references to the different shifts) is available from both pages
  • Optionally: a trail is drawn between these two pages consisting of these two shifts
Your thoughts, comments, objections, rejections, love, flowers and puzzled sighs will be highly appreciated.

cheers,

Mushon Zer-Aviv | ע Shual.com - design studio |§ ShiftSpace.org - an opensource layer above any website | +  1-646-283-6057



an wrote:

711


Best, An

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "ShiftSpace" group.
To post to this group, send email to Shift...@googlegroups.com
To unsubscribe from this group, send email to ShiftSpace-...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/ShiftSpace?hl=en
-~----------~----~----~----~------~----~------~--~---


  

Dan Phiffer

unread,
Apr 28, 2008, 9:35:18 PM4/28/08
to Shift...@googlegroups.com
I had another off-list discussion with Mushon and we agree that both
permissions and communication tools (comments, notification,
subscriptions) are important, but we just need to prioritize. Here's
how I think we should approach these:

1. First priority is communication tools, to make Mushon's use case
possible
2. Second is controlling visibility to a greater extent (restricting
read access in new ways)
3. Third is collaborative tools (expanding write access in new ways)

Permissions done in the Unix style could potentially hit 2 & 3 in one
shot, but the main point is we should focus first on the communication-
oriented stuff. I don't know about the multiple groups thing -- sounds
like it'd be more trouble than it's worth.

Thoughts?

-Dan

> Mushon Zer-Aviv | <shual_icon.gif> Shual.com - design studio |
> <shiftspace_icon.gif> ShiftSpace.org - an opensource layer above any

Doron Ben Avraham

unread,
Apr 28, 2008, 10:22:35 PM4/28/08
to Shift...@googlegroups.com
Permission function ala unix sound like a great idea and they can offer
a solution to some of the point Mushon makes.
here is my kill joy notes however.
i am concerned that our underlaying structure is flawed, mainly due to
the well established problem that our database is a single centralized
system.
basically we can go dark and off the web at any given moment, adding
features that make the data more versatile and relevant (conversations
etc..) on this architecture is problematic, since its not resilient.

Right now the data elements are pretty basic, so if we face the very
serious task of trying to create a distributed model of the db, i think
it will be easier for us to tackle this problem with current entries,
tools and spaces. If we create a permission system prior to the
distributed model, i suspect we will have to backtrack allot in order to
solve the issue of data integrity and permissions on the distributed model.

We wouldnt want to cut off features for the sake of reliability, rather
we would want to build the features on top of a better structure.
IMHO we need to polish all the elements we have for 0.11 possibly
perfect them to 0.12 and start working on the distribution issue

Im a paranoid minority so forgive me :)

D

Dan Phiffer

unread,
Apr 30, 2008, 11:50:41 AM4/30/08
to Shift...@googlegroups.com
I think Doron makes a good point. I'm interested in decentralizing
earlier than later, but so far we've discussed it as something in the
distant future. Maybe we should consider it for 0.12? We've talked
before about CouchDB, which is a promising choice, but it's probably
still not quite ready. Another choice I've been exploring more
recently is Jabber. I think it can fulfill a lot of the same
requirements as CiouchDB, but in a software package that is more mature.

In any case, yeah, let's put these discussions on hold until we get
0.11 out the door and the new server is operational. I'm about to head
out to Eyebeam for the hacking session today, which I think will be a
good one.

-Dan

Dan Phiffer

unread,
Apr 30, 2008, 11:52:45 AM4/30/08
to Shift...@googlegroups.com

On Apr 30, 2008, at 11:50 AM, Dan Phiffer wrote:

> Another choice I've been exploring more
> recently is Jabber.

Oops, I mean ejabberd -- Jabber is the protocol, not the software
package.

Reply all
Reply to author
Forward
0 new messages