-
Notifications
You must be signed in to change notification settings - Fork 17
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
Correct Information about remote magazines #217
Comments
I thought the amount of subscribers being local only was a limitation of AP but it does appear mastodon is able to do it mastodon/mastodon#4840 |
How To get moderators from lemmy:
Lemmy uses the
|
To get the subscriber count:
|
Ok, so Lemmy uses a property from the offical activity pub standard: attributedTo
|
Maybe related fep-1b12. Think this is just proposals, but it seems to have come from lemmy. |
Very good hint, thank you 😊
Am 7. November 2023 23:29:24 MEZ schrieb e-five ***@***.***>:
…Maybe related [fep-1b12](https://codeberg.org/fediverse/fep/src/branch/main/fep/1b12/fep-1b12.md#group-moderation). Think this is just proposals, but it seems to have [come from lemmy](https://codeberg.org/fediverse/fep/issues/22).
--
Reply to this email directly or view it on GitHub:
#217 (comment)
You are receiving this because you were assigned.
Message ID: ***@***.***>
|
If I may jump in as a user (not a dev), I think there's still value in the local information. Re: subscriber count, the remote subscriber count is also not an accurate representation of all subscribers, as that still only tracks the host instance's local subscribers for that magazine/community. Having the local number and not just the remote number can help to give a sense of how concentrated a magazine/community is on its host instance, plus how much representation is in your local instance by comparison. The local sub count can help to understand what people on a given instance are interested in. Re: mods, user reports on a user's instance are (if it works the way I think it does?) being sent to both the local instance mod(s) and the remote instance mod(s) for that magazine/community. It's entirely possible for the user's local instance to want to action a post based on local instance rules even if the rules of the remote instance or its magazine/community's rules haven't been broken. Thus I think there's still value in showing who would be receiving those reports on the local instance. In both cases I would ideally like to have both the local and remote information shown for these two fields if that's something that could be shown without ending up too clunky or confusing UI-wise? |
I agree it'd be nice to see, not just for the points you mentioned but also because it was thought to be the key of whether your instance even gets data; magazines with 0 local subscribers tend to not receive any updates. I had discussed making this a blocker to v1.2.0, but for a few reasons changed my mind: one of those being that I realized that's just happenstance with, most likely, Lemmy that 0 subscribers mean no more updates. I noticed other linked software continues to send federated information regardless of unsubscribing. So I felt it might need more investigation if there is a way to even tell whether you're getting information anymore from the source, not sure if AP has a way to ask the source. Also not sure if AP provides a method similar to CAN-SPAM, something I need to look in to, because it seems some software could just not honor unfollow requests and continue sending you information. Regardless of all that, ironically right before you posted this I was looking into adding local sub count to the sidebar, my plan for it being in an
I'm not sure I fully follow on local mods, I'm not aware of whether instances are appointing local mods to remote magazines, that's definitely not a workflow I've thought about and not sure it would be valid. We're pretty sure reports for remote content do not make it to the remote instance, basing it off the fact that you can't even direct message remote users. I thought we had an issue related to this but I see now @BentiGorlich's issue was more about getting notifications about reports happening at all, not remote reporting. To your other point, I just mentioned this in
I think my plans to rework the UX of reporting are blocked behind being able to actually report remote content, though maybe it can be split up (To clarify, your reports go to local mods and the local admin/global mods, but for remote magazines obviously that would only be the local admin/global mods, nothing about the changes from the PR linked to this issue changed that, as it's how it always worked) |
The information from the remote instance are not just subscribers on their instance. The "original" instance keeps track of everybody who is subscribed to a magazine otherwise, how would the instance know where it needs to send new posts. So this number we now display is the total number of subscribers a remote magazine has. I agree that the local sub count could be useful, but outside of "no one on our instance subscribed, so this magazine might now get updates" I don't see the value of a real counter for local subs.
Reports should always go to your local admin and the global mods as well as the mods of a magazine. I do not understand why an instance would have mods specifically for a magazine that is not the property of said instrance (aka a remote magazine).
I do not think that we should list all the accounts that will probably get the report. It is true that your local mods and admins as well as the remote magazine's mods should get the report and we can describe that in the text above the input field, however I do not think that we should list the specific mods/admins for the post that you are reporting. |
@e-five256 if something still sends you data although nobody on you instance is subscribed to the group (AP term) or the actor fo the post than that is just wrong. You are not part of the audience if no one on your instance is "listening" and the remote server should respect that. So no there is not a endpoint to check whether you still get updates, because in theory you should have all the info needed. Maybe we should start rejecting posts where we do not belong to the audience? |
Something like that would be nice!
Some bad wording on my part, didn't mean to imply local instance moderators for a remote instance, just the local instance admin(s). |
Ah, I seem to have carried a misunderstanding over from when everyone was new and nobody knew how anything worked (but guessed) - thanks for clearing that up! I had been under the impression even the home instance only reported local subscriber counts (and only tracked subscribed instances, so didn't actually know the "true total" subscriber count).
Yep, just meant the local instance admins - didn't mean to imply mod-level users at the local instance policing a remote instance.
Fair enough! If the current thinking is to have something such as text saying as much that would be totally fine; I was just wanting to have the user know that (if the report does federate out, which sounds like it currently doesn't for kbin/mbin?) that both the local and remote ends get that report. So a specific list of local instance admins and a "btw this report goes to X and Y" are basically interchangeably able to fulfill that goal for me. |
Is your feature request related to a problem? Please describe.
The amount of subscribers of remote magazines and users is wrong. It only shows the the amount of local subscribers/followers.
Additionally the moderator of remote magazines is always the local admin, not the actual moderators of the magazine.
Describe the solution you'd like
The correct info should be fetched when initially looking a magazine or user up. Afterwards it should periodically refetch this information
Describe alternatives you've considered
Imo the solution above is the only one that is correct
The text was updated successfully, but these errors were encountered: