sharing and permissions

[Caleb Davis]

There is a mapping between the items in your collection and the
individuals allowed to view them. Those are permissions.

We'll begin implementing these by assigning each media entry an
array of authorized viewers, listed by username. Eventually, these
could be openids for federation, but that's beyond the scope of
this ticket.

Because writing a list each time you submit an item would give us
the blues, we'll have a default list editable by the user. That
list of users will be used to populate the permissions array on the
item.

Now, you may not always want the default list, so it's important to
make it easy to specify which of your 10 million fans get to see
your cat with whip cream on its head. For that, each user will be
able to maintain groups of individuals. These groups can be given
any name. Suggestions would be friends, family, etc. Those will be
enabled by default but can be removed in favor of other group
names.

So, when creating an item, you see an array of labels representing
your default sharing profile. It could be as simple as 'everyone',
or as complex as you like. Modify the sharing labels by adding or
removing individual names, or group names. Individuals and groups
can also be added to specifically exclude, but let's save that for
a future ticket.

When you submit the item the labels are interpreted and converted
to individuals for the item's permissions array.

When called upon for viewing, the item looks up the viewer in its
permissions array and allows viewing or coyly stays hidden,
depending on whether the viewer gets to see the item. This should
apply for every view - galleries, thumbnails, etc.

The fun part is that the groups the user maintains may be flagged
as private. This means you don't have to pull your hair out trying
to be political about who gets to be in which group. Chris's
example is great -

::

    SmoothBro might not show off his "saturday night swingers" group publicly because maybe he doesn't even want people to know about that, esp his parents.

Breathe in. Breathe out. Explore the space!

This ticket does not cover notifications, only viewing
permissions.

[Caleb Davis]

hm, prolly don't need to store individual usernames in the
permissions array, nevermind. It can be something like

::

         #label could be an individual, groups is the permissions array
         for label in groups:
             for username in group:
                 append username to users_in_permissable_groups
    
         if viewing_user in users_in_permissable_groups: display item

As things get huge we could do some caching to minimize all the
lookups. Of course if we do that, we'd have to add a mechanism to
quickly update the cache if the user changes the viewers
permissions during a session. Caching is clearly out of scope for
now!

[Caleb Davis]

Perhaps the hardest part will be to build this in a way that is
compatible with a federated environment. We're not specifically
building for that with this ticket, but add any design
considerations that come to mind.

[Caleb Davis]

It would be great if we could be smart about this, storing these
permissions by reference in the db. We won't have to worry about
exclusions for now, so I don't think we would run into any trouble
by doing that.

[Caleb Davis]

this ticket also does not consider 'friends' or 'followers' in the
traditional sense. We could add that on top later.

[Christopher Allan Webber]

Please also see:
`http://groups.google.com/group/ostatus-discuss/browse\_thread/thread/27eb180009020c41 <http://groups.google.com/group/ostatus-discuss/browse_thread/thread/27eb180009020c41>`_

[Will Kahn-Greene]

The original url for this bug was ​http://bugs.foocorp.net/issues/416 .
Relations:
#212: related

[Christopher Allan Webber]

Removing claim on this ticket; does not seem to being actively worked on.

[Elrond]

Okay, I'm trying to work on this sometime next.

I will implement a super simple thing for starters. Where you can mark a mediaentry as "private, only for people on this instance".

We will then continue with something on the lines of pump.io. It needs this anyway.

[Christopher Allan Webber]

Just confirming that we will be indeed tackling something along these lines, both because a) it'll be needed for full pump.io support anyway, and b) we promised it as part of the ​campaign.