That sounds like an interesting idea, I’ll test that out, thanks!

I thought about this solution, as it is the “cleanest”, however I need on total 4 firefox derivatives. Unfortunately, when looking deeply into the options, i haven’t found 4 that are similarly trustworthy, well maintained etc. Also i have my firefox config fully figured out, it works and is as private as i want them, without some maintainer forcing their opinion on my use cases. Plain firefox is the easiest to configure, as it’s like a blank start. However i might be wrong here and am open to suggestions :D

Unfortunately that is not what I am looking for. I am already using named profiles. Like i stated in my original post as well as my answers below, this only works from Inside Firefox, however from the operating system pov it is still treated as the same application. Which means:

a) When i share the work profile, i also share all other profiles, as they are all Firefox b) When I quick access firefox via spotlight, i end up at the nearest, random profile / instance of firefox. c) There is no way to differentiate the profiles on an application level. d) I can not assign the instances to different desktops, as they are all Firefox.

I don’t know how the code is currently working, but I like this feature idea and would suggest to start very simple and proceed from there.

For example you could: a) Make a list of communities that are siblings with their id and instance b) add a toggle to view sister community posts yes /no c) query all communities, list the last x posts from each with time constraints, e.g. not older than 1 day or hour depending on the community post frequency d) list them sorted by time of x , depending on what was chosen

The biggest issue I see with this simple approach, besides others, is that different communities are different in terms of activity / post frequency. So ideally the better, but more effort, way would be to let each community instance communicate their posts themselves via a query with activity metric parameters. Basically the amount of returned posts would depend on common parameters set by the most active instance.

It’s not yet thought out, but just getting an mvp started and test the waters would probably be better than having it perfect right away while working on it for months

The issue was much more straightforward than i thought. It seems sometimes thinking of too complex issues will hinder finding the easiest cause - the local forewall on the pi was blocking it / had no explcite allow.

To check i did: sudo ufw status verbose

There was only port 22

I added the new port as Allow Port 8081: sudo ufw allow 8081

And it works now! Thanks for all the tipps that pointed me in the right direction!

Thanks for the hints, this definitely helped, however it did not solve the issue.

What i did:

1. I changed via omv-firstaid the omv port from 80 to 8081.
2. I confirmed with ss -ltn that this change was successful and i see the listening port 80 vanished, while this now popped up:

State Recv-Q Send-Q Local Address:Port Peer Address:Port

LISTEN 0 511 0.0.0.0:8081 0.0.0.0:*

3. I tested locally via ssh from the pi the connection via curl http://mylocalip:8081/ and it works, i get the html back
4. I tested from my laptop (connected to my router via WiFi, where the raspberry is meshed into via the repeater in between) and i still get the timeout.
5. I tried tunneling again via ssh ssh -L 8081:localhost:8081 pi@raspberrypi.local and i did not get any errors this time. However when i open the local url in the browser i get a connection reset and my terminal shows me channel 3: open failed: administratively prohibited: open failed. However this just says that TcPForwarding is disabled, which is fine, so that tunneling issue should not be the main problem, i assume.