Hey everyone! I’m back from doing things for Ludum Dare and am starting work back up on Pangora.

Spent a bit setting up a backend so I can start implementing some backend features such as flairs and started some progress on the admin settings in Pangora-UI

My current plan is to add two new features onto the backend and then clean up and add everything from lemmy-ui that hasnt been added already to get it ready to be publicly tested. After which will be aimed for a first release

Flairs

The first feature being added is going to be flairs which is the main thing that ive noticed has been lacking when interacting with lemmy.

Flairs are split up into four different types

  • instance flairs
  • community flairs
  • post flairs
  • user flairs

Instance Flairs

Instance flairs are flairs set on the instance/site level to show what kind of content your instance contains. For example for programming.dev we can instance tag ourself with programming and mander can tag themselves with science. This can then be shown in the site sidebar and to categorize instances in sites such as https://pangora.social .

The instance flairs available will be the same across instances so that a consistent instance flair naming system can be enforced but people can freely request new flairs from the repo if theres one thats missing.

Community Flairs

Community flairs are set on communities to show what kind of content that community contains. These can be created by instance admins and set on a community by community mods

A community flair for programming.dev might be gamedev (to put on godot, unreal_engine, gamedev_news, play_my_game, etc.)

Post Flairs

Post flairs can be set on posts to categorize posts in a community. In a community about godot some posts may be tagged as help if its a help request, or news if its something such as news from the godot blog.

These flairs can be created by community mods and have a setting to make them either only able to be set by mods or be able to be set by both mods and users.

User Flairs

User flairs are community-specific and can be set on a user in that community. People might add a flair onto themselves if theyre an official developer for a software, or for more cosmetic reasons to theme themselves around the community

Admin Permissions

Second thing I want to add is different permission levels for admins. Currently adding an admin to your site gives them access to basically everything on the site. This can cause issues if you for example only want to add someone who can accept applications but dont want to give them access to causing chaos with your site information.

Entering a new permission system for admins. How this is going to work is new roles are going to be able to be created in the site and set to have different permissions. You can create an accepter role that can only accept applications, an emoji master role that is able to create and delete emojis on the site, an admin trainee role that is able to do most things in the site that can easily be reversed, and a standard admin role that is able to do everything.

Permissions are going to be all booleans and able to be stored in one variable length integer per role with one bit per permission (with the bit set to 1 if that permission is given, and 0 if not)

Admins with the role managing permission are going to be able to create and manage roles below them to add some new ones to the site. Instance owners have every permission by default and are at the highest level in the role chain and this cannot be changed without transferring the site ownership.

Ending Note

Thanks everyone for joining and watching the progress here on pangora! If youre interested in helping out feel free to join the matrix and I can help get you set up with the codebase. https://matrix.to/#/#pangora:matrix.org . Backend is in rust and frontend is using Next.js with TypeScript

This is something I’m currently working on part time with most of my time going to university (and some time going to gamedev) but as progress is concentrated on a couple features it still should be getting some good amount of development done. Its also downstream from lemmy so any updates and bug fixes the lemmy devs make will also be merged into Pangora to help keep the two as close as possible (and ill be making pull requests into lemmy once flairs and admin permissions are stable for them to accept or not. )

For transparency on who I am. I’m a computer science student in Canada currently mostly doing work in gamedev and webdev. I try to run AMAs every so often here in !iama@programming.dev and should be doing another one soon if anyone wants to ask me some questions there. Ive been mostly doing work on managing communities here in the instance but ive been onboarding some new admins and will start mostly working on development of Pangora in the future.

  • NeshuraA
    link
    fedilink
    English
    arrow-up
    1
    ·
    1 year ago

    Hey, given that you’re on the topic of flairs have you taken a look at this: https://github.com/Neshura87/Lemmy-RFC

    Haven’t really gotten around to opening that PR on the Lemmy Repo but will hopefully eventually, maybe check it out first to avoid your soft fork becoming too out of sync with lemmy (assuming the RFC would get merged which… I think is unlikely to happen given the main devs opinions on tags)

    • Ategon@programming.devOPM
      link
      fedilink
      arrow-up
      2
      ·
      1 year ago

      Ive seen that pop up but havent looked at it too closely yet. But yeah ill see if I can make my system similar (although I believe that RFC only has post flairs)

      • NeshuraA
        link
        fedilink
        English
        arrow-up
        1
        ·
        1 year ago

        RFC only has post flairs but the idea behind it should be expandable to pretty much anything that gets federated, be that user, community or instance

  • Dame @lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    1 year ago

    Why not use Admin/moderator roles that way it’s not too confusing and having multiple admins roles with various permissions?

    • Ategon@programming.devOPM
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      1 year ago

      The issue is theres a large amount of things admins can do and you might not want to let people in charge of doing one task have access to something else

      E.g. you can have people only for application accepting and not let them edit the instance itself or communities, or only community management and can’t do things like defederate from other instances

      Its more complicated than just an admin role but it shouldn’t matter for people other than admins that its a mechanic

      Instances can make as many roles as they want so they can just have admin if they want though but this lets them make them as needed