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 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.
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.
Example Flairs
key
and store the preview inbody
.youtube link -> invidious link
bot will use the YouTube video’s ID askey
and store an link to the invidious instance in thebody
.key
and store the channel name, video title, and video duration in thebody
. OpenGraph is pretty useless for YouTube links.key
and store a summary inbody
.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.