jgrim commented 7 months ago

🌿 Flair Design Doc

Flairs for 4 kinds of things: users, communities, instances, posts.

Flairs have a slug (that will not change and will be used to reference against in things like bots), text (what is shown on it), a color (the background color of the flair), support emojis in text, and have hover text (shown when hovering over it so you can do something like a heart for donators and then say Donator when you hover over it.

Flair Groups

Used to logically separate types of flairs. Groups can be set so theres a maximum amount of flairs from the group that can be added to one thing and a minimum amount of flairs from the group that can be added (setting both to 1 for post flairs would be used for setting post type to help, news, etc., having it uncapped could be used for cosmetic ones (or a maximum of 5 or something can be placed on the cosmetic ones to prevent flair spam).

Flairs do not have to belong to a group but can be moved, in, out, or between groups

Flairs that can be set to only be used by users, only be used by mods, etc. can have that set in the group so that it is group wide. Same for editable flairs, and basically all other options.

Post Flairs

Used to mark posts as different things such as what type of post it is (e.g. Help post, news post, etc.), flag certain subcontent (such as in a programming community flairing gamedev or webdev, etc.), etc.

Can be created by mods of a community to be used in the community or admins of an instance to then be instance wide. (when instance wide, moderators can "fork" the flair to add their own custom customizations to it and have that used instead (same slug though))

Can be set to be able to be set by users or only be set by mods/admins

Flairs can be marked as editable which allows users to edit them before being used on a post (used if you want users to be able to customize tags a bit to give details that its feasible to make tons of flars for or do completely custom ones). (still shares the same slug)

Can have hashtags assigned to flairs that will add hashtags to posts marked with the flair (for things like viewing them from mastodon and other microblogs)

User Flairs

Used to mark users within a community or within an instance. User flairs created by moderators are only visible within a community while admin created ones are visible within the entire instance (maybe both flairs from the instance the community is in and the instance the user is viewing it from are shown when looking at a post) (when instance wide, moderators can "fork" the flair to add their own custom customizations to it and have that used instead (same slug though))

Can be set to be able to be set by users or only be set by mods/admins

Flairs can be marked as editable which allows users to edit them before they add them to themselves. (still shares the same slug)

Used for vanity customization or to mark people as things such as donators, developers, etc.

Community Flairs

Used to mark communities as things. E.g. a Godot community might flair themselves with a gamedev flair as they are a game engine. These can be created by instance admins and set by moderators or admins.

Flairs can be marked to be able to only be set by admins or they can be set to be used by moderators

Can be marked as editable to allow moderators to edit them before using them on a community (still shares the same slug)

Can have hashtags assigned to flairs that will add hashtags to posts made on the community (for things like viewing them from mastodon and other microblogs)

Instance Flairs

Used to mark instances around certain topics or for other tags. Equivalent to tags in fediseer

Can be created by developers and have tags that are standard for certain things (e.g. if we want tags for technology, programming, music, etc.) that can be easily referenced against since people use the same one due to it being standard

Can also have custom ones created and set by instance admins

Instance flairs can be used by instance finding sites to allow people to filter by topic

Pdzly commented 7 months ago

My data model idea would be like ( i would add flairs to comments too ):

{
    "id": 1234,
    "name": "my flair",
    "tooltip": "What a nice flair!" | null,
    "ap_id": "...../flairs/id",
    "type": "post" | "user" | "community" | "instance" | "comment",
    "color": "#hexcolor",
    "permissions": null | "mod" | "admin" # null = everyone, "mod" = Mod or above, "admin" = admin only,
    # Note: Specific "types" will be ONLY "admin" e.g. instance or ONLY null OR "admin" e.g. user
    "group_id": 4321 | null,
    "community_id": 123 | null # null = instance,
    # Note: Specific "types" will be ALWAYS null e.g. instance
    "editable": true | false,

}

# Edit Data

{
    "id": 1111,
    "edited_name": "Wow i can edit this",
    "edited_tooltip": "Secret!!!!" | null,
    "creator_id": 2222,
    "flair_id": 1234,
    "post_id": 11111 | null,
    "community_id": 1122 | null 
  (etc. for each  other "entity" )
}

# Flair Group

{
    "id": 4321,
    "ap_id": "...../flairs/groups/id",
    "name": "Nice flair group",
    "permissions": null | "mod" | "admin" # null = everyone, "mod" = Mod or above, "admin" = admin only,
    # Note: Specific "types" will ignore this and be ONLY "admin" e.g. instance or ONLY null OR "admin" e.g. user
    "minimum": 0-maximum,
    "maximum": -1-9999999 # -1 = unlimited,
    "editable": true | false
}

# changes to the instance config

{
    ....,
    "post_max_flairs": 1234,
    "user_max_flairs": 1234,
    "community_max_flairs": 1234,
    "comment_max_flairs": 1234,

}

# For each "entity" where a flair can be added there should be a M to N table like

{
   "flair_id": 11111,
   "post_id": 2244
}