the /c/imaginary x spam is killing me. (lemmy.fmhy.ml)

submitted 1 year ago by AmbleHamble@lemmy.fmhy.ml to c/freemediaheckyeah@lemmy.fmhy.ml

68 comments fedilink hide all child comments

Browsing new or Hot and seeing 15 posts in a row to /imaginarytanks, /imaginarycars, /imaginaryaviation, etc. got old the 2nd time I've seen it. I've had to resort to blocking the communities and bot that's just spamming for content.

you are viewing a single comment's thread
view the rest of the comments

[-] Martineski@lemmy.fmhy.ml 2 points 1 year ago

I need to mentally prepare my ADHD brain for this before reading it xD. I will go do something else before I get ready lol.

[-] Zeus@lemm.ee 1 points 1 year ago* (last edited 1 year ago)

no worries, i don't even expect you to respond to all of it. i did just sort of ramble for a while. but i thought it might be good to have on hand when you talk to neshura

i didn't even read it that much, so i apologise for any formatting errors (i wrote it in a text editor outside of lemmy)

[-] Martineski@lemmy.fmhy.ml 2 points 1 year ago* (last edited 1 year ago)

Alright, my response is... Tags won't function like mastodon and such, each community will have their own tags to further categorise content of a general topic that sublemmy is about. (Edit: actually, I think it may be do BOTH of those things now that I read my conversation with the dev again)

This is what the dev said about stages of tag system (in my conversation with him on dc):

Stage 1: Tagging and Presets (Community and Instance, no User defined Tags allowed)

