Elizafox's Ramblings

Someone mentioned that there should be a spec for #nobot, so I'm going to write one.

It's going to be the simplest thing that does what everyone expects it to do.

I'm also going to include #noindex and any other bot tags.

Without further ado...

Specification

This document specifies a proposed standard for consensual interactions with bots on the Fediverse and other social media platforms.

This document is licensed under the CC0-1.0 or later.

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.

This document is a living specification and is versioned in accordance with semantic versioning.

This version of the specification is 0.2.5.

Rationale

Many users of the Fediverse and various social media platforms do not wish to be followed by bots, or interact with bots in any way, or do not want interactions they did not initiate.

A de facto standard has arisen, the “#nobot” and “#noindex” hashtags in profiles.

Most bots already respect these hashtags. This specification simply clarifies what bots should do when and where they encounter the tags, and what bots should check for. This also gives a semantic outline of how opt-in and opt-out bots are generally expected to behave.

Bot actions

There are two classes of bot actions for the purpose of this specification: direct and indirect bot actions. When the term “bot action” is used alone, it SHALL be construed to mean both indirect and direct bot actions.

Indirect bot actions

An indirect bot action for the purposes of this specification is defined as one of the following:

• Retrieving a user's metadata for purposes aside from checking for tags
• Retrieving a user's post history
• Boosting, reblogging, or reposting the post, or a related action
• Favouriting, liking, or reacting to the post, or a related action

Direct bot actions

A direct bot action is defined as any of the following:

• Replying to a thread
• Directly or privately messaging a user

Opt-in and opt-out

A bot is classified as opt-in or opt-out based on its behaviour and method of consent for bot actions.

Opt-in

A bot is defined as “opt-in” if the user MUST follow or directly interact with the bot in some form, such as in a private message, to perform a bot action. A specific tag MAY also be used. An enrollment system MAY also be used.

Opt-in bots SHOULD NOT perform direct bot actions in any way without prior interaction, and MUST NOT perform any indirect bot actions without consent.

Opt-out

A bot is defined as “opt-out” if the bot will perform bot actions without prior opting-in by the user.

Bots SHOULD NOT perform direct bot actions on an opt-out basis.

There is the possibility of privacy concerns with non-consensual indexing of users. Please consider privacy and legal ramifications very carefully before indexing users on an opt-out basis.

If a user has opted out through one of the mechanisms below, then an opt-out bot MUST NOT directly interact with the user. Indirect bot actions MAY be permissible, provided the user has interacted with the bot first.

Following an opt-out bot MUST NOT override the semantics of any of the tags mentioned below.

Guidance

Bots SHOULD be opt-in, not opt-out. It it strongly RECOMMENDED that new bots SHOULD be opt-in.

However, an unfortunate reality is that many bots exist which are not opt-in. Therefore, this specification will deal with both.

Non-conforming bots MAY be blocked by users and admins, so adherence to the specification is strongly RECOMMENDED.

Tags

The following tags are defined, which MUST have the leading octothorpe on the Fediverse and platforms which use “hashtags”, but MAY NOT on platforms that use another tagging mechanism:

• #nobot
• #noindex
• #bot
• #index
• #yesbot
• #yesindex

Valid locations for tags

When a mechanism for opt-in or opt-out uses a tag, any of the described tags MUST be put in the biographical or about page of a user who wishes to opt in or out of specific functionality to take effect. Bots MUST parse this information and search for any tags relevant to its operation as outlined further in this specification.

A user MAY place the tags in a specific “tags” field. Bots SHOULD check this field as well, if applicable.

Tags MUST NOT be parsed from any other source.

Conflicts

If two tags conflict with each other, it is unspecified what a bot may do. Regardless, bots SHOULD respect the most restrictive policy specified by the tags. For example, #nobot SHOULD take precedence over #noindex.

#nobot

The #nobot tag SHALL opt the user out of indirect interactions with bots. All opt-out bots MUST respect this tag, regardless of functionality.

The #nobot tag SHOULD imply #noindex. Users are nonetheless encouraged to use both tags if they do not wish to be indexed nor have any non-consentual bot interactions.

#noindex

The #noindex tag SHALL opt the user out of indexing by bots. All opt-out bots which perform indexing MUST respect this tag.

#bot

The #bot tag SHALL indicate the user in question is a bot. It is RECOMMENDED all bots put this in their profile or biographical information or tags section or equivalent, if there is no other means on the platform to identify a bot.

#index

The #index tag SHALL indicate the user in question is an indexing bot. It is RECOMMENDED all indexing bots place this tag in their profile or biographical information or tags section or equivalent.

#yesbot

The #yesbot tag SHALL indicate the user in question opts into all bot actions, but MAY NOT have opted into indexing.

#yesindex

The #yesindex tag SHALL indictate the user in question opts into being indexed. The user in question MAY NOT have opted into any other bot actions.

Following

If a user follows a bot, they SHALL be deeemed to have opted into bot actions, unless a conflicting tag is present. In such cases, the tag takes precedence.

Following a bot MUST NOT be construed as permission to index the user.

Blocking

If a user blocks a bot, they SHALL be deemed to have opted out of all bot interactions. Bots MUST NOT attempt block evasion. However, such bots are usually malicious and wouldn't follow the specification regardless.

Caching

A bot that caches consent information such as tags MUST refresh that data upon request, or SHOULD refresh it at least once per hour per any bot action with the user in question.

Revocation and granting

Consent MAY be revoked or granted at any time by users. See the section on “Caching” for more information.

Authorship and conflicts of interest

This specification has been authored by Elizabeth Myers.

The author(s) of this specification assert they have no conflicts of interest related to this specification.

Version history

• 0.1: initial revision
• 0.1.1: minor corrections
• 0.1.2: formatting fixes
• 0.1.3: clarify opt-in and opt-out slightly
• 0.1.4: change “ban evasion” to “block evasion”
• 0.1.5: clarify what opt-out bots should do
• 0.2.0: add section on caching and revocation
• 0.2.1: clarification and fix wording on opt-in
• 0.2.2: notes about behaviour with conflicting tags and specify that #nobot should include #noindex.
• 0.2.3: strengthen wording about opt-out being not recommended.
• 0.2.4: add enrollment as part of opt-in
• 0.2.5: disallow parsing of tags from any other source

— Elizabeth Ashford (Elizafox) Fedi (elsewhere): @Elizafox@social.treehouse.systems Tip jar: PayPal || CashApp || LiberaPay