Create a group, manage members and roles

Groups are where conversation between more than two people happens in Korat, because chat itself is one-to-one only. It takes two forms. Most of it is posts: a group post is an ordinary row in the posts table carrying a community id, so comments, mentions, notifications and search work on it unchanged rather than being rebuilt in parallel. Alongside that, a group can have rooms — Discord-style text channels listed inside the group, with their own permissions and their own read state. Rooms are deliberately thin, and the callout below says exactly how thin.

A group post is a feed post with an address

This is the single most consequential thing to understand about Korat groups. When you post into a group, you are creating exactly the same object you would create on your own feed: same reactions, same comment threads, same @mentions that resolve to real handles, same edit and delete, same notification plumbing. There is no second-class group comment system that is missing a feature the feed has.

The only thing the group id changes is where the post appears. Group posts are filtered out of the main feed at precisely one point in the code, so they stay inside the group rather than leaking into the timelines of everyone who happens to be friends with a member. One filter in one place is also why the behaviour is consistent — there is no second exclusion rule somewhere else that can drift out of agreement with the first.

The practical payoff is that a group in Korat is immediately as capable as the feed, and improvements land in both at once. The cost is honest and stated below: the group's rooms are not the messenger, and the durable half of a group is its board of posts.

Public and closed, and what closed actually means

When you create a group you set a name, a description, a category, a privacy setting of public or closed, and a rules text. The rules field is not decoration: a group without written rules ends up with rules anyway, invented ad hoc by whoever is moderating that day, and members find out about them by breaking them.

A closed group uses join requests. Someone asks to join, and an owner or admin approves or rejects; the requester can cancel a pending request rather than being stuck waiting for a decision that is not coming. Both sides are notified — the managers when a request arrives, the requester when it is approved. A request that vanishes into silence is the most common failure of every group system, and a notification on approval is the cheapest fix for it.

A group whose members all train the same sport is better served by a sports club, which claims one sport, ranks its members from the sessions they record in Health, and adds a leaderboard and an activity feed the general-purpose group does not have. Both have the same rooms.

The state of a group is shown before you tap, not after. A closed group carries a lock on its card, so the difference between "join" and "ask to join" is visible while you are still deciding — a button must never promise something the next screen refuses.

Four lists, not one list with badges

The groups screen is split into titled sections with counts rather than a single list where relationship is conveyed by a small badge: groups I manage, groups I joined, pending requests, and discover, plus search across all of them.

This started as one "my groups" list and was rebuilt, because the four rows mean four different things. A group you own has settings and a request queue waiting for you. A group you have merely asked to join has nothing yet. Sorting them into headed sections with counts answers "do I have anything to deal with?" at a glance, which a badge on a row buried thirty items down does not.

Roles, and handing a group over

There are three roles — owner, admin and member — shown as badges next to a person's name. An owner or admin can change a member's role, remove a member, edit the group's settings, or delete the group. There is also ownership transfer, which matters more than it sounds: a group whose owner has stopped using the app and cannot pass the keys on is a group that slowly dies with a locked settings screen.

Korat's rule is that an action the backend will refuse should not be offered at all. An owner does not see a "leave group" item, because leaving would orphan the group; the path for an owner who wants out is to transfer ownership first. Anything posted in a group can be reported from the post itself, with the same fixed reason list the rest of the app uses. Destructive actions — deleting a group, removing a member — sit behind a confirmation that says plainly what does *not* happen as well as what does, since people hesitate mostly because they assume the worst outcome.

Notifications that correspond to decisions

Groups send four kinds of notification, and each one maps to a moment where somebody needs to know something: a new post in a group you are in, a join request arriving for managers, your request being approved, and your role changing.

The first of these was missing early on, and the result was a group that looked abandoned because members simply never learned that anything had been posted. The same failure mode later showed up in shop orders. A feature that produces content nobody is told about is not a quiet feature, it is a broken one.

Sharing a group outward

A group can be shared through the same opaque link system the rest of Korat uses — a koratland.com/s/<token> URL with a 14-character random token that resolves in the app. The resolver returns only what kind of object the token points at and which one; it never reveals who created the share or how many times it has been opened. The same resolver carries a shared post, a profile or a shop page, which is why a recruiting link posted publicly carries no information about the person who posted it.