Stage 2 (not sure if I'll do that): Filtering, Cosmetics? (Border, Text Color)

And this is what he told me when I asked about the possibility of stage 3 of the tag system where you can subscirbe to only certain tags so only choosen content from a community shows up on your feed:

I think backend wise not worrying about that is fine for now, the separation of tags per community can be achieved by filtering tag AND community ID in the filter, which could just be hidden from the user or displayed, there's a separate discussion to be had about the filter features. Point is not separating these tags per community shouldn't limit their filterability because community id's already exist. Plus by not splitting them up in the backend general tags can be used across instances a lot more easily.

Subscribing to tags in a community could then work similar to that filter, again the issue would be how to make the UI bearable but backend wise should be no problem to implement.

So my idea is possible from what he told me. The problem is that we need to make the idea known and we need to find someone who will work on it because the dev isn't even sure if he will be the one that implements stage 2 when I'm talking about stage 3. Also, to implement my ideas for stage 3 we need foundation to be laid out which means that the stage 1 and stage 2 need to be completed first.

For the stage 3 to be implemented (if anyone decides to implement this AT ALL) we will need to wait for weeks at best and months at worst. Now this makes it hard for me to decide how to proceed with my communities because the path of the tag system is not yet clear and I need to decide NOW which communities should be separate and which should become more general.

Edit: I talked with the dev, it will take months to reach stage 3. And I realised just now that not all content on c/imaginaryaviation will be vehicles which means that I will need to a create a new sub called c/imaginarylocomotion to be able to fully capture both of the subs.

[-] Tywele@lemmy.dbzer0.com 3 points 1 year ago

I really like the idea of subscribing to/filtering of a tag (tags that are predefined per community by a mod) of a community.

[-] Zeus@lemm.ee 3 points 1 year ago* (last edited 1 year ago)

(Edit: actually, I think it may be do BOTH of those things now that I read my conversation with the dev again)

yeah, the thread was hard to follow due to people talking about different concepts without realising. i feel like that would need to be clarified before implementing one (or both[^hopefully not])

Stage 1: Tagging and Presets (Community and Instance, no User defined Tags allowed)

Stage 2 (not sure if I’ll do that): Filtering, Cosmetics? (Border, Text Color)

yeah this seems fine (although cosmetics seems like a late stage issue to me, but meh)

I think backend wise not worrying about that is fine for now, the separation of tags per community can be achieved by filtering tag AND community ID in the filter, which could just be hidden from the user or displayed, there’s a separate discussion to be had about the filter features. Point is not separating these tags per community shouldn’t limit their filterability because community id’s already exist. Plus by not splitting them up in the backend general tags can be used across instances a lot more easily.

Subscribing to tags in a community could then work similar to that filter, again the issue would be how to make the UI bearable but backend wise should be no problem to implement.

i'm not surprised, that makes sense. as an aside: there are community id's? like, uuid's? or does he mean just comm@instan.ce which is, i guess, an id?

For the stage 3 to be implemented (if anyone decides to implement this AT ALL) we will need to wait for weeks at best and months at worst. Now this makes it hard for me to decide how to proceed with my communities because the path of the tag system is not yet clear and I need to decide NOW which communities should be separate and which should become more general.

in my (irrelevant) opinion, separate communities are better. it's a paradigm that everyone knows, rather than some nebulous proposal that 1) may not be implemented 2) may be lacking features (rss etc.) 3) will almost certainly be more complex to use. also you could merge them at a later date and add links to the archived versions in the sidebar. not really optimal, but it is a solution

adding them all together won't prevent spam (although i guess it would make it easier for people to block..). there will be the same volume of posts, just all in one place. i have been trying to avoid flooding local though. i have a whole folder of art to add to these subs. although to be honest, i've no sympathy with the op. browse subscribed if you don't want to see irrelevant posts. if you browse all, be prepared to see posts you have no interest in

Edit: I talked with the dev, it will take months to reach stage 3. And I realised just now that not all content on c/imaginaryaviation will be vehicles which means that I will need to a create a new sub called c/imaginarylocomotion to be able to fully capture both of the subs.

ah yes, convoluted and intermingled subs. fun

[-] Martineski@lemmy.fmhy.ml 2 points 1 year ago* (last edited 1 year ago)

i feel like that would need to be clarified before implementing one (or both[^hopefully not])

The dev will write a github issue with everything described for stage 1 of tags before proceeding to gather opinions. But he will only mention stage 2 and stage 3 of tags and I will have to make issues for stage 2 and 3 myself.

yeah this seems fine (although cosmetics seems like a late stage issue to me, but meh)

I would love to have an option for customizing the looks of the tags to make it more easly browsable when you have more than just a few but yeah, it's not something that would need to be implemented in stage 2.

i’m not surprised, that makes sense. as an aside: there are community id’s? like, uuid’s? or does he mean just comm@instan.ce which is, i guess, an id?

I just found this on github. It was mentioned by nutomic a month ago:

Each Activitypub object (post, comment, user, community) has an ID. In case of posts this looks like https://lemmy.world/post/1 with the domain where the creator is registered. When another instances fetches the post, it inserts it in the db and renders it as a link with the db post.id column value, eg https://lemmy.ml/post/3. So the problem is that the url id is exactly the same as the db id, which naturally differs between instances. A cleaner solution for this would be random IDs as described in #1101. This is what Peertube does for example.

ah yes, convoluted and intermingled subs. fun

Yeah, that would make the sub waaaay too general. I will leave the imaginary aviation as a separate sub but imaginary ships/subs on the other hand is something that I can merge with imaginary vehicles. I also think that I can merge imaginary armies with imaginary characters and just give them their separate tag once they come out. There shouldn't be a problem with both of those cases.

I also have this weird sublemmy called "imaginary cities/cityscapes/landscapes" because it's about cities but cityscapes very often are also portraying a landscape. I can either make "imaginary scapes" (ik this sounds weird lol) and use it for starscapes, landscapes, skyscapes, cloudcapes etc. and have a separate sublemmy for showing inside shots of cities/villages where far away shots of them would be counted as a "scapes" to which will be included in "scapes" sublemmy and not the sublemmy about cities/villages. The second option is to include cityscapes in sublemmy about cities and repost artworks to imaginary scapes if it contains a landscape on top of a cityscape. But that would result in a lot of reposts though and this would make the OP very sad. There's also a third option where I include scapes, cities, cityscapes and villages into one place BUT that's not the content of the same topic which is a very not cool thing to do. What do you think?

Edit: I also think that I could move imaginary tanks into imaginary vehicles too.

[-] Zeus@lemm.ee 2 points 1 year ago

The dev will write a github issue with everything described for stage 1 of tags before proceeding to gather opinions. But he will only mention stage 2 and stage 3 of tags and I will have to make issues for stage 2 and 3 myself.

i guess i'll have to keep an eye on the gh then - presumably it'll be on lemmy-ui

I also have this weird sublemmy called “imaginary cities/cityscapes/landscapes” because it’s about cities but cityscapes very often are also portraying a landscape. I can either make “imaginary scapes” (ik this sounds weird lol) and use it for starscapes, landscapes, skyscapes, cloudcapes etc. and have a separate sublemmy for showing inside shots of cities/villages where far away shots of them would be counted as a “scapes” to which will be included in “scapes” sublemmy and not the sublemmy about cities/villages. I also have this weird sublemmy called “imaginary cities/cityscapes/landscapes” because it’s about cities but cityscapes very often are also portraying a landscape. I can either make “imaginary scapes” (ik this sounds weird lol) and use it for starscapes, landscapes, skyscapes, cloudcapes etc. and have a separate sublemmy for showing inside shots of cities/villages where far away shots of them would be counted as a “scapes” to which will be included in “scapes” sublemmy and not the sublemmy about cities/villages

i, personally, would prefer the former. i don't know which is objectively better, but i was actually considering making a "grungy hamlets" sub.[^stuff like this] although i didn't really know what to call it. so i'd like / will make a "street level views of mediævil/vicorian/cyberpunk distopic towns", but i have no interest in wide grandiose vistas.

i don't really have strong opinions, but that's my thoughts. i wonder if we should make some sort of discussion group with tywele, sebinspace, and remus989 to make co-ordinated decisions?

[-] Martineski@lemmy.fmhy.ml 2 points 1 year ago* (last edited 1 year ago)

Alright, inside city/village shots will have their own sublemmy and cityscapes will be moved to scapes.

i wonder if we should make some sort of discussion group with tywele, sebinspace, and remus989 to make co-ordinated decisions?

YESSS, I was already thinking about it but I wasn't sure how to proceed with that.

Edit: I just realised that merging imaginary soldiers/armies with imaginary characters is not an option because imaginary characters sub focuses on single characters.