sunaurus

joined 2 years ago
[–] sunaurus@lemm.ee 8 points 6 hours ago (1 children)

Hey, there isn’t any default community right now. There are a few different databases that track graphs of such things, for example, fedidb.org.

[–] sunaurus@lemm.ee 16 points 6 hours ago

Thank you very much for the support!

Our infrastructure costs are currently quite stable at around 200€ per month, and considering that the instance is right now quite decently supporting nearly 6000 monthly active users, you could say that you are indeed relatively contributing a ton - you are effectively covering server costs for 60 people!

The fact that it’s a monthly amount is particularly great, because with recurring income, we will get advanced warning if there is danger of funds starting to run low.

[–] sunaurus@lemm.ee 25 points 13 hours ago* (last edited 13 hours ago)

We had a few really huge days in 2023, but other than those, it seems like the growth so far in March is definitely outpacing our initial wave of new users in 2023.

635
submitted 14 hours ago* (last edited 13 hours ago) by sunaurus@lemm.ee to c/meta@lemm.ee
 

Hi folks!

Over the past few months, we have started seeing a significant amount of new user sign-ups. I would like to take this opportunity to welcome all of our new members, and to share some useful resources and info about lemm.ee.

First, some stats

Here is a bar chart of daily new users (this is only counting users which have been approved by our admins):

collapsed inline media

As you can see from the chart, for most of 2024, we were accepting roughly around 10-20 new users every day. Then, from the start of this year, the daily numbers have been constantly growing. Yesterday, we approved a massive 609 new users on lemm.ee.

The increase in sign-ups is significant enough that I have been taking several steps to improve our monitoring & anti-bot measures, but so far, it seems the vast majority of the new users are completely legitimate real humans! (Thank you all for not being bots 😅)

About lemm.ee

This Lemmy instance is turning 2 years old very soon. It was initially created around the time of the Reddit API changes, when existing Lemmy servers were getting overloaded with new users - lemm.ee was intended to help spread the load. We're now the second largest Lemmy server when it comes to monthly active users.

Our core philosophy for this instance has always been to treat it as a generic gateway to the Lemmy network. I want to provide our users a stable and reliable home for their Lemmy account, so that they can have easy access to all of their communities, regardless of what instance the community is actually hosted on.

We run on some decently beefy hardware, and our setup is fairly customized in several ways in order to ensure a smooth experience for our users (most of the time, this has worked out quite well!). Our servers are currently hosted in Finland.

Our infrastructure has been funded by the community almost from the start through GitHub sponsorships and Ko-Fi donations. I am sure I speak on behalf all of our users when I say that I am extremely grateful to all supporters - you are really responsible for the continued existence of this instance!

Lemmy itself is open source software, and while it has improved massively during the time I have been using it, it definitely still has some rough edges. Please be patient when using Lemmy, and remember that it is being built collaboratively by humans (not corporations), without any intent of ever turning it into a business.

Useful resources

Don't forget to participate!

Communities on Lemmy only work if people actively use them. Even upvoting/downvoting based on quality of content is a great start, but I would really like to encourage you all to comment and even write posts, because that's really the best way to build communities.

If you have any questions or thoughts about lemm.ee or Lemmy in general, feel free to post a comment below this post, and myself or one of our veteran users will definitely respond.

I hope you enjoy your time on lemm.ee, and I wish you all a great week!

 

Hey folks

Just a quick heads up, we will be performing some database maintenance today. Expected downtime is ~15 minutes.

Sorry for the inconvenience!


Update: maintenance complete!

[–] sunaurus@lemm.ee 1 points 1 week ago

The e-mail successfully went out from our side - please check your spam filters etc

[–] sunaurus@lemm.ee 1 points 1 week ago (4 children)

That's just Lemmy behavior for when you click the e-mail verification link multiple times. It basically means "e-mail already verified".

[–] sunaurus@lemm.ee 1 points 2 weeks ago

Our servers are currently in Finland, but this is subject to change if necessary for financial/technical reasons. We've also used German servers in the past for example. In general we're definitely staying in the EU, though.

1
submitted 2 months ago* (last edited 2 months ago) by sunaurus@lemm.ee to c/meta@lemm.ee
 

Hey Folks

Just a quick note to let you all know about some changes in the lemm.ee admin team. After discussing things with the other admins, we've decided to shuffle around our roles a bit.

Up until now, I’ve been the head admin at lemm.ee - handling infrastructure, maintaining rules and policies, and acting as the main contact person for the admin team.

However, I’ve come to realize that this role has taken a toll on me. While I still love the idea of Lemmy and everything it stands for, being an admin has slowly drained the joy I once had for the platform. The occasional negative experiences have been increasingly difficult for me to shake off. For the past several months, I’ve found myself hesitating to check my DMs or the moderation queue, simply because I’m bracing for some new drama that I no longer have the energy to manage.

After some conversations with the team, we’ve agreed on a plan to ensure my burnout doesn’t negatively impact the instance:
  1. I am stepping down as head admin of lemm.ee.
  2. The new main contact person for the admin team will be @EllaSpiggins@lemm.ee.
  3. I’ll continue to maintain and update the infrastructure behind the scenes.
  4. The rest of the admin team will now handle all moderation issues, managing our policies, and any general admin communications.

It’s been an honor to serve as your head admin, and I’m incredibly grateful for the amazing people I’ve met here. I’m excited to stay involved in a capacity that works better for me and allows me to enjoy this community once again.

See you around!

4
submitted 8 months ago* (last edited 8 months ago) by sunaurus@lemm.ee to c/meta@lemm.ee
 

Hey folks!

For anybody stumbling on this post from outside lemm.ee: I am the head admin of lemm.ee, a general purpose Lemmy instance, which recently turned 1 year old. I am writing this post to elaborate on how we approach defederation on lemm.ee.

Anybody who has been on Lemmy for a while has most likely seen several public defederation drama posts (most recently regarding lemmy.ml, but there have been many many others previously). As an admin, I have probably seen far more than what is visible publicly, as I regularly receive private messages on the topic, ranging from polite questions about federation, to outright demands that I immediately defederate, and even to threats and personal attacks over the fact that I have not defederated some particular instance. It is definitely a topic that will keep coming up for as long as Lemmy exists, which is why I feel it would be useful to condense my current thoughts about it in a single place.

Note that while I strongly believe everything this post contains, it is definitely a subjective topic, and there is no single right answer here. Other instances have completely different approaches to federation compared to lemm.ee, and that’s of course totally fine. The beauty of Lemmy is that everybody can choose their home instance, and in fact, everybody is free to spin up their own instance and run it however they feel is best. For an absurd example, if you want to create an instance which defederates any instance with an “L” in their name, then nobody can stop you!

Quick intro to the lemm.ee federation policy

Very shortly after creating lemm.ee, I wrote down a federation policy, which basically boils down to “we treat defederation as an absolute last resort, and we do not use it as a generic way to curate content for lemm.ee users”. This policy can always be found in the sidebar of the lemm.ee front page.

In practice, this has meant that we have had extremely few defederations, and that we mostly solve problems with other means. I am very happy with the results, as it means that lemm.ee has become a great entry point into the Lemmy network, with very few artifical limitations on who our users are allowed to interact with.

The benefits of federation

I hope that this part of the post is very uncontroversial, but I firmly believe that federation is the absolute strongest feature of Lemmy. While we all know that the concept of federation can cause confusion for new users, this is usually overcome extremely quickly (for example, using the common e-mail providers analogy to explain Lemmy instances). To me, it’s completely clear that the benefits of federation far outweigh the downsides.

For example, by splitting the Lemmy network between thousands of independent nodes, we ensure that:

  1. Any single entity is not a single point of failure for the whole network. Even if the biggest instance goes down tomorrow, their content will still be accessible through all the other federated instances.
  2. The maximum impact of admins is limited to their own instance. As a lemm.ee admin, I can ban a remote user from posting on lemm.ee, but I can’t completely ban them from the entire network.
  3. Private user data (such as ip addresses, e-mails, etc) are never shared between instances. No single malicious instance can harvest user data for the entire network, and extremely privacy sensitive users can always spin up their own instance if they don’t want to put their trust in any existing admins.

One thing which is probably important to note here is that I tend to view Lemmy instances as infrastructure, rather than as communities. I know that there are alternative approaches, as quite a few large instances are in fact run as mega-communities, but that’s not the approach I take with lemm.ee, because I feel like such an approach encourages centralization and negates some of the benefits of federation (if all communities related to one topic condense on a single instance, then that instance does effectively become a single point of failure for a large number of users).

In general, I feel like it should be a goal to encourage and cultivate decentralizing the network through federation as much as is practical, in order to maximize the above benefits.

The downsides of dedeferation

Conversely, defederation has a lot of downsides.

  1. It obviously negates all the benefits of federation mentioned above. Every time two instances defederate, the Lemmy network becomes less redundant, some communities become a bit more centralized, and the danger of malicious admins for those communities becomes much greater.
  2. There is a lot of collateral damage. The most common reason I have personally seen for defederation demands is related to moderation of either a single user, or a handful of users. For example, a lemm.ee user gets into some heated arguments with people from an instance with hundreds of active users, and then links this heated thread to me as proof that the instance should be immediately defederated. However, in this situation, there are hundreds of other users who were not even involved (or even aware of) the thread in question. By defederating, I would be making a decision to cut off every single lemm.ee user from every single one of those hundreds of innocent remote users.
  3. Ironically, defederation actually makes moderation more difficult. It was recently pointed out to me by a user on another instance that they are afraid they can’t effectively moderate communities on lemm.ee, because their instance has defederated several other instances, which means they would not be able to see posts from those instances on lemm.ee communities.
  4. It is extremely easy for malicious actors to abuse. In the year I’ve been on Lemmy, I have already seen two separate cases of users creating accounts on another instance and posting garbage, and then going back to their home instance and demanding their admins defederate over the content they themselves created. Basically, if an instance is known to use defederation as a tool to punish misbehaving users on other instances, then it’s actually quite easy for users to manipulate the situation to a place where admins have no alternative except to defederate.

It seems to me that a lot of users don’t think of such downsides when demanding defederation, or they just don’t consider them as important enough. In my opinion, these are all significant issues. I do not want to end up in a fragmented Lemmy network, where users are required to have accounts on 5 different instances in order to be able to access all their communities.

What’s the alternative to defederation? Should Lemmy become some kind of unmoderated free speech abolutism platform?

I want to be very clear that I do NOT believe in unmoderated social networks. Communities should always be free to set and enforce rules which foster healthy discussions. On top of that, instances should always be free to set and enforce rules for all of their users and communities.

In the case of lemm.ee, we have some instance-wide rules, and we will enforce them on all lemm.ee users, as well as all remote users participating in communities hosted on lemm.ee. For example, we never want to offer a platform for bigotry, so we regularly issue permanent bans for users who want to abuse lemm.ee to spread such hate. In practice, site bans have been extremely effective at getting rid of awful users, whether they are remote or local.

On top of site bans, Lemmy admins also have the option of removing entire remote communities. There are certainly cases where a community might be allowed on instance A, but not instance B - rather than defederating (and potentially cutting off a lot of innocent unrelated users), instance A can just “defederate” a single community.

Finally, a lot of issues can be solved through simple communication between instance admins. Often having a discussion with another admin results in pretty clear alignment over whether some user is problematic, and the user will end up being banned on their home instance.

Being one of the most openly federated large instances with such an approach, we have discovered several things:

  1. If we were to defederate over every rule breaking user or community on the Lemmy network, we would not be federated with any of the large instances at this point
  2. In the vast majority of cases, remote users who have broken lemm.ee rules have ended up banned on their home instance anyway - there is very little additional moderation workload for our admins from being widely federated
  3. If a user truly wants to spread some kind of hate, defederation wouldn’t stop them anyway, as they will just create accounts on any instance which they want to “attack”

