I swapped out all the coils and drip pans last summer. I didnt realize you can just tug on the coil and it just comes off. Game changer.

I cleaned the hoose and ended up with a box of stuff i wanted to toss. I listed everything in the box on nextdoor/fb for free and everything was gone by the end of the day. People love free stuff.

Niceeee. Love the windmill.

Thanks!

Thank you!

The most common one, complimentary reimagined.

Thanks!

Thank you! It is a green house thus all the glass :D

Thank you

Thanks!

Alternatively, eat using a funnel so that the food skips your mouth and ends up directly in the stomach. Then it cant damage your teeth and you still get all the nutrients /s

Thats why I never neuter or spay my cats. /s

I dont wear pajamas to bed but I wear it at home out of the bed because its cold and pajamas are more comfortable than wearing outdoor clothes.

Try turning on “Use cursors when loading the post feed”. Its under settings > misc > use cursors when loading the post feed. Let me know if this fixes the issue.

Explanation: I think you are hitting the max page limit. However I thought that limit is 100 pages so generally you shouldnt be able to hit the limit unless you scroll a ton. The limit can be set by the instance though so it might be a lower limit on your instance?

The limit doesnt exist when using cursors but cursors are buggy and certain combinations of sort order + hide unread doesn’t work. Thats why the app doesn’t load using cursors by default.

In the past, Summit used to hide unreads on the client side. I might have to bring that back because of the issue with cursors.

I have not been made aware of this issue. Is there any patterns to these 400 errors? Eg. does it occur when you perform specific actions, does it occur on one instance or multiple instances? Does it occur more often on certain days? Etc.

Well said. Thank you.

This isn’t a new thing. Essentially every “object” has an id and there is a translation API built into Lemmy that allows you to look up “an object” associated with an id on the current instance. The app uses this API to let you see a post from any instance. The logic has been the same for a very long time.

I would argue this is the normal behavior. The “abnormal behavior” would be to look up the same exact post on your current instance and then redirect to that post instead without the user knowing. However this is a case where the “abnormal behavior” likely results in a better UX. It’s like when Apple had to make their music shuffle algorithm less random so that it was perceived to be more random.

Back when Summit was first developed, federation could be hit or miss and pretty much everyone got a different experience of a post depending on which instance you viewed the post on. I’m not sure how true that is these days. So I made the decision that preserves the intended experience of link.

As an extreme example, let’s say someone asked what are some good recipes for beans and I knew of a post on !asklemmy@lemmy.world with some good answers so I link to the post. Now you open it on your instance but because of special instance settings and possible federation issues you only see bad bean recipes. So then you come back and yell at me for giving you bad recipes, but when I view the post on my instance I see good recipes only.

So as a compromise Summit, by default, shows the post as it is seen by the person who posted the link and optionally allows you to view the same post on your instance, while making sure the user knew what was happening.

That was the logic behind this decision.