Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post Flair and Bots #7

Open
TabithaES opened this issue Mar 7, 2024 · 1 comment
Open

Post Flair and Bots #7

TabithaES opened this issue Mar 7, 2024 · 1 comment

Comments

@TabithaES
Copy link

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.
@dessalines
Copy link
Member

Flair is really just another name for tags, which is what #4 is about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants