In our Digital Notepad, there are already some contributions to federated systems.
We recently published an ad hoc contribution on the fediverse entitled “The «fediverse»: here is the federated universe in the Internet network..”
In addition, we have already described Matrix in the article titled “Matrix: the protocol for secure communication that respects privacy”, XMPP in the one titled “XMPP: the secure communication protocol that respects privacy”, and Mastodon in the article titled “The «fediverse». Mastodon: open-source social network”.
Today we present Lemmy.
What is Lemmy?
We find the answer on the official page, where we read:
Lemmy is a selfhosted social link aggregation and discussion platform. It is completely free and open, and not controlled by any company. This means that there is no advertising, tracking, or secret algorithms. Content is organized into communities, so it is easy to subscribe to topics that you are interested in, and ignore others. Voting is used to bring the most interesting items to the top.
Lemmy was written by @firstname.lastname@example.org and @email@example.com with the Rust programming language, using the web framework for Rust ACTIX and of course the ActivityPub protocol.
The project is available on GitHub - LemmyNet and consists of the following components:
- “lemmy” - Building a federated link aggregator in rust;
- “lemmy-ui” - The official web app for lemmy.;
- “lemmy-ansible” - A docker deploy for ansible;
- “lemmy-docs” - documents;
- “lemmy-translations” - A store for lemmy’s translations in i18n json format..
You can register by choosing an instance (a server) that already exists or create it on your server in self-hosting mode.
«Privacy Community»: our Lemmy instance.
We decided to install Lemmy on our server (self-hosted mode) by creating the instance called NicFab Community, which can be reached at this URL https://community.nicfab.it.
You can find the installation instructions in the official Lemmy documentation.
We proceeded with the installation using Ansible, as suggested.
The installation using Ansible consists of two steps:
- configuration of the system locally, i.e., on a PC or Mac from which we run the command to install the components on the server;
- the application accesses the server via SSH (as configured) and proceeds to install the components automatically.
Undoubtedly, installation via Ansible is very convenient.
At the end of the installation, the application creates the main default community (precisely called “main”).
We have decided to give the name “Meta” to the main community (which is devoid of content at the moment because we consider it to be system-wide).
We have, therefore, created the “Privacy Community” which is a common space for projects and users interested in privacy, data protection, cybersecurity, and the most innovative solutions.
“Privacy Community” is a global information channel where we post links to resources on the web about community topics (and thus privacy, data protection, cybersecurity, and more innovative solutions). You can pick up the RSS feed to keep updated on content as soon as it is published.
Anyone can register and then write posts, comment, and interact with other existing communities.
Getting Started: registering for the community.
Once you reach the https://community.nicfab.it page in the upper right-hand corner, the user who wishes to register will need to click on “Sign Up”, as we highlight in the image below
Then the user should fill in the fields as shown in the following image
The user, therefore, will need to indicate:
- a username;
- an email address;
- a password, to be confirmed in the next box; and then
- some very brief information, so the platform will check that they are not bots (to avoid indiscriminate requests).
Lastly, the user must choose whether or not to check the box labeled “Show NSFW content.” The acronym NSFW stands for “not safe for work,” meaning inappropriate content. Therefore, the user will have to choose whether to check the box to enable their profile to display inappropriate content, eventually posted.
Once the user has filled in the fields and clicked on the Sign-Up button at the bottom left, the platform will send the same user an email with a link that the user must click to confirm their intention to register.
After clicking on the link in the email, the administrator of Lemmy’s instance will either approve the request or reject it.
How to interact: write posts and comments.
Once registered, the user can create posts and/or comments to existing posts and must do so with the code of conduct we have indicated in the box to the right in mind.
Each user is responsible for any activity they perform on the platform, including posts or comments on posts they decide to publish.
In conclusion, Lemmy is a good resource.
Kudos to the developers.
Our privacy considerations.
After a brief analysis regarding the Lemmy project and the possible impact on users’ personal data, we have concluded that no conflict arises with the existing legislation for the European Economic Area (EEA) regarding the protection of personal data. Our analysis focused on the legislation on the protection of individuals with regard to the processing of personal data in force in Europe (EU Regulation 2016/679 - GDPR) and, in particular, in Italy (Legislative Decree 196/2003, as amended by Legislative Decree 101/2018 - Privacy Code).
Our evaluations considered every process, from account creation to user activities on the platform.
We proceed step by step.
Information to be provided according to Article 13 of the GDPR.
At the outset, it should be clear that the administrator of a Lemmy instance is obliged, in their capacity as data controller, to provide information to the data subject according to Article 13 of the GDPR.
However, we think it is helpful to conduct a comprehensive analysis so that we have a clear picture.
The data controller is the server administrator (of Lemmy’s instance).
What data is collected.
Regarding this point, we must distinguish two steps.
(a) Registration in the community: username, password, and email;
(b) Access to the community and user activities: IP address, username, password, and email.
Registration in the community
We can schematize the account creation process in three steps.
First step - When users create their account, they must choose a nickname and provide an email address. That is the only data voluntarily provided by the user. The nickname chosen by the user should not be the user’s first and last name but a shortened name, nickname, or pseudonym. In this case, it will not be possible to associate the username with the identity of the user, who would be unidentified or even identifiable. It could happen, however, that the user, at the time of registration, uses a username that is already widely known on the network, so much to make it identifiable. The same reasoning also applies to the email address if the user uses one so-called “non-speaking” that does not allow the identification of that person. In any case, the username and email address, individually or jointly, constitute personal data. Once the registration process is completed, the system sends an email to the user who requested registration, inviting them to confirm the request by clicking on a link.
Second Step - Having carried out the procedures described in the previous point, the user stays waiting for validation of the registration request by the instance administrator (i.e., the server).
Third step - The system, via the platform’s web interface, notifies the Lemmy instance administrator that a registration request has been made and presents only the username and not the email address. The administrator can approve or not approve the registration request. If the administrator approves the user’s request, the user’s data (username and email) are recorded in the database on the server.
The user data (username, password, and email) are recorded in the database, and specifically, the passwords are “hashed” (i.e., transformed into alphanumeric strings using the hash function).
Access to the community and user activities
Having completed the account creation process, the user can log in (Login) to the community through the browser, and then the IP address is acquired.
Each user is responsible for the content they intend to post on the Lemmy community.
In that phase, the personal data of users collected are the username, password, email address, and IP address.
Who can access the data and for what activities.
The server administrator (instance) can read data of the activities performed on the community recorded on the server and precisely in the database or log files (username, email, IP address, community web address, type of activity - technically GET or POST).
The administrator only accesses users’ personal data for strictly technical reasons (system analysis, updating application packages, maintenance needs).
We should point out that access to users’ personal data, whether in the database or logs, is a specific activity that is not generally performed except to resolve particular conflicts or errors.
The purposes of the processing.
The purposes are those related to server maintenance and system and application upgrades.
The only cookies present are functional ones and, therefore, no profiling or tracking activities.
Data transfer to countries outside the EEA.
The data controller, the administrator of Lemmy’s instance, does not transfer data outside the European Economic Area (EEA) if Lemmy is installed on the server located within the European Economic Area.
We feel it is appropriate to clarify this further.
Users registered on an instance are always solely responsible for their activities by creating communities or publishing posts or comments.
There is no transfer outside the SEE when registered users on an instance within the same EEA perform activities on the same server (instance). For example, our instance (https://community.nicfab.it) is located in Italy and thus within the EEA. If users registered on our instance perform activities on our server, there is no data transfer outside the EEA. Similarly, there is no data transfer outside the EEA even if registered users on our instance subscribe, publish posts, or comments on other instances - for example - located outside the EEA. Indeed, in the latter case, our instance administrator can access the logs and see only the domain (and thus not even the full URL of the community on which activities are performed) and its IP address. No further user data is transferred outside the EEA by the administrator or automatically by the Lemmy platform. The user should be aware that their username in the form “@username@domainofcommunity” (e.g., in our case, @firstname.lastname@example.org) will be visible in the community in which they have intervened (e.g., to publish posts or comments).
There will be no transfer of data outside the EEA even if the user intends to create a community on the existing Lemmy instance within the same EEA.
All of this is because it is a proper function of the fediverse’s system and the ActivityPub protocol used by Lemmy.
Adoption of technical and organizational measures.
However, it remains the obligation of each administrator to take appropriate security measures for their server (instance).
If this resource was helpful, you could contribute by
Or donate via
Follow us on Mastodon