The longer I run lemm.ee, the more sure I become that in the vast majority of cases of abusive users, the best approach is to simply hand out site bans.

When is defederation the only option?

Having said all of the above, I still believe that there a few cases when defederation is the best option:

  1. When an instance is abusing the Lemmy network - generating spam, advertising, illegal content, etc - either deliberately, or through inactive admins (this has been the most common reason for lemm.ee to defederate any instance in the past)
  2. When an instance is just causing too much moderation workload. So far, we haven’t experienced this yet on lemm.ee, but I can’t rule out that it could happen in the future.

Conclusion

I hope this post helps clarify my stance on defederation. Like I said in the beginning, I realize a lot of this is subjective, and there are no right or wrong answers - this is just the way we have been (and will be) doing things on lemm.ee. I intend to save this post and link it in the future when people bring up defederation requests. If you feel like I didn’t address something important, please feel free to raise it in the comments!

[–] sunaurus@lemm.ee 1 points 9 months ago

Well, one advantage we have over commercial social media is that they need to pay people to write code and maintain the infrastructure, but a lot of work on Lemmy is volunteer-based.

Many admins for bigger instances are basically on-call the whole year for free, open source contributors provide code for free, etc. Even the core maintainers are effectively losing money by working on Lemmy, because while they are getting some income, the sum of money they are getting from working on Lemmy is way smaller than what they would get if they worked typical software engineering jobs.

Basically, if any non-volunteer organization wanted to replicate Lemmy, it would cost them quite a bit more in terms of payroll alone.

Another aspect is scale - Lemmy is able to spread the costs between different instances, and while growth of the network can generally increase costs for individual nodes, they will still end up paying less compared to if they were hosting the entire social network in a centralized way.

[–] sunaurus@lemm.ee 0 points 9 months ago (2 children)

We have about 3.3k monthly active users. This is based on users who at least vote/comment/post once a month, so it doesn't include lurkers. But yeah, in terms of just infrastructure costs, we're at about 6 cents per active user per month.

[–] sunaurus@lemm.ee 0 points 9 months ago (4 children)

We've been stable just around 200€ per month for most of this year (it fluctuates up and down a little bit depending on exact usage). I update https://status.lemm.ee/ once every month with expected running costs for that month, and while it hasn't changed much in the past months, if it does ever change, you'll find up to date info there!

 

Hey all!

Upcoming lemm.ee cakeday

Can you believe that lemm.ee is almost 1 year old? In just a couple of weeks (specifically, on the 9th of June), we will be able to celebrate our first instance cakeday.

I am thinking of compiling some stats about how lemm.ee has been used in its first year, if you have any specific stats in particular you would like to see, feel free to comment below. I will try to accommodate any ideas as I start gathering this info!

Infrastructure updates

A few weeks ago, I posted about plans to make some changes to our infrastructure in order to deal with different intermittent networking issues.. It took a bit longer than I hoped (just did not manage to get enough free time between then and now), but I am happy to report that this work has now been completed! Additionally, I have decommissioned our stand-alone pict-rs server.

With the two changes mentioned above, I believe lemm.ee should now be much more resilient going forwad, and I expect a significantly lower rate of infrastructure-related issues for the rest of the year!

I'll leave a tehcnical overview about the problem & solution below for those interested, but if these details don't interest you, then you can safely skip the rest of this post.


For context, lemm.ee has been hosted on Hetzner servers for most of this year (having migrated from DigitalOcean initially), with everything except our database being hosted on the Hetzner Cloud side, and the database itself living on a powerful dedicated Hetzner server. This mix allows a great amount of flexibility for redeploying and horizontally scaling our application servers, while still allowing a really cost-effective way of hosting a quite resource-hungry database.

In order to facilitate networking between the cloud servers and the dedicated database server (which live in different networks), Hetzner provides a service named "vSwitch". This service basically allows you to connect different servers together in a private network. Unfortunately, I discovered quite quickly that this service is very unreliable. During the short few months that we have been using the vSwitch, we have gone through one extended period of downtime (where the service was just completely broken for several hours), as well as dozens (if not hundreds at this point) intermittent disconnects, where servers randomly lose their connections over the vSwitch. After such a disconnect, the connection never recovers without manual intervetion.

