Opened 12 years ago
Last modified 7 years ago
#126 accepted enhancement
sharing and permissions
|Reported by:||Caleb Davis||Owned by:|
|Component:||programming||Keywords:||longterm pumpio large|
|Cc:||Odin Hørthe Omdal (Velmont), Elrond, Christopher Allan Webber, Caleb, Davis||Parent Tickets:|
Description (last modified by )
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.
Change History (12)
comment:1 by , 12 years ago
comment:2 by , 12 years ago
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.
comment:3 by , 12 years ago
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.
comment:4 by , 12 years ago
this ticket also does not consider 'friends' or 'followers' in the traditional sense. We could add that on top later.
comment:5 by , 12 years ago
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>`_
comment:6 by , 11 years ago
The original url for this bug was http://bugs.foocorp.net/issues/416 .
comment:7 by , 11 years ago
|Type:||defect → enhancement|
comment:8 by , 10 years ago
Removing claim on this ticket; does not seem to being actively worked on.
comment:9 by , 10 years ago
|Keywords:||longterm pumpio added|
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.
comment:10 by , 9 years ago
comment:11 by , 8 years ago
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.
comment:12 by , 7 years ago