Jajaja, sí, soy Mexicano 😁

🥳 Muchas gracias!

That’s awesome! Thanks for sharing

Woah. That is a lot sooner than I had anticipated.

It works great for me! I’ve bookmarked it, thanks!

Yeah, I still see the line now. I am not sure if this was a one-off, maybe the edit occurred when I rebooted the instance for a moment and the edit fell through the cracks… Or there might be an actual issue federating edits.

I think you left this line behind by accident:

l = Lemmy(INSTANCE_URL)

I have just tested by uploading/re-downloading an image, and the EXIF data is removed.

I then looked through the Lemmy issues and found this issue related to the image-uploading back-end (pict-rs) removing the EXIF data. In response to this issue, the developer of pict-res (asonix) comments that striping the EXIF data was one of the original motivations for building the uploader.

I am not sure about how to search through the source code of pict-rs, and it seems like this step is not properly documented in the readme file, so I have not been able to find exactly where the metadata removal operation takes place. I think that this is done by invoking ‘exiftool’.

EDIT: Sorry, I misunderstood this question ~~ I have a raspberry pi connected to a 1 TB SSD. This has the following cron job:

00 8 * * * /usr/bin/bash /home/user/backup/backup.sh

And the command in backup.sh is:

rsync --bwlimit=3200 -avHe ssh user@instance-ip:/var/www/mander/volumes /home/user/backup/$(date | awk '{print $3"-" $2 "-"$6}')

In my case, my home network has a download speed of 1 Gbps, and the server has an upload speed of 50 Mbps, so I use -bwlimit=3200 to limit the download to 25.6 Mbps, and prevent over-loading my server’s bandwidth.

So every morning at 8 am the command is run and a full backup copy is created.

It seems that you have a different problem than me. In your case, rather than doing a full copy like me, you can do incremental backups. The incremental backup is done by using rsync to synchronize the same folder - so, instead of the variable folder name $(date | awk ‘{print $3"-" $2 “-”$6}’), you can simply call that instance_backup. You can copy the folder locally after syncronizing if you would like to keep a record of backups over a period of a few days.

On a second thought, I would also benefit from doing incremental backups and making the copies locally after synchronizing… ~~

You can create a one-person instance and hold your identity there.

If you what you want is for every server to hold your identity, you have to trust all servers. I think that an evil admin would be able to impersonate any user from any instance if that were the case. How do you delete your account? Can an any admin delete your account everywhere? Which one is the real “you”?

Thank you! I will look into cloudfare, what people say about it, and what resources are necessary to avoid DDoS attacks without it!

Better delivery and avoids exposing your IP via emails, although it’s best to setup a some sort of tunnel to avoid having that problem altogether.

Is it possible to have a public-facing instance without exposing your IP? I am not sure I understand that part, and I am very interested in understanding how to achieve that.

consider using an email delivery service like jetmail instead of sending mail directly from the instance

Why is this better? To overcome spam filters, or is there some security risk associated with e-mails?

A few years ago the plain text passwords would show up in the logs. That has been changed since then, but a malicious instance admin can easily revert this change and keep a log of plaintext passwords.

A developer explained to me that adding client-side hashing would be problematic because different clients might do the hashing in different ways, and that the desired solution is to add OAuth at some point. There is also a bit more discussion about this in that thread: https://lemmy.ml/comment/97830

I lack the technical knowledge in client-side hashing to explain why this is the case, but as far as I can tell client-side hashing is not common at all. The standard is to hash the passwords server-side.

I do think that it is important to be aware of what a malicious instance admin can potentially do: they can log your plain-text password, see your e-mail and correlate it to your IP, look at what posts you like/dislike, and read your non-encrypted private messages. But these are not “Lemmy” problems, as these are general issues when it comes to trusting the servers of the sites that you create an account in.

An important benefit of Lemmy is that you can actually set up your own server or use the server of someone who you really trust, and you can use it to interact with the rest of the instances. It is also possible to create an account without providing an e-mail, a phone number is not required, and you can usually access instances via a VPN or Tor. These are not a common luxuries when it comes to other sites.

Using unsafe passwords is dangerous in a lemmy instance, but it is dangerous anywhere.