For most lemm.ee users, the majority of these vSwitch issues have been mostly invisible, as we have redundancy in our servers - if one server loses its connection to the database, other servers will take over the load. Additionally, I have generally been able to respond quite quickly to issues by redeploying the broken servers (or deploying other temporary workarounds). However, in addition to a huge amount of these issues which lemm.ee users hopefully haven't ever noticed, there have also been a few short periods of downtime this year so far, as well as a few cases of federation delays. These more extreme cases were generally caused by multiple servers losing their vSwitch connections at the same time.

After several attempts to work around these issues, I decided that we need to migrate away from vSwitch.

As of earlier today, lemm.ee is no longer using Hetzner's vSwitch at all!

I finally found enough time earlier today to focus on this migration, and I was able to successfully complete it. None of our networking is relying on the vSwitch anymore.

In the end, I went with quite a simple solution - I configured a host-level firewall (nftables) on our database dedicated server, which will deny all connections by default. Whenever any cloud servers are added/removed, their corresponding public IP addresses are added/removed in the allowlist of our database firewall. It would have been ideal to do this whole logic in Hetzner's own firewall, but that one unfortunately has a limit of only 10 rules per server, which is just not enough for our setup.

Bonus: our pict-rs server has been decommissioned!

Pict-rs is the software which Lemmy uses for everything related to media (image storage mostly). Initially, pict-rs required a local filesystem to store both files as well as metadata about files. Since the beginning, lemm.ee has used a dedicated server just for pict-rs, in order to ensure we could easily redeploy the rest of our servers without losing any images.

Over the past year, pict-rs has gained the ability to store files in object storage, and metadata in a PostgreSQL database. This meant that the server running pict-rs itself no longer contained any of the important data, so it became possible to redeploy without losing any images. Additionally, this meant that it would be possible to run multiple pict-rs servers in parallel.

While we had already migrated our pict-rs server to use object storage and PostgreSQL several months ago, we still had the single dedicated pict-rs server up until today. I have been planning for a while to decommission this server, and start running pict-rs directly on each one of our Lemmy application servers. Earlier today, I was able to complete this plan. This should hopefully mean that our pict-rs server is less likely to get overloaded, and it also means a tiny reduction in our overall monthly infrastructure bill (due to one less server running).

With the above changes, I think our infrastructure has become more robust, and hopefully, we will experience less issues with images, federation, and general downtime going forward.


That's all from me for now. Feel free to leave any thoughts or questions in the comments, and as always, I hope you're having a great day!

[–] sunaurus@lemm.ee 1 points 2 years ago (1 children)

Hey, are you sure you're not misinterpreting the votes? There was a small minority of users in favor of federating, but the majority was against it.

-1
submitted 2 years ago* (last edited 2 years ago) by sunaurus@lemm.ee to c/meta@lemm.ee
 

Hey folks!

I made a short post last night explaining why image uploads had been disabled. This was in the middle of the night for me, so I did not have time to go into a lot of detail, but I'm writing a more detailed post now to clear up where we are now and where we plan to go.

What's the problem?

As shared by the lemmy.world team, over the past few days, some people have been spamming one of their communities with CSAM images. Lemmy has been attacked in various ways before, but this is clearly on a whole new level of depravity, as it's first and foremost an attack on actual victims of child abuse, in addition to being an attack on the users and admins on Lemmy.

What's the solution?

I am putting together a plan, both for the short term and for the longer term, to combat and prevent such content from ever reaching lemm.ee servers.

For the immediate future, I am taking the following steps:

1) Image uploads are completely disabled for all users

This is a drastic measure, and I am aware that it's the opposite of what many of our users have been hoping, but at the moment, we simply don't have the necessary tools to safely handle uploaded images.

2) All images which have federated in from other instances will be deleted from our servers, without any exception

