Admin on the slrpnk.net Lemmy instance.
He/Him or what ever you feel like.
XMPP: povoq@slrpnk.net
Avatar is an image of a baby octopus.
They have been talking about how creators want to own their platform and I could imagine that they don’t mind allowing a few such people to migrate off Threads to facilitate that. In the end what matters to them is that the large audience stays on their platform where they can serve them personalized advertisements.
Well then, your assertion that Matrix gives it freely is false.
My point is that it should never give out that data, or even store it permanently in the first place. This is just a fundamentally bad design from a privacy perspective, and other messengers don’t do that.
This is false, too. Historical event visibility is controlled by a room setting. (And if you don’t trust admins of a sensitive room to configure for privacy, then you’re going to have bigger problems, no matter what platform it’s on.)
This is not false, what you mean only hides it for normal users, but it still ends up in the database of all participating homeservers and all the admins of those have full access to it. I happen to run a Matrix homeserver myself…
Obviously you need someone joining the room for the room metadata to be shared between homeservers. But that is really only a minor barrier and once that has happened the worst case scenario takes place immediately. On other messengers (federated or not) a newly joining member has very limited access to past room metadata. Not so with Matrix, where a joining homeserver get full retroactive access to all the room metadata since the room’s creation. If you can’t see the problem with that, you really need to stop privacy LARPing 🙄
lol, why are you even posting on a privacy community then? And using Tor doesn’t help at all in that case.
Yes it is a problem for both public and private rooms as this info is stored and shared retroactively. Lets say one of the participants of a private room gets compromised or you invite someone that has their account on a compromised homeserver. This then results in the entire room meta-data history (since the room was created) being shared with that compromised homeserver which can then easily analyse it in detail.
No, because Matrix stores all this info and gives it freely to other servers retroactively(!). Also with network layer sniffing (which is anyway much harder to do) you can only see which home-server talked to with other homeserver and what clients talked to their homeserver. If you have the full room meta-data you can easily make a social graph of which account talked to whom when and where.
There is a lot more metadata than just avatars and reactions. Accounts and their room membership over time, timing of messages (and thus online times), individual interactions between specific users (based on the timing of their messages) and so on. That is all in the unencrypted metadata of a Matrix room and can’t be moved to the encrypted message part like avatars and reactions.
Like all of it. It is not a “leak” if it is working as intended.
Anyone can spin up a Matrix server, join a room with it and the Matrix network will happily push a complete copy of the room metadata (all the way back to the point the room was first created) to that new homeserver.
You seem to be unaware of how Matrix works. It is inherent to the protocol that room metadata is shared with other servers. It is not fixable as it is working as intended. This feature is nice for censorship resistance, but it is pretty much a nightmare for metadata privacy.
Because there is a lot more metadata than just IP addresses.
I think the term often used is “NAT reflection”.
Power-line tends to be quite slow and error prone. If you have existing coax, that is likely the better option. You can get up to 2.5gbit adapters for it: https://til.simonwillison.net/networking/ethernet-over-coaxial-cable
Yes, I could easily configure our Podman containers to auto-update, but given how there have been significant breaking bugs in Lemmy releases before, I think it’s better to not automate it.
Systemd is very useful for managing (rootless) Podman containers.
They are not included. You need to divide the 3.600€ by two main developers and then add up the irregular NLnet payments to that. So as a result it comes to approximately 3000€ for each of the two devs per month (6000€/month total). At least that is my understanding from what is written above.
Here it isn’t so heavy on CPU, but the database eats RAM like crazy. My guess would be that their server is constantly swapping out stuff from RAM due to insufficient surplus RAM and this as a result creates the high CPU load.
Hmm, I think there are more people that are #1 and #2 the same time (not me though) and the bigger divide is between those that rent a VPS and those that run a homelab.
You can compile it from source.
Usually* there is a database for the file meta-data that will benefit from faster access times of a SSD, the files themselves can be on a HDD.
*not sure how Immich specifically does it.
There are actually local names for that geographic area that pre-date those introduced by the colonizers.