Spaces

[exalate-issue-sync]

A New Approach to Collaboration on Files

On the ownCloud Infinite Scale platform we would like to introduce a new approach on how users collaborate on Files.

The new approach distinguishes between short term and long term collaboration.

Short Term Collaboration: User- or Group Shares

The typical usecase in short term collaboration is that people are passing a document to each for quick reference. Usually that is single document, or maybe one folder with a image series, and the duration of use is fairly small. The sharee nor the share receiver do not change over that period.

That is the typical use case for direct sharing with single other users or user groups known to the ownCloud.

This is also called file sharing.

Long Term Collaboration: Spaces

Another case is that a group of people plans to work on a bigger file set for a longer term. Many people are responsible, might have different roles when working with the files, and the responsibilities might change over time.

The file collection is not owned by a single person but is more a collection of files many work on. A typical example would be a the files around a project in a company.

This new concept will be called Spaces (PROD-3) in ownCloud Infinite Scale.

Current Status

oC 10

• Users have only one area, their personal space (/).
• All mounts are part of the personal space (e.g., external storage)
• Incoming shares are part of the personal space and can be freely moved within the hierarchy
• All shares consume the owner's quota
• Sharing of folders and individual files
• User sharing types
  • User (internal/federated/guest)
  • System group (internal, admin-defined)
  • Custom group (internal, user-defined)
• Location for incoming shares (configurable)
  • Default: root
  • Can be any folder
• Pending shares (configurable)
  • Shares are only accessible/syncable when they have been accepted
  • Unshared shares are denied but can be recovered

Concept for ownCloud Infinite Scale

This will be implemented on the oCIS platform only.

Home Space

Every user has a home space. That space is really private. No mounts of not user owned files (such as shares) pollute this space.

The user can freely share files from the home space to other users as short term collaboration.

From the home space, users can only copy or move files to other spaces.

Quota is only calculated from the users Home space.

Shares

Shares that a user receives from other users are collected under a special node called "Shares". On clients, this node is displayed in parallel of the Home Space and contains accepted and pending shares from other users. The shares are mounted under this node and can not be moved out.

TBD: also federated shares?

Spaces

Spaces provide file storage of a certain size, they have their own quota which does not charge a single user. Users can not create spaces on their own by default but require admin permission.

Spaces have their own properties (sharing policies / encryption / retention policies / etc.)

There are different space types, eg. external storages, project spaces, team spaces etc.)

There is metadata available for spaces, for example theming, lists of members, icons, link collections etc.

There will be a special API to query all information about spaces.

There is a Spaces Initiative

Client Design

Clients are providing independent areas for

• The Home Space
• The Share Space
• Every Space that the user has access to

and display them for example in separate areas in the left sidebar on web. For Home and Share there will be localized terms. The Spaces will have a user defined display name in the properties.

WebDAV Layout

For the WebDAV interface that is crucial for client interaction, the following routes are planned:

Desktop- and mobile clients maintain a separate connection for each Home, Shares and each space.

remote.php/webdav/<user>/home
remote.php/webdav/<user>/shares
remote.php/webdav/<user>/spaces/space1

ETag propagation happens up to each of these endpoints (home, shares, spaces). However, clients can check the propagation endpoint spaces specific, ie. space1 in the example above.

Client Compatibility

There will be a server capability if the new concept is available to be queried by the clients.

Behaviour of clients that do not implement this new scheme yet ("older clients") TBD.

References

• Client behavior for shared folder: [All] Share-jail folder to contain all the accepted shares #7
• Spaces Spec on Github https://github.com/owncloud/enterprise/issues/3863
• Spaces Initiative

[exalate-issue-sync]

Michael Stingl commented: Previuos discussion: https://jira.owncloud.com/browse/OC-1106

[phil-davis]

The "fixed" folders "Shares" and "Spaces" (and "Home" if that is going to be "a thing" under the "root") will need to have language-translated values when used in any User Interface. (Of course the URLs paths of the APIs will always use the words home, shares and spaces)

I am not sure if the intention is that the Home space is shown in UIs as a completely separate thing. If so, then all is well - in English a user will see "Home", "Shares" and "Spaces" at the root level. If not, then what to do when a user has created a folder called "Shares" or "Spaces" in their "Home"? Just need to make sure that naming conflicts do not happen.

[phil-davis]

Spaces have their own properties (sharing policies / encryption / retention policies / etc.)'

I guess there will be more detail to write! For example, "sharing policies" will need to allow some users/groups to have read-only access and other users/groups to have read-write access... i.e "ACL"s with multiple entries.

[exalate-issue-sync]

Hannah von Reth commented: I really like the idea, compared to what was discussed before.
For the desktop client we need to discuss how we want to manage the file system integration.
1)

~/ownCloud/home
~/ownCloud/shares
~/ownCloud/space1

~/ownCloud/
~/ownCloud-shares
~/ownCloud-space1

~/ownCloud/
~/ownCloud-shares
~/space1

or something similar, I guess in any case users will complain...

(1 would probably mean only one side bar entry, 2) & 3) will mean unlimited entries or optional entries)

[jnweiger]

1. makes sense to me. The other two will certainly cause much confusion. The downside of 1) is, that there is an additonal folder "home" inside "the" ownCloud mountpoint.

The other user-friendly layout I can imagine would have exactly two-sidebar entries: The home remains where it is, and all other magic is subfolders of ~/ownCloud-Network (or whatever fancy name we want to give to that):

~/ownCloud/
~/ownCloud-Network/Shares/
~/owncloud-Network/Spaces/Space1

(The ~/ownCloud "home" could actually be a symlink to ~/ownCloud-Network/.home to keep things technically in one place and transparent to those who want to investigate.)

This also leaves room for future exansion. E.g. we could present public links as entries in ~/ownCloud-Network/Public/...

[exalate-issue-sync]

Hannah von Reth commented: While it is 2021, symlinks are still not portable