Federation resharing concept ideas

[PVince81]

Discussed this with @schiesbn today:

The current problem with federation / server to server sharing:

1. user@owncloudA shares a folder "workspace" with user@owncloudB
2. user@owncloudB shares that folder with user@owncloudC
3. user@owncloudC shares it with user@owncloudD
4. etc

This will create a chain of connections and the user@owncloudX will have an extremely slow connection, because for every access one server needs to connect to the next until it reaches owncloudA.

Here is a proposed alternative workflow:

1. user@owncloudA shares a folder "workspace" with user@owncloudB
2. user@owncloudB wants to reshare it with user@owncloudC: clicks "share" and types in "user@owncloudC"
3. Server owncloudB contacts owncloudA with user@owncloudB's token, asking for a reshare with user@owncloudC
4. Server owncloudA validates the token and notices that reshare is allowed
5. Server owncloudA sends an invitation to user@owncloudC to access the folder "workspace" (as if it was shared by user@owncloudB)
6. user@owncloudC receives invitation that says "user@owncloudB shared the folder "workspace" from user user@owncloudA with you"
7. user@owncloudC accepts the invitation and receives the server
8. Whenever user@owncloudC accesses the folder, the connection is made directly to user@owncloudA

This has the following advantages:

• direct connection to the actual folder, no chaining
• folder owner (here user@owncloudA) can know who has access and revoke them, as each of them receive a separate share/token
• be consistent with the way how reshares will work for internal shares, see https://github.com/owncloud/core/issues/9058
• folder owner still has control over their data

Disadvantages:

• anyone getting access to the folder will know who the owner is, but I think it is legitimate to let them know the originating server

Extensions:

• user@owncloudB must have the possibility to unshare from user@owncloudC
• user@owncloudB should be able to query the list of people who have access to the folder "workspace", but that list could be limited to the people user@owncloudB "knows" (as in: "the owner" and "people who user@owncloudB shared with"). Tricky.

@MTRichards @karlitschek @DeepDiver1975 @icewind1991 @nickvergessen

[schiessle]

@cmonteroluque probably also interesting for you.

[icewind1991]

user@owncloudB must have the possibility to unshare from user@owncloudC

That means user C must have a different token then user B.

A way to solve that would be to have user ocB request a new token from ocA for the share which it then gives to ocC, ocA and ocB both remember that the new token is generated by request of ocB.

That way ocB can request ocA to invalidate the token given to ocC and ocB keeps a list of all users it "knows" to have access to the share

[PVince81]

Actually the idea was to have ownCloud A issue a new token for ownCloud C by sending the regular share invitation, as if user@A had shared with user@C, but the sharing action is triggered by user@B.

Yes, one token per user is the ideal situation :smile:

[oparoz]

Hmmm... I don''t like step 6. It should be optional. For privacy reasons, userA should not have to know who the data is shared with beyond userB.

[PVince81]

Well, one could say the data actually belongs to userA, so they have the right to know. Especially this is what is likely to cause additional bandwidth. Or are you suggesting we just hide it in the UI but still add the user to userA's server as per this concept ? In that case userA could (if an admin), still find out in the database who got access.

There are similar issues with resharing chains for local shares: https://github.com/owncloud/core/issues/9058

Here in this ticket I'm mostly talking about the shares that are initiated from the server, using the share dropdown and entering a remote user's ownCloud ID. Regular link share would still work as before, and would still be chainable.

[PVince81]

I usually like to think of such shares as "workspaces". There is the workspace owner, and that user gets a say who has access to the workspace. So if recipients would like to "invite more friends to the party", it's still the party organizer's right to know who'll attend :wink: (sorry for shifting the analogy mid-sentence)

[schiessle]

I agree with Vincent. I think the owner has a valid reason to know who access which files on his server.

[oparoz]

Thanks for the party analogy @PVince81 . From that view point, it makes sense. I'm sharing something to people I know and I don't mind them inviting more people to MY party.

The thing I'm not entirely warmed up to is when a relationship is created between 2 instances, just because they know the same person. I'm OK with sharing something to B and allocating some bandwidth to that channel, but I don't want the whole world to come and suck my bandwidth because he's posted my video on social media. It opens things to abuse since userA has no say in who connects to his share, even though it's not a public share. Each user should take their responsability and the final user doesn't need to know about the original user.

So, to me there are 2 different use cases for resharing

• Let others invite more people to connect to my share
• Let others re-share my content (a long chain with each node being responsilve for their bandwidth)

[PVince81]

I think for the bandwidth case, the idea would be to disallow resharing (that wouldn't work for share with link, but let's focus on the regular s2s case from the share dropdown). But then how will other people invite people to your party ? Maybe they could send you invitation requests that you need to confirm one by one "can I invite XYZ ?", and you, the owner, can decide whether that person gets access. If you don't care about bandwidth, you could just keep it on "auto-accept" mode.

The "share with link" case and also the fact that public webdav is openly accessible would still be a problem though.

[nickvergessen]

Situation that should be kept in mind:

1. ServerA is intern only
2. ServerB is both intern/extern
3. ServerC is extern only

In case B reshares the share from A, it should still work (maybe just like it does now). So in case C reshares to ServerD, D interacts directly with B

[PVince81]

Right. We could call this the "gateway" usecase, where there's an OC in the middle.

[PVince81]

@oparoz I just thought, the bandwidth argument does not apply because: regardless whether a chain is used or a direct connection, all connections will always affect the owner's server. Because so far federated shares are NOT mirrored, but direct connections (or a chain of connections) that go to the owner's server. (I'd love to have syncing/mirroring, but that's another topic: https://github.com/owncloud/core/issues/5225)

[oparoz]

Good point. I missed that in your OP.

[oparoz]

So, if a direct connection is created, as UserA, will I be able to remove shares from users beyond UserB without affecting the other ones?

How about some policies regarding bandwidth? Allocate 5GB for a share or 1GB per sharee, etc.

[PVince81]

I'd say as an owner you'd see the list of everyone who gets access, so you'd be free to revoke any shares as you wish.

Bandwidth allocation could be an extension, yes. But before it happens here, it was already requested in the past for regular public shares.

[rullzer]

This would help with the final point in https://github.com/owncloud/core/pull/17195

[PVince81]

Flat federated reshare was implemented here: https://github.com/owncloud/core/pull/24603

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.