Kalcifer

More often than not, the best way to hide is to simply blend in with the crowds -- this also encompasses one's choice for a username. It is relatively simple to make a single throwaway account -- just come up with a username, and off you go -- however, if one makes throwaway accounts often, the task of thinking of a unique, and non-identifiable username can become a challenge. I would argue that poeple would often resort to using a pattern employing small changes for all subsequent usernames. Such patterns can be identified to a specific user if all users have their own unique patterns.

How can one reliably generate many unique-but-normal, and non-pattern-identifiable usernames?

On the side bar it lists the following:

• [Matrix/Element]Dead
• Discord

"Discord" is an active link, but the Matrix link is completely inactive. Not only is it inactive (which could have be excused as a broken link), but it is also manually labeled as "Dead", as if there is no intention of making it work. How can a community that is focused on privacy willingly favor a service that is privacy non-respecting when a perfectly functional privacy-respecting alternative exists?

I believe that the addition of an edit history would be a massive boon to the usefulness of Lemmy on the whole. A common problem with forums is the relatively low level of trust that users can have in another's content. When one has the ability to edit their posts, and comments this invites the possibility of misleading the reader -- for example, one can create a comment, then, after gaining likes, and comments, reword the comment to either destroy the usefulness of the thread on the whole, or mislead a future reader. The addition of an edit history would solve this issue.

Lemmy already tracks that a post was edited (I point your attention to the little pencil icon that you see in a posts header in the browser version of the lemmy-ui). What I am describing is the expansion of this feature. The format that I have envisioned is something very similar to what Element does. For example:

What this image is depicting is a visual of what parts of the post were changed at the time that it was edited, and a complete history of every edit made to the post -- sort of like a "git diff".

I would love to hear the feedback of all Lemmings on this idea for a feature -- concerns, suggestions, praise, criticisms, or anything else!

This post is the result of the current (2023-10-03T07:37Z) status of this GitHub post. It was closed by a maintainer/dev of the Lemmy repo. I personally don't think that the issue got enough attention, or input, so I am posting it here in an attempt to open it up to a potentially wider audience.

As I noted within my post, #[email protected] (alternate link), URL thumbnail generation in Element is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:

In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.

Post Edit History

2023-10-02T00:54Z
1c1,2
< As I noted within my post #[email protected] ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server.
***
> As I noted within my post #[email protected] ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
> > In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.

2023-10-02T01:28Z
1,2c1,2
< As I noted within my post #[email protected] ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
< > In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room. 
***
>  As I noted within my post, #[email protected] ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
> > In encrypted rooms, like this one, URL previews are disabled by default to ensure that your homeserver (where the previews are generated) cannot gather information about links you see in this room.

2023-10-02T03:44Z
1c1
< As I noted within my post, #[email protected] ([alternate link](https://lemm.ee/post/9955859)), thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:
***
> As I noted within my post, #[email protected] ([alternate link](https://lemm.ee/post/9955859)), URL thumbnail generation in [Element](https://element.io/) is an enormous privacy, and security vulnerability. Thumbnails are generated server-side, regardless of E2EE settings. What this means is that the URLs that one sends would be leaked out of your encrypted chats to the server. Here is a notable excerpt from the settings within Element:

Post Signature

ul7mHTfs8xA/WWwNTVQ9HzKfj/b+xw+q9csWf60OJrT58jMJpmsX8/BicwFodR8W
Llo93EMtboSUEtYZ+wQhaL/HmrEr6arup7gJzZgslOBWPFj5azADHSpjX9RYuvpt
Fk2muTUgJP2e+SW3BGDPmlcluw6mQOYcap84Fdc1eU47LOZprBXob97qInMK5LrL
tzNqARRtXGdogZtQYlNCqCd9eQgqTwPfxKVadmM6G3xQMh6mWQxQz56sCXqj+mlG
OqJyZIgB1UXEuVZeAO3pl9wN+cSM4eqHLHQwEd+aVeSPf75r2d7mZs+VNwr1WfMu
0sWcPh3aZLXKqdls6UJMEA==

Lemmy is licensed under the AGPLv3. I don't want to rely solely on my own legal interpretation of the license, so I'm wondering if anyone has any explicit knowledge on the matter.

As an aside, am I correct in assuming that, if someone does make changes to the source code, they must host, and link to it?

EDIT (2023-09-27T22:22Z): I am just now seeing that at the bottom of a Lemmy instance's site, there is a link that says "Code". It appears that this is handled automatically.

Workaround

A workaround that I decided to go with was to simply extend my backup of the nextcloud snap to simply include the entirety of /var/snap/nextcloud instead of just taking the data directory, and the dump of the database. If I restore /var/snap/nextcloud, everything is immediately restored to its previous working order. This seems to accomplish what I want.

I still have no idea what was causing the previous issue, though. I'm thinking that it might be that some important files, or directories are being left out in the previous backup that nextcloud is expecting to be present, but I'm really not sure.

Original Post

I have been scratching my head for hours over this -- I'm really not sure what the problem could be. I have nextcloud installed as a Snap on Ubuntu Server.

Here's how I went about restoring the backup (fresh install of nextcloud):

1. Copy over the data: # rsync -Aax data-backup data-directory
2. Drop the existing database: # nextcloud.mysql-client -e "DROP DATABASE nextcloud"
3. Create a new database: # nextcloud.mysql-client -e "CREATE DATABASE nextcloud"
4. Restore the dumped database: # nextcloud.mysql-client nextcloud < database-dump

When I log in to nextcloud in the browser, it initially appears that it worked fine: calendar data, task data, contacts, etc. are all properly loaded, and the images viewer is displaying images; however, when you look at the files tab, there's nothing there, and, when you try to create a folder, it spits out an error saying "Unable to create folder". If I run nextcloud.occ files:scan --all it can see all the files in the data directory just fine, it's just not able to display them in the files taband I cannot figure out why. I would really appreciate any help, ideas, or suggestions.