At this point, we have millions of such images, and I am planning to just indiscriminately purge all of them. Posts from other instances will not be broken after the deletion, the deleted images will simply be loaded directly from other instances.

3) I will apply a small patch to the Lemmy backend running on lemm.ee to prevent images from other instances from being downloaded to our servers

Lemmy has always loaded some images directly from other servers, while saving other images locally to serve directly. I am eliminating the second option for the time being, forcing all images uploaded on external instances to always be loaded from those servers. This will somewhat increase the amount of servers which users will fetch images from when opening lemm.ee, which certainly has downsides, but I believe this is preferable to opening up our servers to potentially illegal content.

For the longer term, I have some further ideas:

4) Invite-based registrations

I believe that one of the best ways to effectively combat spam and malicious users is to implement an invite system on Lemmy. I have wanted to work on such a system ever since I first set up this instance, but real life and other things have been getting in the way, so I haven't had a chance. However, with the current situation, I believe this feature is more important then ever, and I'm very hopeful I will be able to make time to work on it very soon.

My idea would be to grant our users a few invites, which would replenish every month if used. An invite will be required to sign up on lemm.ee after that point. The system will keep track of the invite hierarchy, and in extreme cases (such as spambot sign-ups), inviters may be held responsible for rule breaking users they have invited.

While this will certainly create a barrier of entry to signing up on lemm.ee, we are already one of the biggest instances, and I think at this point, such a barrier will do more good than harm.

5) Account requirements for specific activities

This is something that many admins and mods have been discussing for a while now, and I believe it would be an important feature for lemm.ee as well. Essentially, I would like to limit certain activities to users which meet specific requirements (maybe account age, amount of comments, etc). These activities might include things like image uploads, community creation, perhaps even private messages.

This could in theory limit creation of new accounts just to break rules (or laws).

6) Automated ML based NSFW scanning for all uploaded images

I think it makes sense to apply automatic scanning on all images before we save them on our servers, and if it's flagged as NSFW, then we don't accept the upload. While machine learning is not 100% accurate and will produce false positives, I believe this is a trade-off that we simply need to accept at this point. Not only will this help against any potential CSAM, it will also help us better enforce our "no pornography" rule.

This would potentially also allow us to resume caching images from other instances, which will improve both performance and privacy on lemm.ee.


With all of the above in place, I believe we will be able to re-enable image uploads with a much higher degree of safety. Of course, most of these ideas come with some significant downsides, but please keep in mind that users posting CSAM present an existential threat to Lemmy (in addition to just being absolutely morally disgusting and actively harmful to the victims of the abuse). If the choice is between having a Lemmy instance with some restrictions, or not having a Lemmy instance at all, then I think the restrictions are the better option.

I also would appreciate your patience in this matter, as all of the long term plans require additional development, and while this is currently a high priority issue for all Lemmy admins, we are all still volunteers and do not have the freedom to dedicate huge amounts of hours to working on new features.


As always, your feedback and thoughts are appreciated, so please feel free to leave a comment if you disagree with any of the plans or if you have any suggestions on how to improve them.

 

Hey folks!

It's time for some lemm.ee updates! Feel free to skip ahead to whichever sections seem interesting to you.

New bot rules

The reception to my previous meta post was very positive, so we are going ahead with the new bot rules on lemm.ee. The new rules have been added to our front page sidebar and will be enforced by admins starting on the 1st of August.

The final version of the rules look like this:

  • All bot accounts must be explicitly marked as bots
  • Bots must not vote on any posts or comments
  • Bots must disclose their specified purpose in their profile
  • Bots must not be responsible for the majority of content in any community

The goal for now is to limit bots to a support role. In other words, we have nothing against bots which are used to support running a community for real people, but we do not currently want to host communities which are completely filled with bot content on lemm.ee.

It's definitely true that bot-only communities might provide valuable content, but we need to balance this value with how bots affect our feeds. If in the future the volume of organic user-created content on lemm.ee increases to a point where bots can't easily overwhelm the local feeds, then we may reconsider the last rule.

