Notices tagged with diaspora

Looks like @Robbie is #newHere give them a follow particularly as I believe his #Diaspora* Pod is smaller they'll need more federation to see what we offer here on the #Fediverse

♲ @robbie@diaspora.ragesoss.com:

Kids Are Getting a Bad Reputation and it's Not Justified

I'm still #newhere because I wanted a place to make a #blog that doesn't make me make an account, pay for it, or have ads to pay for it. So here's my first blog entry.

All you see on TV #news or on the internet about #kids is about how stupid kids are, how confused about everything from #science, especially #biology, to #history and human interaction. Maybe in big cities where #education is all corrupted by politics that might be true. But I don't think you can write off a whole generation because kids in the news don't know which bathroom to use and can't tell you anything about the history of their own country and culture. We're not all like that! In fact I think the majority of kids, the ones you never hear about, aren't so ignorant and confused as people think.

I wonder if that is true about a lot of things. Watching the news it all looks bad! But people find ways to make life work and get through life without all that drama and without wars and protests and things that just make noise and hide the real truth behind one crisis after another.

#Adults reading this should know that probably most kids aren't all mixed up about their identity or their gender. The only thing really in doubt is our future, because the world we are about to inherit is a big battleground where the powerful compete for more power and who use confusion and mayhem to accomplish it.

Is anyone else having Friendica/Lemmy federation issues?

!Fediverse !Fediverse (JP) I am subscribed to many #lemmy communities from Friendica. I really love how it works, showing up as Friendica #Forums and basically just being exactly what I want (and one of the reasons why having your #friendica account enabled 👍 & 👎 is important for the upvote/downvote #features). It is WAY better than trying to follow such communities from #mastodon and I personally like the convince of one account and the UI better than Lemmy's native. It feels like it used to work seamlessly, however over the last few months something doesn't seem to work as well. I don't see nearly as many posts in my Network feed anymore, not all of my posts ever seem to actually be shown on the community page I put new posts to when I go there after being surprised, I haven't had any reactions/comments after a time, and a whole lot of comments and reactions to stuff I have posted successfully never show on my side when they do. I'm not sure if it's a recent change to #Friendica or #lemmy that has affected it, or perhaps if it's related to the #RedditMigration and the sheer number of additional users/connections/traffic the various Lemmy instances have than they did a few months ago. I haven't filed an issue because I am not sure where to even start. It could even by my attempts to always cross post, by putting various tags for @ and ! in posts like this, which iirc used to work just fine too, but even I only post to one I'm still seeing extreme delays, and/or lack of federation at all. also, frequently DELTE & RE-DRAFT rather than EDIT, particularly due to having friends on #Diaspora* and #GNUsocial that don't support EDIT, and somehow, I feel like that might have an impact too? #DazedAndConfused #andStatus @AndStatus project @redditmigratoin@kbin.social @Friendica Support

♲ @denschub@pod.geraspora.de: Okay, here's a fun little story about a rabbithole I just fell into. It's about running the #diaspora project web infrastucture, and probably a glance behind the scenes.

Last week, I got an alert about unusually high load on the diaspora* project webserver. I was traveling for work, and the alert resolved itself after a couple of minutes -- so I ignored it. However, earlier today, I once again got alerted, this time about the wiki responding somewhat slow.

This was unusual. Some of our web assets, like the project's website or Discourse, do get quite a bit of traffic, sometimes holding a steady load of 5+ requests per second. The wiki, however, is not that. It generally only sees 5 requests or so per minute, so it was weird to see the wiki causing trouble. After some initial stop-gap measure, I had a closer look at the node, and noticed that the CPU load was on a significantly elevated, but stable, level. This, again, was unusual - because I designed the system in a way that allows it to handle quite large traffic spikes, and it shouldn't be under significant load on regular days.

Luckily, I have way more than enough metrics to investigate here. Looking at the traffic chart for the wiki only, it became very obvious that there was some sort of... deviation from the norm:



Again, traffic to the wiki is usually best measured in requests per minute - not requests per second. One could argue that diaspora* somehow just got very popular, but I have quite a bit of experience running services, and this chart didn't look natural to me.

The slow on-ramp of traffic over five days, and the occasional double traffic bursts, all of that looks like it's a bot (or a bot-farm) trying to see how far they can go before running into rate limits or load limits. So that's... odd - especially on the wiki.

Now, I have a few signals I can use to correlate requests with each other. In this case, I used the source IP and the User-Agent string provided. And it became quite obvious what was happening: A couple of crawlers, with the Amazon Web Crawler https://developer.amazon.com/support/amazonbot leading the list, followed by some .. shady and undocumented web crawlers, had a lot of fun crawling the entire diaspora* wiki in an endless loop - including images in various thumbnail sizes, all previous versions of all pages, etcetc. Not nice. But also easy to workaround.

I noticed a couple of other interesting things, though. A lot of people run their own webservice monitoring applications, and for some reason, people find it fun to add other people's web properties to the list. I guess that's fine if it's only one or two cases, but if a lot of servers request a page once a minute, .. well you're eventually getting to quite an accumulation of traffic. Anyway, that's annoying, but not on a level where it's causing pain. But some of you really really should update your application versions.

Another, and much much more intersting pattern I saw, was that... apparently, some diaspora* pods .. wanted to federate stuff to the wiki?!



All of those traffic sources are actual diaspora* pods. On rank 1, there's @Fla's diaspora-fr.org, and on rank 2, there's my very own Geraspora. So that was... odd. There's a couple of very odd things in here from the point of view of a diaspora* developer. In theory, diaspora* should not try to federate to... a wiki. Also, all those requests were GET requests, not POST requests like you'd imagine. In fact, the only case where diaspora* should send a GET request is when it's trying to fetch a public entity from another pod. Every single one of those request was a GET /Choosing_a_pod, and while I think that's a pretty important page on our wiki, ... y'know, it's not a diaspora* entity.

So what's going on here? After @Benjamin Neff and I spent a bit of time banging our head against a wall, we eventually found out what happened there.

A recently closed down pod, probably in order to help their existing users, set up a redirect to the wiki's Choosing a pod https://wiki.diasporafoundation.org/Choosing_a_pod page. But they didn't only do that for specific URLs, they just send all requests with a 301 status code to that wiki page. And well, that includes the HTTP routes used for federation. So every time those diaspora* pods wanted to send something to the closed down pod, they ended up requesting that wiki page. Fun times. But wait, didn't I say those requests were all GET requests? Well yes, they were! Even though diaspora* itself started out with a POST, that got lost somewhere.

I'm a webbrowser nerd, so I knew what was happening here, but I appreciate that that's not universally the case. So, to explain, what we're seeing here is a bit of an HTTP edge-case. The relevant specification says https://www.rfc-editor.org/rfc/rfc2616#section-10.3.2 (and yes, I know that that's an older version - but if you check the new versions, you will know why I quote RFC 2616 and not RFC 9110)

If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously change it into a GET request.