Public and private groups

Hey,

I found in groups documentation following paragraph:

A group is made up of a superadmin, admins, and members. It can be public or private which determines whether it appears in results when a user lists groups. Private groups are similar to how WhatsApp groups work. A user can only be added when they’re invited to join by one of the group’s admins.

I found in the Nakama server code (open source version) that there is such a thing as an open/closed group concept, which is used to determine whether an invitation is required or not. Is open/closed group the same as public/private? If so, the open/closed group functionality does not affect the search in any way. If it is not the same thing, where to look for the ability to hide groups from search? In the best practicies for groups there is an example with visibility, but it is not entirely clear what this visibility is supposed to do, and thus how it differs from public/private.

I also found some references to private/public concept in Heroic Labs Documentation | Clans. They are also confusing.

Because of the above I don’t have any idea how to implmenet public/private group feature in Nakama. I want to have groups that are searchable when public and invisible in search when private. At the same time such groups should alwasy be closed (requires invitation acceptance).

Thanks in advance

Hello @jlisicki-ccgames,

If you want groups that require an invitation flow you’ll need them to be closed. You can filter groups when listing by specifying whether you want to filter them by their open/closed setting or list all groups. You can also wrap the listing with a custom RPC to filter groups however you may find suitable before returning them.

The example you mentioned in the docs is just pointing out that you can write additional custom metadata in a group when it’s created, and you can then use that metadata to implement custom Access Control / filtering rules or whatever you need to extend and customise the core functionality.

Hope this clarifies.

Thanks for quick answer.

The given solution solves the problem, but introduces another one. List filtering in a custom RPC may require additional internal rounds to collect the desired number of groups. Depending on a scenario, this can lead to an overload of the database, as all groups have to be retrieved to find out that there are not enough groups meeting the condition.

But back to the original question. I still don’t understand how public / private and open / closed are linked. A private group shouldn’t be visible in any lookup, but I can’t set the group to private to verify this because I don’t see anything related to public/private groups in the server code or the server framework method documentation. In particular, ListGroups does not contain any code that might result in private groups not being returned in the response. I can see that there is an option to filter by open/closed state, but this cannot be used when the user searches for groups by name. To me, this means that the open/close feature does not satisfy the statement in the quoted paragraph It can be public or private which determines whether it appears in results when a user lists groups and the author must have had something else in mind.

You’re right, the statement is misleading since the current APIs do not allow that filtering out-of-the-box, we’ll remove that statement and/or improve the docs around it.

However, the example still applies except that you won’t have any open groups, but only closed visible (Invite-only) or closed (private) groups.

The Nakama APIs and related queries are all optimised, it’s true that you’ll be fetching more data from the DB and filter it in-memory within the server, but in practice this model has worked well for us at scale with several of our Heroic Cloud customers.

The case could be made that it makes sense to support private/public groups as well so feel free to open a feature request in the Nakama repository and we’ll consider making it part of the first party API in a future release.

Best.