I don't have much of an opinion on this topic, I haven't really looked into it.

But as soon as I saw this image, the El Al Flight 1862 which crashed in the Bijlmer in Amsterdam in 1992 immediately came to mind. The shape of the hole is very similar!

This image shows the likely position of the Bijlmer plane during the crash:

The image you posted of the Pentagon seems to me consistent with what I have seen of the Bijlmer accident, and so the shape of the hole and the absence of wings in the photo does not persuade me personally that no plane was involved.

The votes themselves are the federated action.

If you fetch an old post, your instance will not see the previous voters. After that, whenever a user votes the instance will get the message "User X@instance upvoted/downvoted post Y" and the vote will be added to the database with the voter's user ID and counted.

This has a practical function. If you don't keep a list specifying who voted for what, it would be much easier to fake votes from one instance to another by simply communicating the message "Downvote post Y". With the current method it is still possible to create a lot of fake accounts and mass-vote, but at least you can get a better insight when looking at the database if the votes are associated with accounts with no activity from a single instance.

There are some federated platforms that will show who likes / dislikes something. I know that friendica used to do this - I have not checked if it still does. So it is not only admins who can see this, this is is basically open information in the fediverse.

Ah, sorry. I did not notice that this was a community about an app.

But maybe if you change it via the browser the app will also respect your settings. I'm not sure though, I have not used "Voyager".

In your settings, you should see "Type: Subscribed | Local | All"

Nooo, I just recently discovered NewPipe 😔

Woah. That is a lot sooner than I had anticipated.

I think you left this line behind by accident:

l = Lemmy(INSTANCE_URL)

This is what I think, but if anyone understands it differently please correct me.

Vertical scalability refers to scaling within a single instance. More users join and they post more content, increasing the amount of disk space needed to hold that memory, network bandwidth to handle many users downloading comments and images at once, and processing power.

Horizontal scaling refers to the lemmyverse growing because of the addition of new instances. The problem in this form of scaling is due to the resources that an instance has to use due to its interactions with other instances. So, you may create a small instance without a lot of users, but the instance might still need a lot of resources if it attempts to retrieve a lot of information (posts, comments, user information, etc) from the other larger instances. For example, at some point a community in lemmy.ml might be so popular that subscribing to that community from a small instance would be too much of a burden on the smaller instance because of the amount of memory required to save the constant stream of new posts. The horizontal scaling is a problem when the lemmyverse becomes so large that a machine with only a small amount of resources is no longer able to be part of the lemmyverse because its memory gets filled up in a few hours or days.

I think this underestimates how users will naturally gravitate towards more centralized instances, or they’ll give up because the bigger instances are closed.

(This is purely my personal opinion, of course!) In the scenario in which a few large instances dominate, the idea of the fediverse failed. One may estimate the likelyhood of success or failure given how they expect humans to behave, but in the end experiment beats theory. I think that for the fediverse to work a significant cultural shift has to occur, but I don't think that it is an impossible shift. I would like the fediverse to succeed, and so I choose to take part in the experiment.

This also ignores that the system isn’t horizontally scalable at all, so scaling up gets even more expensive

Yes, that might cause some serious issues. The project is still in an early-development phase, and I don't understand the technical aspects well enough yet to be able to identify whether there is obviously a fundamentally invincible barrier when it comes to scalability. My optimistic hope is that the developers are able to optimize horizontal scalability fast enough to meet the demand for scale. If it turns out to be impossible to scale, then only rich enough parties would be able to have viable instances, and that could be a reason for failure.

A small cloud server + a domain name costs less than a Netflix subscription. The developers have taken care to package lemmy in ways that are relatively straight forward to deploy, so a dedicated person with a small amount of experience can have an instance up and running in an evening. As long as a few percentage of users are willing to pay a netflix subscription to keep a server running, the financial burden would be spread.

I looked through the git, it was removed here: https://github.com/searx/searx/pull/2566

It appears that Yandex would respond to requests with a captcha and they were unable to fix it, so they removed it.