I apologize again to any bot developers who have chosen lemm.ee as the home for your bot-driven communities, I hope you can find another instance without too much trouble.

0.18.3 update

Last week, lemm.ee was updated to Lemmy version 0.18.3. We were previously already running a patched version of 0.18.2 which included many of the performance improvements that landed in .3, so the upgrade did not have as much of an effect on lemm.ee as it probably did on many other instances.

In any case, we are now again running on a completely unmodified version of Lemmy, and will continue to do so until there are performance or security reasons to run a custom patch again.

lemm.ee stance on hosting alternate Lemmy frontends

In the past few months, a lot of alternate web UIs for Lemmy have started cropping up. I've checked out a few of these and I think a few look really cool!

While such frontends generally provide ways to use them without being directly hosted on any specific instance, some instances have begun hosting such frontends on their own servers as well. I've also received a few dozen requests to host such frontends directly on lemm.ee. I would like to address these requests directly here.

For the time being, I am not planning to host any other frontends than the default lemmy-ui on lemm.ee. There are several reasons for this.

I am personally familiar with lemmy-ui code (to a reasonable extent). I know what it's doing overall, I know several of its pitfalls and I am able to quickly react in case of issues. As just one example, lemm.ee was the first instance in the world which fixed the weak script-src CSP in lemmy-ui that enabled the recent login session breach on some other instances - this is because I deployed the code on lemm.ee before I submitted a PR to the lemmy-ui repo with the fix.

The above would not be true for alternative frontends. I don't have the capacity to go through the implementation details of additional projects at the moment, so I have no idea what the code would be doing in any third party UI. I have no way to guarantee that it's not malicious to begin with. Even if the code is not malicious, I would not be able to quickly apply patches if problems crop up.

As a result of all this, I am not comfortable with hosting these third party frontends on lemm.ee for now. Note that this does not mean you're not able to use such frontends with lemm.ee - all the ones I've checked will work perfectly fine without being hosted on the same domain as the instance itself. But as with any 3rd party app, please be careful when using these frontends - by doing so, you are effectively sharing your username and password with anybody who is developing and hosting them.

Personal note

Some of you may have noticed that I have been a bit less active in the several Lemmy-related communication channels & GitHub for the past week or so. The reason for this is that I've had two stressful things happen: earlier this month, I found extensive water damage in my house which is not covered by insurance. Even worse, shortly after this discovery, I received news that my current place of work, a startup, is shutting down at the end of August (mostly due to changed market conditions).

As a result, I've been spending a fair bit of time trying to deal with the renovation of my house & now am also spending additional time trying to figure out where I can land in terms of employment in order to keep putting food on the table. Nevertheless, I am hoping to get back to more Lemmy contributions soon.

Sorry to use this space for selfish purposes, but I would like to take this chance to note that if anybody is looking for a remote software engineer, I am currently open to new opportunities! Just as a short overview about myself:

  • I've been working as a software engineer for over a decade, about 5 years in technical leadership roles
  • I have experience with end to end ownership of software platforms - everything from writing code to running it in production
  • I'm based in the EU but happy to work in either EU or US timezones
  • For the past few years, my main tech stack has been TypeScript (nodejs/react) + Postgres + Terraform, but I have extensive experience with a lot of other technologies and generally am quite adaptable
  • I have experience running platforms at considerably bigger scale than Lemmy

I would of course happily go into much more details if you contact me directly, so if this is interesting to anybody then please feel free to reach out!

Also, please let me assure anybody who is worried: lemm.ee funding is not currently in jeopardy. For the next couple of months, lemm.ee is not even dependant on a single cent of my own financial contributions, as community support has provided enough money already to give us a nice buffer. I am planning to write a summary of our financials in the next few weeks, please keep an eye on the meta community if you're interested in seeing this!

That's all for now, thanks to anybody who has made it this far! As always, please feel free to leave comments below if you have any thoughts or questions.

 

Context

There have been a lot of posts and comments recently about Facebook entering the fediverse, and how different instances will handle it. Many people have asked me to commit to pre-emptively defederating from Threads before they even implement ActivityPub.

