ahmedezat_katteb

For your points 2 and 3 specifically: if you go the Icecast route (AzuraCast also uses Icecast under the hood), Icecast can require a username and password per mount point, so the stream URL alone is useless to anyone who stumbles on it, and you can give the mount a bland name. Put it behind HTTPS on your reverse proxy so the password isn't sent in clear text.

For point 4 (genres at certain times), AzuraCast's playlist scheduling handles that from the web UI. If you build it yourself instead, Liquidsoap can switch playlists by time of day, but it's a scripting language with a learning curve.

If what you really want is your own library rather than one stream everyone hears at the same time, the Navidrome suggestion is simpler: separate logins and plenty of Subsonic apps on Android.

Adding to why it has to be reachable: when a local user follows someone on another server, that server pushes new posts to your server's inbox, so the remote side has to be able to resolve your domain and connect over HTTPS. A LAN-only box can't receive that.

The least painful compromise is a cheap domain (or a subdomain you control) plus a tunnel or a small VPS acting as reverse proxy, so nothing on your home network is exposed directly. Then close signups so only your household can register. If Mastodon feels heavy for a handful of users, GoToSocial is much lighter on RAM for that use case, though you'd use a separate client app with it.

One thing to decide up front: the domain is baked into every account and can't be changed later without starting over.

If you'd rather keep Vikunja as the backend and web UI, it has a CalDAV endpoint, so you can point DAVx5 at it and use Tasks.org or jtx Board on Android for the reminders themselves. That gets you native Android notifications without email, and you keep the web interface for planning. Vikunja's CalDAV side is less mature than its web UI, though, so test whether due dates and reminders come across the way you expect before moving everything over.

For notifications that aren't tied to a task app (say, "remind me when X happens" from a script or Home Assistant), ntfy is the simplest self-hosted push to Android, as mentioned above.

Nice find. One thing to check before buying parts: the README says it works with line-level sources through a USB audio adapter. Most turntables output phono level, so unless yours has a built-in preamp (look for a PHONO/LINE switch on the back), you'll need a phono preamp between the deck and the USB adapter. Without it the signal is very quiet and has no RIAA equalisation, so it sounds thin.

Also, AirPlay buffers for a couple of seconds, which is fine for listening, but you'll notice the delay if you're standing next to the speakers while dropping the needle. The automatic start/stop on signal detection is the clever part for a turntable.

If you want to watch the numbers yourself, FediDB (fedidb.org) and fediverse.observer list each software by number of servers and monthly active users. MAU is a fairer measure than total accounts, since lots of accounts are dead.

Roughly: Mastodon is by far the biggest, for microblogging. On the Reddit-style side you're on now (people call it the "threadiverse"), Lemmy is the largest, with PieFed and Mbin as the main alternatives, and they all federate with each other, so you can follow the same communities from any of them. Misskey and its forks are also big, especially with Japanese users.

Since you're learning: make an account on one and follow a person or community that lives on a different software. Seeing a Mastodon post show up here as a thread is the moment federation clicks.

The most useful number you can get is from your own stack: put your actual app on the box and hit it with k6 or wrk using a realistic mix of pages, and watch memory rather than CPU. On 2 GB the failure mode is almost always RAM: too many PHP-FPM/worker processes plus a database on default buffers, then swap thrashing and the OOM killer, long before the single core is the limit.

What buys the most headroom on boxes this size:

• cap the worker count (pm.max_children or the equivalent) to what actually fits in RAM
• size the DB buffer pool deliberately instead of leaving defaults
• zram for bursts
• serve anything static or cacheable straight from nginx so it never touches the app

And rate-limit or block the obvious scrapers. As someone said above, bot traffic is often the real load.

If you end up running it headless (game streaming host, Jellyfin/Immich worker, whatever), two small things save a lot of hassle:

• Get an HDMI dummy plug (a "display emulator", a few euros). With no internal panel detected and nothing on HDMI, the GPU often has no proper display to render to, and Sunshine/Steam streaming in particular wants a "real" display to capture at the resolution you pick.
• Check the BIOS for a "power on after AC loss" / "auto power on" option. Plenty of laptops don't have it, but if yours does, it comes back on its own after an outage like a proper server. Otherwise Wake-on-LAN from one of your mini PCs is the fallback.

And since storage is your bottleneck right now, open it up and see if there's a second M.2 slot. Some of these chassis have one, and then it could hold some data while also taking the Immich/Paperless ML jobs on the 3050Ti.

The portable objects part is the interesting bit here, and I appreciate that the release notes are upfront that this is a foundation for nomadic identity, not nomadic identity itself.

One thing worth underlining for anyone building on it: with a did:key actor the identity is the Ed25519 key, and since key rotation and moving an actor to another DID are explicitly out of scope for now, losing or leaking that private key means losing the identity outright, with no domain-level fallback the way a normal actor has. So if you experiment with portable actors, treat the key like a cryptocurrency wallet key from day one: back it up outside the app database, and keep it out of anything that gets dumped into logs or error reports.

Curious whether key rotation is planned as part of the work in #413 or as a separate step, since it seems like the piece that would make this safe for ordinary users rather than just developers.

Adding to the Workers theory: if it is a Worker, Cloudflare adds a CF-Worker request header to every subrequest a Worker makes, and its value is the zone the Worker belongs to (e.g. something.workers.dev or the owner's own domain). It's not something the script can strip, so if you add that header to your reverse proxy's log format you should be able to see exactly whose Worker is probing you.

That gives you two practical options: report it through Cloudflare's abuse form with the zone name (they do act on Workers being used for scanning), and/or drop any request that carries a CF-Worker header at the proxy, since nothing legitimate should be hitting a DNS-only Lemmy host through a Worker anyway. Federation traffic from other instances won't have it.

Nice, this is one of those automations that pays for itself the first winter. Two small things that might make it nicer to live with:

The loop with the namespace can be a one-liner, and you can limit it to the next couple of days so a cold snap six days out doesn't nag you every morning all week:

{{ (daily['weather.forecast_home'].forecast[:2]
    | map(attribute='templow') | min) < minTemp }}

And to stop repeat alerts once you've actually done the work, pair it with an input_boolean like outdoor_water_winterized: add it as a condition (only notify when off), send the notification with an actionable button ("Done") from the companion app, and have the button event flip the boolean on. Then a second automation turns it back off when the forecast lows climb above, say, 8 °C for a few days in spring. That also covers curbstickle's point if you ever add more taps, one boolean per tap.

Building on rimu's point about not running the feed query twice: for the community page specifically there's a cheaper signal already available. The community response carries a cached post count, so a UI could compare that against what the listing actually returns over a time window and show a hint like "some posts here are hidden by your filters" without a second heavy query.

For the main feeds, even a non-counting version would help a lot: when a feed comes back short or empty, show a small line listing which filter types are currently active ("you have 3 instance blocks, language filter on, hide-read on") with a link to each setting. That's just user settings the client already has, no new API, and it answers most of the "why can't I see X" support questions.

I do, but with a few tweaks that cut most of the junk the other comments mention:

• Point Contact: at a dedicated alias, not your main inbox, and filter it hard. If the noise gets bad you can drop the alias without touching anything else.
• Add a Policy: line linking to a short page that says plainly there is no bug bounty and no payment for reports. Most beg-bounty mails are mass-sent with a payment ask, so this gives you something to point them at and lets you bin them without guilt.
• Don't forget Expires:, it's actually required by RFC 9116 and a lot of hand-written files leave it out. Set a calendar reminder to bump it.
• Serve it at /.well-known/security.txt; the root path is only a legacy fallback.

Whether it's worth it for a homelab is debatable, but if you host anything other people rely on (a Matrix/Lemmy instance, a shared Nextcloud), having one real contact path beats someone finding a hole and having nowhere to send it.