It's very hard to say anything definitive, because many of those can generate different load depending on how much traffic/activity it gets (and how it correlates with other service usage at the same time). Could be from minimal load (all services for personal use, so single user, low traffic) to very busy system (family and friends instance, high traffic) and hardware requirement estimates would change accordingly.

As you already have a machine - just put them all there and monitor resource utilization. If it fits - it fits, if it doesn't - you'll need to replace (if you're CPU-bound, I believe CPUs are not upgradeable on those?) or upgrade (if you're RAM-bound) your NUC. You won't have to reinstall them twice anyway.

The fundamental issue is not that emoji XSS (that's just a vector), but how JWTs are implemented and [not] secured. I've read that it was reported at least this January (https://akkoma.nrd.li/notice/AXXhAVF7N5ZH1V972W).

So, developers were already aware, yet - as I'm checking 0.18.1 - they have not fixed the unsafe-inline and unsafe-eval CSP, haven't made jwt cookie HttpOnly, and haven't done anything about exp and jti in the JWTs. I hope the recent events will make them do to so, and not just patch this particular XSS.

So you can comment, vote and save without jumping extra hoops (because you can only do this from your home instance)

Some apps have hardcoded assumptions about the paths, making those kind of setup harder to achieve (you’ll have to patch the apps or do on-the-fly rewrites).

Then there’s also potential cookie sharing/collision issue. If apps don’t set cookies for specific paths, they may both use same-named cookie and this may cause weird behavior.

And if one of the apps is compromised (e.g. has an XSS issue) it’s a bit less secure with paths than with subdomains.

But don’t let me completely dissuade you - paths are totally valid approach, especially if you group multiple clisely related things together (e.g. Grafana and Prometheus) under the same domain name.

However, if you feel that setting up a new domain name is a lot of effort, I would recommend you investing some time in automating this.

I don't think XMPP comparison is correct.

First, in my personal (subjective!) opinion, XMPP died because of entirely different primary reason: it, by design, had trouble working on mobile devices. Keeping the connection was either battery-expensive or outright impossible, and using OS native push notifications had significant barriers.

As for Google Talk - it just came and went. Because they never had proper MUCs (multi user conferences, think communities), in my own (again, personal, thus subjective - not objective!) experience it was quite the opposite to how the article paints it. Whoever participated in chatrooms I've been in, and had used a Google account, hated Google's decision and moved to XMPP. I'm no fond of Google, but their impact on XMPP was not strictly negative - they contributed some useful XEPs and useful free software libraries after all. Although, of course, for those who used XMPP primarily as a classic messenger system (like MSN, AIM or ICQ) for private 1:1 chats things surely looked differently.

Now, why I think the comparison is not correct. I think Threads' situation is different because of fundamental differences in how those systems operate. And not in favor of Threads/Meta. If Threads would be Lemmy or XMPP MUC-like system (that is, having communities/groups hosted on particular servers), then it would be a complicated story, where Fediverse could even theoretically score a net win. But as I get it, Threads is Mastodon/Twitter-like thing, and their users' content will stay with Meta, entirely at Meta's discretion whenever they let other systems access it, and when they pull the plug. Given that Meta is also not likely to contribute to FLOSS Fediverse projects, their Fediverse presence is of questionable benefits to say the least.