Federation for groups

[cal940]

Right now Federation works only with users not with groups.

[schiessle]

Thanks for the feature request. We already thought about it multiple times. I assume that this will be on the roadmap for one of the next version. For Nextcloud 12 it is to late but chances are high that it will make it in Nextcloud 13

[MorrisJobke]

@rullzer @schiessle didn't we discussed lately about this? 🤔

[schiessle]

Yes, we discuss this every now and then. In general there are two kinds of federated group sharing you can think about:

1. address a group on another server, share with group@server the same way you can share with user@server

2. Have real federated groups where group members can be on different servers as well

The second way of looking at it raises a lot of open questions. But the first option is absolutely feasible and has a good chance that it will be on the road map for Nextcloud 14, but I can't promise it yet.

[rullzer]

Let me paste here what I already wrote before:

---

1. Federation over groups is a weird concept. It is even weirder in the context of Global scale.
   On a single instance you already don't know who is in a group. However you can be somewhat certain your admin configured things properly and when you share with sales that this is actaully sales. Sharing with a remote group is just saying well I share with this gorup but I have no clue who is a pat of it.
2. I don't know how this would look UX wise
3. Performance wise this will most likely slow to a crawl. Lets say:
   a. userA on instanceA shares a fodler with groupB on instanceB.
   b. groupB consists of 1000 users
   c. all those 1000 users (the way we currently do it) will try to fetch that info

We are improving the speed and usablility of federated shares all the time. But this could mean that and instance gets all of a sudden >1000 federated shares in an instance. We never tested this. And I would not be surprised if there are parts that don't scale so nice. We should look into this.

Now in the context of GS federated group sharing is even more an issue. Because it isn't 1 to 1. With GS the idea is that it all feels like 1 big instance and the user doesn't have to care where they are located. So actaully when they share to the group sales they would expect everybody (no matter what their instance is) to get this. But!

1. The lookup server has no group concept
2. Because users can move around basically at any moment in time resolving of those shares becomes trickier as well (userA on instanceA could be migrated to userA on instanceC etc).

So long story short. There are some technical and UX wise things that we need to properly think about, discuss and define.

So basically like @schiessle mentions above it is tricky and we should make small steps to assure it keeps on working and the behavior is somewhat sane.

[schiessle]

c. all those 1000 users (the way we currently do it) will try to fetch that info

Not everybody would fetch it simultaneously. On the recipient side we could just store the information that there is a federated share for group X. Users of the group can accept/decline it and we only access the file when we setup the filesystem, which will most likely not happen for all users at the same time. But I agree, it is something to keep in mind, e.g. in a organization where 75% has a running sync client during office hours.

Now in the context of GS federated group sharing is even more an issue. Because it isn't 1 to 1. With GS the idea is that it all feels like 1 big instance and the user doesn't have to care where they are located. So actaully when they share to the group sales they would expect everybody (no matter what their instance is) to get this. But!

You are right, that in a GS setup the lookup server doesn't has any group information. But we know all instances because it is a closed environment. So in a GS setup we could basically broadcast group shares to all servers to make sure every group member, no matter on which server will get the share.

But this are all high level ideas and we need to go there step-by-step.

[hodyroff]

In regards of federation I think you continue to implement the Open Standard "OpenCloudMesh". I think it would make sense to bring up the discussion in the standards group, document it and then implement?!

[schiessle]

Don't worry, I will take care of it. Everything is already discussed with your colleagues and the broader community.