Agree with above, with following suggestions:

• Instance admin should be able to open a moderation interface for a group and perform Deactivate and Delete functions on the group account
• Maybe admin, mod, member levels, could be changed to owner, admin, member levels, and higher levels can never be removed from the group by lower levels
• Need function to allow transfer of group ownership to another member in the Members page
• A boolean visible setting should affect if the group is searchable or not in a groups search function. If a group is non-searchable, it becomes found when its join page URL is shared with others, or if someone edits group URL values to observe to observe different group IDs
• Gab offers a Password field in group settings to require a password for group post access. That could provide value to some groups, as long as posts can be reported and instance owners always have access to view group activity
• Maybe offer a category dropdown selector and/or tags field in group settings to improve filtering for people searching for new groups to join
• Group level chat should be available for group members
• For each post, dropdown menu for moderator/owner should offer Delete Status from Group, Delete Account from Group, and Pin in group
• Gab offers a dropdown selector when posting, to allow posting to a specific group that you are a member of or to your public timeline. I don't see much value in that, due to the extra steps and learning curve. If it is obvious that you are in the main timeline or in a particular group when you post, then the posting scope is naturally defined.
• Add/remove group shortcuts to the sidebar is a highly valuable feature for those who navigate a number of groups
• If we wanted to create a channel style group capability like Telegram and MeWe have, you would need another group setting for Member permissions with choices of Contributor and Viewer, or choose Group or Channel when creating the group like Telegram does. A Contributor is normal group timeline behavior where all group members can post on the group timeline, comment, chat and invite. A Viewer can comment, chat and invite, but not post on the group timeline. If a group is set to Viewer member permissions (channel style), the channel owner should be able to curate comments and promote them to the group timeline.
• Maybe add a comment that the members_only scope feature should only have value if a group is set to public privacy. Otherwise, all statuses by default have member_only scope

When moderating trolls that reply to group posts on the main timeline but aren't members of the group, in the Gab world, you can only delete a status, but can't delete the account because they hadn't joined the group. That means that a moderator must chase the troll around, deleting replies, because there is not a mute for entire group feature. We should discuss techniques of allowing mods to one-click suppress trolls who harm group chemistry through replies to group posts without joining the group.

Agreed, a lot of stuff I was thinking already. I'm trying to keep it as simple as possible at first, but I'm keeping in mind ways it could grow.

This looks like a good starting point. Regarding non-owner administrative roles in GET /api/v1/groups/:id, can those roles be assigned to remote users (e.g. let's say MK Fain from Spinster moderates a group Alex owns on Gleasonator)? And if so, is it perhaps better to use ActivityPub ID to identify such types of members of a group like in the ap_id part under pleroma of a GET /api/v1/statuses/:id response? Maybe not.

The only other thing I could think of is security concerns regarding fetching and federating this properly without encountering situations where someone who isn't authorized to view posts from a group with visibility set to followers_only on a remote server isn't able to view it.

Yep indeed, remote users may be assigned to manager roles. There are some quirks (they may not be able to see all group members) but it should mostly be okay.

Agreed about the security issue, been thinking about that. But I think "authenticated fetch" could solve it, and maybe the followers_only scope already has some logic we could copy.

One thing that MeWe offers that is highly useful in Groups is to be able to hover over either group posts or group chat posts and see who emojied the post. It is useful because groups are more intimate and you can follow the flow of consciousness in the group of who has seen something, who understands something or not, etc., via a simple hover over emojis.

MeWe limits emoji application to up to 4 emoji types per post, selected from an emoji modal. Once an emoji is applied, others can click on an applied emoji to update the who reacted information. The quality of feedback via emojis goes up dramatically if you have a large selection of emojis to choose from, even if the types per post is limited to 4. If emojis work well in a group, it is much more efficient to provide feedback to a post by using emojis than by writing out a reply.

It seems that since Groups can be a more intimate communication environment, that we should provide more effective ways to communicate and to understand reactions to posts, by opening up both emoji types that can be used and knowing both who reacted and how they reacted.

Since some groups might be wide open, with members not really knowing each other, perhaps an admin can adjust group settings to toggle the display of who reacted to a post, but I think the default should be On so that people can learn to appreciate the richness of communications available with this approach.