You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
Ondřej Hruška 2b84e5eeb0
update readme
3 years ago
src slightly better handling of socket going silent, maybe 3 years ago
.gitignore tags wip 3 years ago
CHANGELOG.md change elefren linking 3 years ago
Cargo.lock slightly better handling of socket going silent, maybe 3 years ago
Cargo.toml slightly better handling of socket going silent, maybe 3 years ago
LICENSE.txt add MIT license 3 years ago
Makefile add make targets 3 years ago
README.md update readme 3 years ago
build.rs reformat, add ping command 3 years ago
fedigroups.example.service add restart cmd, add example service file 3 years ago
rustfmt.toml reformat, add ping command 3 years ago

README.md

Fedi Groups

How it works

This is an approximation of groups you can use right now with existing fedi software that implements the Mastodon client API.

A group is a regular user account controlled by a "bot" service that runs on a Linux server (e.g. a Rpi in your closet). To join a group, simply follow the group user. To post into the group, tag the group user in a top-level post (not a reply), or use /b in a reply to share the parent post to the group. The group will reblog shared posts to its members.

Groups implement moderation (banning users and instances, member-only mode with user whitelist). This is controlled by slash commands, see below.

Group admins can issue group announcements that are posted poublicly by the group user, such as when there is a planned maintenance. The group will attempt to catch up with posts missed during the outage.

Advantages of emulated groups

Unlike some other attempts at group implementation (namely gup.pe or the mythical WIP Pleroma Groups), this works with current Pleroma and Mastodon. There's no need for interoperability in different server implementations, since it uses existing follow/mention/reblog features that are already cross-compatible. Mastodon users can join a group running on Pleroma and vice-versa.

Groups probably can't be hosted on Honk and Misskey, but their users can use groups hosted elsewhere just fine.

Setup

Building

Install the rust toolchain using rustup: https://www.rust-lang.org/tools/install

Rust 1.54+ is recommended.

Build with cargo build, or optimized: cargo build --release. The binary is placed in the target/debug or target/release directory.

You can also run the program using Cargo, that is handy for development: cargo run. When passing command line flags, use --: cargo run -- -i my@group.xyz.

Setting up a group account

  1. Create the group's account all nice like you want it. Pleroma and Mastodon should work, others may work too but you're on your own.
  2. Run the group service with fedigroups -a mygroup@groups.social (your account's handle) to authenticate.
  3. Make sure you auth as the correct user!
  4. Paste the Oauth2 token you got into the terminal, hit enter.

The program now ends. The credentials are saved in a file groups.json.

You can repeat this for any number of groups.

In case you need to re-authenticate an existing group, do the same but use -A instead of -a.

Editing config

Do not edit the config while the group service is running, it will overwrite your changes!

The JSON file is easily editable, you can e.g. add yourself as an admin (use the e-mail format, e.g. piggo@piggo.space). The file format is quite self-explanatory.

{
  "groups": {
    "group@myserver.xyz": {
      "enabled": true,
      "acct": "group@myserver.xyz",
      "appdata": {
        "base": "https://myserver.xyz",
        "client_id": "...",
        "client_secret": "...",
        "redirect": "urn:ietf:wg:oauth:2.0:oob",
        "token": "..."
      },
      "group_tags": [
        "grouptest"
      ],
      "admin_users": [
        "admin@myserver.xyz"
      ],
      "member_only": false,
      "member_users": [],
      "banned_users": [],
      "banned_servers": [
        "bad-stuff-here.cc"
      ],
      "last_notif_ts": 1630011219000,
      "last_status_ts": 1630011362000
    }
  }
}
  • group_tags - group hashtags (without the #). The group reblogs anything with these hashtags if the author is a member.
  • member_users - group members, used to track whose hashtags should be reblogged; in member-only groups, this is also a user whitelist.
  • banned_users - can't post or interact with the group service
  • banned_servers - work like an instance block

Running

To run the group service, simply run it with no arguments. It will read what to do from groups.json.

Note that the file must be writable, it is updated at run-time.

An example systemd service file is included in the repository as well. Make sure to set up the system user/group and file permissions according to your needs. You can use targets in the included Makefile to manage the systemd service and look at logs.

Group usage

Commands

Commands are simple text lines you use when mentioning the group user. DMs work well for this. One post can contain multiple commands; the replies will be batched to one response.

Replies keep the same visibility level as the post with the command.

Posts with commands, mentioning the group, won’t be boosted.

Membership

When a user follows a group, the group follows them back and marks them internally as a member. (In member-only groups, a group admin must initiate the second part).

Admin can add or remove group members using the /add and /remove commands. Users can use /join and /leave.

Members can use /join to make the group re-follow them, for example when the follow somehow stopped working.

Group mentions

Any user (member in member-only groups) can post to the group by mentioning the group user. The post is then reblogged.

Group hashtags

Admins can add hashtags to the group config (/add #hashtag, remove the same way: /remove #hashtag).

When a group member posts one of the group hashtags, the group will reblog it. This is a nicer way to share posts, you don't have to mention the group user at all.

For group hashtags to work, the group user must follow all its members; otherwise the posts might not federate to the group's server.

List of commands

Note on command arguments:

  • When a command wants user handle as an argument, use the e-mail form, e.g. piggo@piggo.space, to avoid mentioning the user.
  • Local users can be specified without the domain part, but the first @ is then needed.
  • When specifying a server (for server ban commands), the name must contain at least one dot.
  • Hashtags are specified in their full form with a hash.

Basic commands

  • /help - show help
  • /ignore, /i - make the group completely ignore the post
  • /members, /who - show group members / admins
  • /tags - show group hashtags
  • /boost, /b - boost the replied-to post into the group
  • /ping - ping the group service to check it's running, it will reply
  • /join - join the group
  • /leave - leave the group

For admins

  • /announce x - make a public announcement from the rest of the status. Note: this does not preserve any formatting!
  • /ban x - ban a user or a server from the group
  • /unban x - lift a ban
  • /op user, /admin user - grant admin rights to the group
  • /deop user, /deadmin user - revoke admin rights
  • /opengroup - make member-only
  • /closegroup - make public-access
  • /add user - add a member (use e-mail style address)
  • /kick user, /remove user - kick a member
  • /add #hashtag - add a hasgtag to the group
  • /remove #hashtag - remove a hasgtag from the group