Enhancing Badges

[lilfade]

Discussion of badges, the uses and direction we should take this feature. I pulled in the comments from the prior post from #135 down below for review. And additional comments or ideas would be welcome for this feature.

---

(quite a bit of my own opinion mixed down below)

dunno where I heard this from but apparently badges were meant (or has been understood) to be something similiar to (post level) reddit flairs where it's most common application seems to be a kind of per sub/forum submission categorization. and additionally for reddit it can be used for submission filtering within sub/forum, like to either only show entries containing that flair or to exclude them from the listing.

take for (non reddit) example: Raddle's /f/egg_irl, it's those little boxes with short text besides the title. although for them it appears to just simply exist and cannot be used for filtering at the moment.

If we are to keep the badges then I think getting them to work just to this point would be a good start (although this would be a site specific features as I'm not too sure how to translate it to something that could be AP federated without resorting to json-ld extension).

---

awards on the other hand though can get axed for all I care, from what I can guess from global award page it looks like a top tier clout chasing feature and isn't of any use.

Originally posted by @asdfzdfj in #135 (comment)

---

Seems a general consensus so far on awards. I like your angle of the badges. Do we have any ideas on how to go about implementation I assume this would require a bit of the UI devs input here for possible options.

As for propagating to other sites that would indeed be a bit of a kerfuffle as we have to send more data to and from and then updates for these, likely getting the "flairs" to update to all places. Though that might touch on relaying and I'm sure that would need another topic/discussion itself.

Originally posted by @lilfade in #135 (comment)

---

I like the idea of badges/flares still in that case, let's see how we can shape this (we could use sub-tags to make it AP compatible). For instance we can leverage the AP tags, but instead of showing all the tag content within the magazine, we could leverage badges/flares to make it easier to filter if a magazine has multiple tags. My feeling is that we can definitely make this happen.

And I agree on the removal of awards, that can be fully removed that part from the code.

EDIT: Reintroducing awards or tipping can always be done later, if the community really wants it.

Originally posted by @melroy89 in #135 (comment)

---

Seems a general consensus so far on awards. I like your angle of the badges. Do we have any ideas on how to go about implementation I assume this would require a bit of the UI devs input here for possible options.

for full implementation details I think we might need a place to fully discuss and come up with a feature specification of sorts, maybe hash out some more details before starting serious implementation

as for some basic ideas I have floating around right now:

0. get it working first

• overall goal is to get a small text badge to display besides the entry title, similar to how one might use [this construct] in the title to categorize their entries.
• each magazine can have a set of predefined badges that can be set by magazine mod/owner
• the current badge settings UI in magazine panels is rather barebones, and I think changing it to works in a similiar way to adding tags when making entries would be an improvement
• when user is making a new entry, they could pick which badge (or up to 2) to apply to the entry, using autocomplete textbox that offers preset badges for selection should be sufficient. note that adding badges is entirely optional.
• (my opinion) maybe impose some restriction on badge text length, generally it should be succinct, about 40-50 chars should be plenty.

1. make it meaningful

• find a way to federate these badges over to other mbin instances, otherwise these badges is only useful on the origin instance and not so useful in the grand scheme
  • maybe these could be put into tag section of AP representation of an entry, perhaps something like this:

    {
      "@context": { /* ... */ },
      "tag": [
        {
          "type": "Badge",
          "name": "badge text",
          "magazine": "https://mbin.instance/m/magazine"
        }
      ]
    }

  • using native activitystream or existing well known json-ld contexts and constructs is preferred...
  • ...but do prepare to make our own extension
    • honestly, this might make our lives easier and more preferable that trying to gymnastic existing vocabs and properties to fit our semantic if a perfect fit term couldn't be found
    • come up with a common base indentifier for mbin specific json-ld context and extensions,
      • perhaps we might be able to leverage our github pages domain as namespace base if this additional github dependence is deemed acceptable
      • other projects tends to use their landing/main project domain for this, and we don't have any for the moment
• allow basic filter to either list entries containing a certain badge, or to remove them from listing.

2. add some possible useful enhancements

• allow badges with fully custom text, with setting to enable per magazine
  • sometimes some sub/forums doesn't really use badges/flairs for categorization like previously described,
    and on the occasion that it comes up the texts within is most likely for fun, for actual "flair".
• allow multiple badges to be applied to one entry
  • configurable upper limit either per instance or magazine
  • tread carefully: (my opinion) overall badges should be succinct. this is not a substitute or another space for hashtags
• allow more complex entry filtering criteria with badges
  • selecting or excluding multiple badges at once
  • selecting with one badges not if another badges is also applied
• colorable badges for easier reading/grouping

Originally posted by @asdfzdfj in #135 (comment)

[asdfzdfj]

prior discussion on kbin side: https://codeberg.org/Kbin/kbin-core/issues/658

---

on attaching the badges to AP representation: another possible way to do this is perhaps making use of PropertyValue, perhaps something like this (other contexts/properties omitted):

{
  "@context": [
    {
      "PropertyValue": "https://schema.org/PropertyValue"
    }
  ],
  "tag": [
    {
      "type": "PropertyValue",
      "name": "Badge",
      "value": "badge text here"
    }
  ]
}

[e-five256]

May have some overlap with LemmyNet/rfcs#4 if I understood correctly. At least when it comes to federation of these things. Use case wise I'm not quite sure, the examples there and here don't quite match up, so if it seems like the goals are separate just let me know

[asdfzdfj]

thanks for linking that, that looks interesting.

it does raise some good points (for me):

• using a custom object (mbin:Badge for us, if we somehow ended up with this before them?) and give it an id such that the badge could be federated in a better way (e.g. their Update/Badge activity example)
• allow multiple badges to be added for one entry, with maybe configurable upper limit
• ability to have badges where it would mark/imply the tagged entries as sensitive

I'm still don't know about hierarchical badges though, like sure having NSFW/* to signify sensitive content and why it's so is kinda good and I could get behind, but some examples over there feels like it's trying to use this hierarchical ability to make/reinvent groups/"group within a group" or something similar, though I think this stems from differences in (perceived) needs for groups: my idea here was mostly made in image after reddit flairs, where it's tied to a specific subs and you'll likely need them in order to get a complete meaning (and the existing code/infrastructure seems to be more suitable to make this kind of thing), whereas the one suggested in there wants it to be more decoupled from groups but may ended up with side effect of encoding the same grouping information in a different way with its heirarchical ability

perhaps what I have here is just a subset of what that rfc purposes

EDIT: some interesting tidbits regarding tagging and rfc

• https://lobste.rs/about#tagging
• https://docs.tildes.net/instructions/hierarchical-tags
• https://safebooru.donmai.us/wiki_pages/howto:tag (personal anecdote but it looks like there's some convergence towards *booru-styled tags being proposed/preferred)

[github-actions]

This issue is stale because it has been open 50 days with no activity. Remove stale label or comment or this will be closed in 6 days.