troy

I've always seen these self hosted S3 API compatible services as something a developer would use for testing.

Could maybe simplify the solution with https://syncthing.net/ or https://restic.net/ for self hosted backups.

Paperless will store documents in plain text. Maybe one could write a small webserver or extend Paperless to serve an RSS feed that could be consumed by Yacy.

For a couple reasons

1. Store and version configs in git. I realize unRAID provides flash drive backup (using git also), but this allows me to spin up my setup on another machine that may not be running unRAID. Helped recently when I switched away from Proxmox.

2. Allows me to group services with their dependencies. ( e.g. postgres, redis, etc ) Also can help isolate service groups from each other. Avoiding port conflicts on common db ports for example. Downside being may have more than one database, redis, etc.

Note, there is an unRAID docker compose plugin so you can still get easy access management buttons to start, stop, view logs, and edit services.

I have a very similar setup minus the iot and metric related services. I'm managing the services with Docker Compose on unRAID.

Good point, if supporting JS disabled browsing is a goal, SSR is a must.

re languages If doing SSR, language matters. If doing CSR, statically generating site, it matters less. For example, there are more hosting options for PHP than Rust. There are even more hosting options for static assets (eg CDN).

The power of Social Media is the community. Coupling the UI with Rust seems like it would prevent the larger community from contributing. I'm interested in both web and Rust, but have zero interest learning a Rust JSX variant.

Why not static site? Could have a themes folder where admins could drop their static themes. Also, would allow admins to host markup and Lemmy API on different hosts.

Your data/content is public on Lemmy, FB would have no problem fetching it.

Your edit is correct. SSO not required.

Probably want to keep services with different life cycles in separate docker compose files to allow you to shutdown/restart/reconfigure then separately. If containers depend on each other, then combining into compose file makes sense.

That said, experimenting is part of the fun, nothing wrong with testing it out and seeing if you like it.

My ranking attempt

"3: Only allow topics that arent limited to one language, library, etc. (general topic community)" "5: Only allow crossposts into the community with things like news being posted in the specific community first (crosspost community)" "4: Dont allow questions of how to do X in X language but allow actual discussions or news about the language in addition to general topics (general & discussion community)" "2: Allow any posts and direct people in the comments to more specific communities for their future posts (people catching community)" "1: Allow all posts relevant to the instance (main community)"

Basically desiring that posts be in their respective communities with the main community acting as a catch-all for posts that don't fit into any existing community or announcements like community launches.

I know ranked voting is a good system, but the options are a bit confusing to me as they don't seem mutually exclusive. Perhaps it is correct, but I have never seen a ranked vote like this. For example, I believe you could allow cross posting in addition to allowing topics that are not limited to one language.

Currently the benefit is not sending your credentials and other requests through wefwef.app and avoiding throttling. If you value privacy self hosting is a good idea. If you trust wefwef, then the only other reason is to customize/develop wefwef.

After CORS fix in Lemmy is done and wefwef updates your requests should go directly to Lemmy servers so privacy concerns are mitigated.

Future Lemmy release will enable CORS headers which will allow web clients to connect directly to Lemmy server. This should make it easier for clients to reach server through Cloudflare filters.