When a community is not yet federated on the instance (or post is from before federation) enabling notifications for it makes backfilling of past posts trigger notifications too
I don’t have an opinion if this is wrong per se but I think I’ve discovered an edge case that I decided to share
Scenario 1:
- I discover some communities on another instance that my instance doesn’t know of yet
- I open my feeds and add them to a feed that has notifications enabled
- at this point communities are empty, backfilling of IIRC 50 last posts will happen soon
- wait a bit
- suddenly my notifications get drowned in past posts
Scenario 2:
- I have a community that has notifications on, either directly or via a feed
- out of the blue I get notification about some old post. Not a comment inside, the post itself. As if it was just posted. But all the dates inside are in the “far” past
I guess what happened in scenario 2 is that someone did “retrieve remote post”
Logically it makes sense but I guess it might be disorienting to some from pure UX perspective. I know of backfill and it does serve the purpose of showing that federation for community is working. But TBH what I expected was to start getting notified on new posts, not the old ones
On one hand, to me, addressing that feels like going after Pareto hard
On another, when someone migrates to a newly set up instance, that will be the behaviour of notifications
You must log in or # to comment.
Scenario 1 -
That is perhaps less than optimal. Maybe we can have a new notification subtype that just sends one notification for a new community being added to the feed, and not notifications for every single post? Since there are new posts in the feed, I feel like at least one notification does make sense, especially for anybody following the feed that isn’t you (the person that added the community).
This does beg the question though; if we have a notification for a new community added to a feed, do we also have one for when a community is removed from a feed? I think these should only go out to users that have the activity alert turned on; it would be too spammy to send this to every person that subscribes to a feed.
I am going to ping @Skavau@piefed.social as our resident feed power user to see what their thoughts are.
Scenario 2 -
This is something we have talked about in the past and decided to keep it (though always open to more perspectives). As you suspect, this happens when old content that wasn’t originally federated to your instance is either fetched manually or the old post was edited by the OP in some way. The last time a user brought this up we basically decided that it might be confusing, but it isn’t really spammy in the same way that your first scenario is. Also, it is a new post in the community/feed that they are subscribed to, so it isn’t wrong to notify them about it.
new notification subtype that just sends one notification for a new community being added to the feed
I think that in itself would not stop the notifications from backfill to flood notifications. I was rather thinking about suspending notifications from that community until backfill finishes. But I have not looked into PieFed code, no idea how much of a nightmare to address an edge case that would be
I agree that would be the hard part of what I proposed; controlling what posts send notifications to activity alert subscriptions vs. not. To get a bit technical, we would have to add an option to the post creation flow where we specify whether this post should trigger activity alert notifications or not. When it is being created as part of a backfill for a newly federated community it would not send notifications, otherwise, the default behavior is that it does (what happens now). I haven’t looked at the code yet to see how difficult this might be to do, but that is the high level of what would need to happen.
As for potential new notifications about communities being added/removed, that is much more straightforward.
