Nginx VS Mastodon

Yeah, unless I'm looking at it wrong, there doesn't seem to be any meaningful difference between 1.25.5 and 1.26.0:

https://github.com/nginx/nginx/compare/release-1.25.5...rele...

However, it's very unlikely that .NET developers will directly expose their Kestrel-based web apps to the internet. Typically, we use other popular web servers like Nginx, Traefik, and Caddy to act as a reverse-proxy in front of Kestrel for various reasons:

> I actually don't understand why I am seeing arguments like this all the time.

Have a look at:

https://github.com/nginx/nginx/blob/master/src/http/modules/...

It's got the whole checklist: nginx idiosyncratic module system, inline parsing, custom utf conversion, buffer preallocation and adjustments, linked lists, comments about side effects of custom allocator, and probably other things.

It's not easy to deal with source like that and any serious improvement to that area would effectively be a rewrite anyway.

Since anything doing work in nginx is a module anyway, it wouldn't even have to be a full rewrite in one go.

According to this article, nGinx is being used to serve 34% of all websites in the world. I checked out who's contributing to nGinx, and just like I thought, the project has 8,208 commits, and 5,366 of those commits was made by 2 software developers; igorsoev and mdounin.

Nginx + Roadrunner (fcgi mode)

Apache’s mod_fastcgi’s last commit was 2 weeks ago:

https://svn.apache.org/viewvc/httpd/httpd/trunk/

It’s a fork of what you linked (and was more popular afaik back when fastcgi was state of the art, and apache was the undisputed champion of web servers).

These days, nginx has more market share than apache, and its fastcgi module is one of the more recently updated ones in its source tree (5 months vs multiple years):

https://github.com/nginx/nginx/tree/master/src/http/modules

If I was going to build an embedded web server, I’d start with nostd rust, probably with though axum + tokio, since thats already memory safe-ish.

If I needed fastcgi for some reason (dynamically loadable endpoints, or os-level isolation), there are at least four implementations of fastcgi for it. No idea if any are decent though.

APISIX is an API Gateway. It builds upon OpenResty, a Lua layer built on top of the famous nginx reverse-proxy. APISIX adds abstractions to the mix, e.g., Route, Service, Upstream, and offers a plugin-based architecture.

Oh, TIL about https://mastodon.social/ (https://joinmastodon.org/)

Looks like what you describe, doesn't it?

> Social networking that's not for sale.

Interestingly there is some discussion for Mastodon with people asking the limit to be smaller, which raises the question as to the purpose of alt text, and how to properly handle larger text lengths in screen reader programs.

https://github.com/mastodon/mastodon/issues/12268

Through the Fast Forward program, we give free services and support to open source projects and the nonprofits that support them. We support many of the world’s top programming languages (like Python, Rust, Ruby, and the wonderful Scratch), foundational technologies (cURL, the Linux kernel, Kubernetes, OpenStreetMap), and projects that make the internet better and more fun for everyone (Inkscape, Mastodon, Electronic Frontier Foundation, Terms of Service; Didn’t Read).

Mastodon DMs have absolutely no privacy: https://github.com/mastodon/mastodon/issues/18079

For a decentralized protocol doing things right is much more important than doing things fast, it is very difficult (and in a lot of cases impossible) to break backwards compatibility.

Postmortem on what happened here: https://news.ycombinator.com/edit?id=39305884

The v1 API of Mastodon limits the size of the tree that it will expand for users who are not logged into the server: https://github.com/mastodon/mastodon/blob/main/app/controllers/api/v1/statuses_controller.rb . I am guessing that this or some similar limit applies to threads being returned to unauthenticated users of the web UI. It just arbitrarily stops expanding the replies at some point, including the main thread from the OP.

If a thread is truncated, users expect it to expand automatically and autoscroll when you hit the bottom. In my desktop browser, that does not occur, and there is no indication that there is more to see. This is the situation of the web interface as of Mastodon version 4.2.5.

The issue is very sensitive to observer conditions. If you are logged into the server, the behavior is different. If you use a Mastodon app instead of the web, the behavior might be different. As the tree expands, the cutoffs become different. If you look at the thread on a different Mastodon server, the tree is different because every server has its own view of the Fediverse.

HN needs a best practice for linking to Mastodon threads in a way that provides a consistent experience to HN readers. The average Mastodon server would be crushed by hundreds of HN readers grabbing the entirety of a huge thread all at once, so this might involve some thread-unroll-and-cache service. I tried https://mastoreader.io/ but it did not solve the problem.

Alternately, we push changes into the Mastodon web UI to warn users when they need to click to see more and assume that people will get used to the navigation.

Suggestions?

Fixed in Mastodon v4.2.5 https://github.com/mastodon/mastodon/releases/tag/v4.2.5

>You can defeat the Affero clause by putting the software behind a proxy, for example

Could someone elaborate on this? This is NOT my understanding of the license, and it seems absurd considering e.g. Mastodon is AGPL but the standard install requires a reverse proxy[1]. If using a proxy defeats Affero, why would the Mastodon team do this? Are they stupid?

[1] https://github.com/mastodon/mastodon/blob/main/dist/nginx.co...

Mastodon is free and open-source. Go ahead and add the flag:

https://github.com/mastodon/mastodon/blob/main/CONTRIBUTING....