Directory

SimpleX

This is a list of SimpleX groups and channels hosted by me, alphabetically-sorted A-Z, based on brand name, followed by group/channel name, and is formatted as <brand> - <group/channel>.

Public groups and channels can be joined by anyone without an invitation. Private groups and channels require an invitation; requirements for invitations differ per group/channel.

Joining a group/channel can be performed by clicking/tapping the group/channel name, or scanning the QR code, for each group/channel to be joined.

For a list of staff members and how to contact them, the Staff section can be consulted.

Name	QR Code	Description	Access
Announcement		Announcements related to network and server maintenance, group and channel additions, modifications and removals, and feature additions, modifications and removals.	Public
Music		Discussion of music-related topics and posting of music.	Public
Off-topic		Discussion of topics without a dedicated group.	Public
Politics		Discussion of politics and related topics.	Public
Science/Technology		Discussion of science-related and/or technology-related topics.	Public
Software		Software posting only; use group "Inferencium - Science/Technology" for discussion.	Public

Staff

For assistance within any group/channel, a moderator of the group/channel should be contacted. If an issue is related to a moderator, an administrator should be contacted. Administrators should not be contacted unless the issue cannot be resolved by a moderator.

Each profile of a staff member is represented by an ID in the form of a number beside their name. Any or all of the profiles can be used to contact the respective staff member. Staff members can also be contacted from within the groups/channels.

Note that SimpleX group/channel roles have a different naming scheme than stated here. For unification across platforms, "Moderator" will be used for lower-privileged users with the ability to remove members and their posts, while "Administrator" will be used for higher-privileged members with the ability to manage all aspects of the groups/channels.

To verify the legitimacy of a staff member, a random string can be sent and signed with their respective OpenSSH key(s). The signature can then be verified by the sender of the random string. For information on how to perform OpenSSH-signing and OpenSSH-verification, my documentation regarding it can be consulted.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIIFM8fjK85yAiUrB+wiu3z94b8TnQKkNpkb3/gsh3Na3

SHA256:BHnqlyBhEGsAYTuYNIJ/jtwStKch9MUuvbP1dQzc3fM

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIA7YvZSfu4zJzCxZMuiwDk738ai2vaLu/EqG/L7zOnF7

SHA256:cXnYROHnsj3xN+XzP3Npzv9/bwMdWRhquHKb3hW+ha8

Verification

Optionally, members of my platforms can choose to verify themselves via an OpenSSH public-key, in order to reserve their username and avatar, and protect against impersonation attacks. PGP is not supported (the Keys webpage contains more information on this matter).

OpenSSH-key-based verification is compatible with anonymity, at the expense of each anonymous profile being linked across platforms rather than being truly ephemeral. Members are free to use either their real-life identity or anonymous identities.

In order to verify themselves across my platforms, members must send an administrator or moderator their OpenSSH public-key. An OpenSSH key-pair can be generated specifically for my platforms. Should the public-key change for whatever reason, members must sign the new key with the previous key(s). It is essential that members keep the chain-of-trust intact; failure to do so will result in their verification being invalidated.

All public-keys are saved in a location only Inferencium administrators and moderators can access. Should a member wish for their public-keys to be removed from my systems, they can request it; this will immediately invalidate that member's verification. Using a key-pair generated specifically for my platforms removes the requirement to trust me or my infrastructure.

Upon joining an Inferencium platform, a randomly-generated string must be signed by each member wishing to be verified, via a previously-sent public-key. Failure to do so will result in the member being classified as an imposter and will be forced to change their username and avatar.

For information on how to perform OpenSSH-signing and OpenSSH-verification, my documentation regarding it can be consulted.

The status of OpenSSH key-types on my platforms are shown in the following table:

Supported key-types are valid for both new and current public-keys. Deprecated key-types are valid for current public-keys, but will not be accepted for new public-keys. Legacy key-types are no longer valid and must be replaced.