Add Shared Folder Permissions

[AmriaLeiah]

Is your feature request related to a problem? Please describe.

When a folder is shared, it is fully public. There is no way to limit its spread. Additionally, such things can be crawled and discovered even if they were never meant to be shared beyond a small group such as those participating in an MMC competition.

Describe the solution you'd like

Adding Shared Folder permissions. Upon marking a folder to be shared it will give a dialog of settings to determine certain permissions of the folder and how it can be shared. Including, but not limited to; "Only I can share" meaning only the owner can spawn a sharable folder. "Only Contacts can share" meaning only contacts of the owner can share it. "Only Group can share" only a selected group can share it. "Do not allow saving in shared folders" meaning the folder itself cannot be saved to a folder that is shared and prevents a folder being shared if this is contained in it. And possibly more.

Describe alternatives you've considered

None other than moderation taking action on services like UniPocket or RedX and making it a bannable offense which isn't really tenable.

Additional Context

No response

Requesters

AmriaLeiah, Gearbell, Reviver

[Frooxius]

We can't really limit the "sharing" aspect of this - public folders are like hyperlinks - if someone has the hyperlink, then there's not really a way to stop them from passing it forward.

What would make most sense though (and what I think is probably closer to what you actually want here) is configuring read/write access for them though - that way you specify who can view or modify contents of the shared folder.

That way even if someone gets the link, they will lack the necessary permissions to browse that folder.

Would that work well enough for you?

[GearBell]

What if there was a slight alternative - Only the owner of the folder can Share a folder (marking it public) but has an additional option of creating a Folder Shortcut (not public but linked to thier folder), Only the owner can create Shortcuts and they cannot be handed out (nonpersistant except if the owner is present). With shortcuts the folder would still be private but as long as the owner is online it is accessable. Its a crunchy concept but I cant think of much else. Basically

• Shared folder = public, spawnable by anyone (blue)
• Shortcut folder = Once given the folder by the owner you cannot spawn it, linked to a unpublic folder (orange, similar to "nonpersistant" orange)

[AmriaLeiah]

We can't really limit the "sharing" aspect of this - public folders are like hyperlinks - if someone has the hyperlink, then there's not really a way to stop them from passing it forward.

What would make most sense though (and what I think is probably closer to what you actually want here) is configuring read/write access for them though - that way you specify who can view or modify contents of the shared folder.

That way even if someone gets the link, they will lack the necessary permissions to browse that folder.

Would that work well enough for you?

Absolutely! That actually sounds like it would work so much better. The only thing I would worry about is if allowing others to modify the contents of a folder might make groups ever so slightly redundant?

[Redcyberhawk]

Froox's method of handling it seems to be smoother, but would likely require some system integrations to update the said permissions across everyone's inventory, with the potential of after-the-fact updating in case someone wants to unshare a folder temporarily or for good.

Two seperate permissions for Reading and Writing, and ideally split those up between:

• Owner Only
• Contacts
• Selected Group
• Everyone

Maybe even adding specific user ids to its own configurable list for fine tuned controls, but systematically, it could get messy.

In an ideal world, there would also need to be a user-friendly popup in case you do not have access to read a shared folder, because you know there's gonna be someone who's gonna ask why a shared folder turns up blank with no prompt or notice.

[Frooxius]

@GearBell That doesn't really work well.

To give you analogy, imagine like you tell somebody a secret phrase, say "Mushy Potatoes", but you ask them to not tell it to anyone but your friends. They can honor that, but can you through any mechanics of language really prevent them for breaking that request? You can't, they know the word "Mushy Potatoes", so they can tell it to anyone they want, who in turn, can tell it to anyone they want too. You can't really prevent the spread of the word.

But if we add the read/write permissions - that's like adding an invite list to your secret place. So even if somebody knows the secret phrase, you still check if their name is on the list or not.

[GearBell]

Read/Write permissions based on similar allowances in the Sessions? Allow contacts/registered/anyone/private? That seems interesting. (contacts plus would basically become "anyone" after it gets passed around enough by freind-of-a-friend-of-a-friend etc)

[goof320]

Shared folders permissions should work in a similar (if not identical) way to how Google Drive handles sharing files and whatnot. If you receive a link to something the owner hasn’t given you access to, you get a nice little webpage telling you that you don’t have access when you open that link. And, if the owner of the file, say it’s a document, gives you viewing access but not editing, you can look at it but you can’t edit it. I think it’s also possible to make a file accessible, either viewable or editable, to an entire organization that you’re in as long as anyone in the organization has a link. So, that could also be how group folders are handled? I haven’t used a group in Resonite ever, so I’m not sure if this makes sense lol. Any account in the group can use a folder as long as that folder is set to be accessible by anyone in the group. This is basically the same as Froox’s proposal I think lol

[FlameSoulis]

I have a sneaking suspicion that we're going to be invoking some UNIX file permissions in a way: Permissions for the owner Permissions for the group Permissions for everyone