First cut of showing federation staleness #436
Conversation
andrewmoise
force-pushed
the
warn-on-stale-magazines
branch
from
6c7d823
to
fa5d5d6
Compare
|
Discussion in Matrix is that this should be redone a bit (in addition to fixing the CI); I'll update and repush. |
This comment was marked as outdated.
This comment was marked as outdated.
|
Okay, I've adjusted it as discussed. We stop showing the existing "this is a federated magazine" warning, unless we're on the last page of results (i.e. there probably is more on the original server). And, we show a warning on non-subscribed magazines that they're not getting updates, including a display of how long it's been since they got any updates. |
Show an alert__info panel for magazines which don't have any local subscribers or for which we haven't attempted federation in over 24 hours. Add magazine_has_local_subscribers() to MagazineExtensionRuntime to support it.
andrewmoise
force-pushed
the
warn-on-stale-magazines
branch
from
5a396ac
to
ca3b199
Compare
There was a problem hiding this comment.
Just the 2 little things I mentioned in the comments.
About the lastActive thing: the field is getting updated whenever a new Entry, EntryComment, Post or PostComment is received. So this field is probably getting updated when you post something to a remote magazine. I suggest that you add a field lastRemoteUpdate to Magazine and set it the same way and on the same place as lastActive is set, but with the condition, that the magazine has an apId, the post or whatever does as well and that the domain of the apDomain of the post is the same as the magazine. That way we know we receive updates from the host.
This involves writing a migration, so a bit more fiddly for you, sorry 😅
melroy89
added
the
frontend
- magazines now have an additional property `last_origin_update` for when the last update came directly from the origin this is acting as the base for #436
|
After PR #503 is merged, we will update this PR I suppose? |
|
Yeah, that sounds good to me, I can take a look, it should be pretty much trivial if the new column is done for me, so I can do the update then if that sounds good. |
Co-authored-by: BentiGorlich <benjamin_g@posteo.de>
moved service worker registration into main app bundle, and also deferred the service worker registration a bit as recommended by https://web.dev/articles/service-workers-registration#improving_the_boilerplate, though our service worker doesn't seems to be doing anything much. this removes 1 inline script block from base template
changed entries summary in AP representation to draw from title instead from body, this way the title will be shown along with 'show more' button in most of other fediverse software, which should feel more intuitive and avoids repeating the body twice
|
Hm, how about this?: We could only update last_origin_update on posts or entries, not on comments, and only when we have local subscribers to the magazine. That way, it'd get a continuous flow of updates for as long as we were in good communication with the origin server, and with local subscribers, but not otherwise. It's a little not-ideal maybe because it wouldn't show anything if we aren't in communication with an origin server (and that's not an imaginary situation - IDK how mbin works but on Lemmy you can be "subscribed" to a community on a server that's defederated from you, and people on your server can interact with you, but it doesn't show any content from the origin. It'd be nice to show a warning for that situation). IDK, maybe keeping track of good communication per-remote-instance would be a good thing to track as an alternate way of triggering the same type of warning? But in any case for this change, if changing last_origin_update semantics sounds ok I'm happy to make the change. |
|
Sorry didn't get a chance to answer, yet. I'd like to merge this after I've looked at it again and deal with the I think the biggest problem is, that we cannot know whether the update is received because someone is subscribed to the magazine or to a user posting to the magazine if both, the user and the magazine have the same home server. That problem is there, regardless of how we deal with it. We could of course only update |
|
Ooh. Yeah, that makes perfect sense to me. I'm not super familiar with the federation details, but from what you say, updating last_origin_update when we get announces from the magazine actor sounds perfect. Okay, just LMK if there's anything you want me to do with it. |
|
All good. I think the requested changes are in now -- did you want me to modify the last_origin_update semantics though? To me it still seems like when it gets updated still isn't the perfect setup last I looked. |
|
Nono, I'll do it, but in a different PR. I'd appreciate it if you would create an issue though 😁 |
|
Done 👍🏻 |
|
The Info for
Is not getting added to the |
|
? What do you mean by this? |
|
I meant that if the magazine never received any updates the info that ypu can subscribe to get updates is not being displayed |
|
What? Last week you asked me to split it in two and only display the second sentence if the user is logged in. It's dependent on the existence of app.user, nothing to do with subscription status; you can look at the diff. |
|
Yes this message should only be displayed to logged in users, but that part is missing here |
|
Got it, I see what you meant. Fixed. |
ghost
self-requested a review
First cut of a fix for #362: Add warning panels analogous to the federated magazine panel.
In addition to checking whether the way I did the added internal functionality was right, it seems worth reviewing whether we should be making the "This magazine is from a federated server" panel more subtle, now that we have this? Having the bright yellow panels only show up if there's an actual problem seems better UX wise.