Proposal for the OCM Address format

[KrausMatthias]

Following discussion in #237 and #244

[KrausMatthias]

BTW what is the Sharing User compared to the Sending Party ?

Should we replace the FQDN by some OCM Server Address consisting of host[":" port]?

[mickenordin]

I think this is good!

[glpatcern]

Looks good, but at this point I propose to make the following change:

[MahdiBaghbani]

Based on the discussion in #270
Should we standardize concrete address forms (or consider it) for each entity type (e.g. user@fqdn, group:slug@fqdn, federation:tag) to eliminate ambiguity?

I believe it at least heps with parsing ambiguity and validating the share notification

I can think of an example based on this PR:

ocm-address = identifier "@" server

user-addr: identifier = user name or user id, server = fqdn [ ":" port] or host [ ":" port]
group-addr: identifier = "group:" (group-id / group-slug) "@" server = fqdn [ ":" port] or host [ ":" port]
federation-addr: "federation:" fqdn [ ":" port] or host [ ":" port] or fed-tag or fed-id

in case of fqdn [ ":" port] or host [ ":" port] and federation type, the share is emant for all people at the fqdn
in case of fed-tag or fed-id (wedont have fed-id in spec yet), the share is meant for all people in all servers in the said federations

This is better to go on a new PR where we can talk more about it's design but it worth to mention it here.

[mickenordin]

I also just noticed something "fun", this is the ocm address as presented by owncloud 10 from surfbox, where I am logged in with my eduid.nl account:

Your Federated Cloud ID: [email protected]@surfdrive.surf.nl/files

notice the path at the end of the hostname. Shoudl we infact allow that? That will make instances installed in subpaths work.

[KrausMatthias]

I also just noticed something "fun", this is the ocm address as presented by owncloud 10 from surfbox, where I am logged in with my eduid.nl account:

Your Federated Cloud ID: [email protected]@surfdrive.surf.nl/files

notice the path at the end of the hostname. Shoudl we infact allow that? That will make instances installed in subpaths work.

Discovery via the .well-known/ocm path is not possible in a subfolder, how should discovery behave in the case of subfolders?

[KrausMatthias]

Based on the discussion in #270 Should we standardize concrete address forms (or consider it) for each entity type (e.g. user@fqdn, group:slug@fqdn, federation:tag) to eliminate ambiguity?

I believe it at least heps with parsing ambiguity and validating the share notification

I can think of an example based on this PR:

ocm-address = identifier "@" server

user-addr: identifier = user name or user id, server = fqdn [ ":" port] or host [ ":" port]
group-addr: identifier = "group:" (group-id / group-slug) "@" server = fqdn [ ":" port] or host [ ":" port]
federation-addr: "federation:" fqdn [ ":" port] or host [ ":" port] or fed-tag or fed-id

in case of fqdn [ ":" port] or host [ ":" port] and federation type, the share is emant for all people at the fqdn in case of fed-tag or fed-id (wedont have fed-id in spec yet), the share is meant for all people in all servers in the said federations

This is better to go on a new PR where we can talk more about it's design but it worth to mention it here.

I agree there is a gap where users or implementations need to know if a certain OCM Address identifies a user, group or federation to be able to fill the shareType field in the NewShare message.

If we make that part of the OCM Address we should drop the shareType field in NewShare.

"group:" or "federation:" prefixes might already be contained in the existing opaque strings so that would be a breaking change.

If we do that, I would be strongly in favor of making OCM Addresses a URI, with "group" and "federation" as URI scheme instead of defining something which looks like an URI but isn't.

I'm wondering if we can avoid needing the SendingServer to know it the recipient is a user, group or federation if we leave that distinction completely to the ReceivingServer (requiring a shared namespace on the ReceivingServer where a Group can't have the same name as a user)

[mickenordin]

I also just noticed something "fun", this is the ocm address as presented by owncloud 10 from surfbox, where I am logged in with my eduid.nl account:
Your Federated Cloud ID: [email protected]@surfdrive.surf.nl/files
notice the path at the end of the hostname. Shoudl we infact allow that? That will make instances installed in subpaths work.

Discovery via the .well-known/ocm path is not possible in a subfolder, how should discovery behave in the case of subfolders?

I suppose, what we should do in case we receive such an OCM-address is to try https://surfdrive.surf.nl/.well-known/ocm and then fall back to the legacy endpoint at https://surfdrive.surf.nl/files/ocm-provider/ (which in fact, is what current implementations do as the first action)

[MahdiBaghbani]

If we do that, I would be strongly in favor of making OCM Addresses a URI, with "group" and "federation" as URI scheme instead of defining something which looks like an URI but isn't.

I agree, the blocker for making OCM addresses RFC7565 is the breaking change in already established user shares.

federation and group share are kind of new territory so we might be able to use URI in here?
@glpatcern and @mickenordin are better informed in this area, the current usage and implementation of it.

[mickenordin]

I'm wondering if we can avoid needing the SendingServer to know it the recipient is a user, group or federation if we leave that distinction completely to the ReceivingServer (requiring a shared namespace on the ReceivingServer where a Group can't have the same name as a user)

I would like to avoid having a centralized registry of federations if possible, because that makes it less of a federation and more of a distributed system, the sending server could of course be made to provide additional information about the federated share it wants to set up, and act as a proxy, but again, that just means sending multiple user or group shares to a multitude of servers. We should investigate what Nextcloud does with the federation share type before proceeding more with this line of inquery I think.

[MahdiBaghbani]

Based on Nextcloud sources create share and notification

They use

* send server-to-server share to remote server
*
* @param string $token
* @param string $shareWith
* @param string $name
* @param string $remoteId
* @param string $owner
* @param string $ownerFederatedId
* @param string $sharedBy
* @param string $sharedByFederatedId
* @param int $shareType (can be a remote user or group share)

In the notification it would change them to correct identifies for OCM in here

which finally sends the share in here

The share type is either user or group, defined here

And this is for the remote group, see Nextcloud doesn't use federation but group for the shares

I have a feeling I'm not searching the right places

[glpatcern]

I think this changeset can go ahead as is. The current discussion about the semantic of group/federated sharing will surely continue in #270 but it's beyond this PR.

[MahdiBaghbani]

LGTM! Thanks Matthias