Post Flair and Bots

Everybody hates bots, especially bots that essentially act rouge replying as comments with useless information. Reddit’s post flairs were also somewhat useful. I propose a new system that unifies these ideas under a pro-user regime.

I don't know rust, so I'll speak mostly in example postgres schema.

CREATE TABLE flair_item (
    id serial PRIMARY KEY,
    -- each flair item is created and managed by a bot

    bot_id INTEGER,
    -- the bot designates a uniq identifier for each flair piece.
    key TEXT,
    -- when collapsed, the clickable must describe itself
    display_name VARCHAR(100),
    -- when uncollapsed, the flair has useful content
    body TEXT,
    -- maybe needs to be removed by moderator? IDK
    removed boolean DEFAULT FALSE NOT NULL,
    published timestamp NOT NULL DEFAULT now(),
    updated timestamp
);
CREATE UNIQUE INDEX flair_post_key ON flair_post (bot_id, key);

Example Flairs

• An OpenGraph bot will use the URL as key and store the preview in body.
• A youtube link -> invidious link bot will use the YouTube video’s ID as key and store an link to the invidious instance in the body.
• A YouTube bot will use the Youtube video’s ID as key and store the channel name, video title, and video duration in the body. OpenGraph is pretty useless for YouTube links.
• An LLM summary bot will use the URL as key and store a summary in body.
• A video transcription bot can store a text transcript in body.

Flair items will show up under a post. The first flair will be “open” (think accordion) and the rest collapsed. A sorting mechanism will need to be added. For example, a post that links to a YouTube video should have the YouTube flair first, but a post that contains several links might not. The flair_post_key unique index is to help make sure a bot isn't repeating the same summary multiple times in the database.

CREATE TABLE flair_bot (
    id serial PRIMARY KEY,
    -- like a username, but for bots
    name VARCHAR(100),
    display_name VARCHAR(100),
    -- description of bot
    bio TEXT,
    -- maybe an experimental one needs to get disabled?
    removed boolean DEFAULT FALSE NOT NULL,
    published timestamp NOT NULL DEFAULT now(),
    updated timestamp
);

-- posts can have multiple links, and multiple posts can refer to refer to the same link
-- so posts and flair have a many-to-many relationship
CREATE TABLE flair_post (
    bot_id INTEGER,
    flair_id INTEGER,
    post_id INTEGER,
    removed boolean DEFAULT FALSE NOT NULL,
    published timestamp NOT NULL DEFAULT now(),
    updated timestamp
);

-- users opt-in or opt-out to each bot. Instance owner probably chooses which bots are default opt-int.
CREATE TABLE flair_bot_user (
    user_id INTEGER,
    bot_id INTEGER,
    removed boolean DEFAULT FALSE NOT NULL,
    published timestamp NOT NULL DEFAULT now(),
    updated timestamp
);

• Should flairs federate?
• Bots might have a API keys or webhooks so flairs can be generated asynchronously by external systems or could be built-in to the Lemmy binary.
• Brave instances might let users create their own flair bots.
• This flair system could be expanded to cover comments and users in addition to posts.

No implementation files or tests are identified. Start by reviewing the proposed flair_item, flair_bot, flair_post, and flair_bot_user schemas, then resolve the open questions about federation, bot integration, opt-in behavior, and scope; done means an agreed design with clear implementation entry points.