The lemm.ee federation policy states that it's not a goal for lemm.ee to curate content for our users, but we will certainly defederate any server which aims to systematically break our rules. I want to point out here that Facebook makes essentially all of its money from advertising, and lemm.ee has a no advertising rule - basically, Facebook has a built-in financial incentive to break our rules. ActivityPub has no protections against advertising, so it's likely we will end up having to eventually defederate from Threads just for this reason alone.

However, I would still like to get a feel for how many people in our instance are actually excited for potential federation with Threads. While personally I feel that any theoretical pros are by far outweighed by cons, I do want to use this opportunity to see how much of the community disagrees with me. I am not intending to run this instance as a democracy (sorry if anybody is disappointed by that), but I would still like to have a clear picture of user feedback for potentially major decisions such as this one. This is why I am asking every user who wants lemm.ee to federate with Facebook to please downvote this post.


Here are some reasons why I personally believe that Threads will have a negative effect on the fediverse

  • As mentioned above, Facebook is completely driven by ad revenue. There is nothing stopping them from sending out ads as posts/comments with artificially inflated scores, which would ensure that their ads end up on the "all" page of federated servers.
  • Threads already has more users than all Lemmy instances combined. Even if their algorithms don't apply to the rest of the fediverse directly, they can still completely dictate what the "all" page will look like for all instances by simply controlling what their own users see and vote on.
  • Moderation does not seem to be a priority for Threads so far, meaning that they would create massive moderation workloads for smaller instances.
  • In general, Facebook has shown countless times that they don't have their users best interests in mind. They view users as something to exploit for revenue. There are probably ways they are already thinking about hurting the fediverse that we can't even imagine yet.

By the way, we're not really in any rush today with our decision regarding federation

  • Threads does not have ActivityPub support yet today
  • Even if they add ActivityPub support, their UX is geared towards Mastodon-like usage - it seems unlikely that there would ever be proper interoperability between Threads and Lemmy
  • We don't really know what to defederate from - it's completely possible that "threads.net" will not be their ActivityPub domain at all.

So go ahead and downvote if you feel defederation would be a mistake, and feel free to share your thoughts in the comments! It would be super helpful to me if folks who are in favor of federating with Threads could leave a comment explaining their reasoning.


Update:

By now, it's clear that there is a group of users who are in favor of federating with Threads. The breakdown is like this (based on downvotes):

  • lemm.ee users: 136 in favor of federating with Threads
  • Others: 288 in favor of federating with Threads

While it seems to be a minority, it's still quite a few users. There is no way to please all users in this situation - any decision I make will certainly inconvenience some of you, and I apologize for that.

A big thanks to everybody who has shared opinions and arguments in comments so far. I think there are several well written comments that have been unfairly downvoted, but I have personally read all comments and tried to respond to several as well. I will keep reading them as they come in.

The main facts I am working with right now are as follows:

  • The majority of lemm.ee users are strongly opposed to immediately federating with Threads
  • Facebook has a proven track record of exploiting users (and a built-in financial incentive to do so)
  • We currently lack proper federation/moderation tools to allow us to properly handle rule breaking content from Facebook

Considering all of the above, I believe the initial approach for lemm.ee should be to defederate Threads, and then monitor the situation for a period of time to determine if federating with them in the future is a realistic option

In order to federate with them, the following conditions would need to be fulfilled:

  • There needs to be actual interoperability between Threads and Lemmy
  • Threads needs to prove that they are not flooding instances with rule-breaking content (mainly ads and bigotry for lemm.ee)
  • There needs to be a mechanism to prevent feed manipulation by Threads algorithms (potentially this means discarding all incoming votes from Threads)

Note: this is an initial list, subject to change as we learn more about Threads.

Again, I realize this approach won't please everybody, but I really believe it's the best approach on a whole for now. Please feel free to keep adding comments and keep the discussion going if you think there is something I have not considered.

 

👋 to all the newcomers, let me know if you need any help getting settled in!