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

[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.