2nding @nutomic, that I’m really happy with the stack.

The one that seems really magical to me, is diesel. With it we get a compile-time-checked database, that’s tightly integrated to the rust objects / code.

Every single join, select, insert, etc is checked before lemmy is even run, and it eliminates a whole category of errors resulting from mismaps.

Its made adding columns, and changing our data structures so much less error-prone than when I lived in the java-world.

Whenever we find that we’d want to do things differently, we usually do a refactor ASAP so as not to keep rolling spaghetti code. We’ve had to do this many times for the federation and DB code, and even have 2 major refactors that also add features ongoing. But luckily we’ve been able to stay in the rust eco-system for that.

As for UI, leptos didn’t exist when I built lemmy-ui, so I went with a fast react-like alternative, inferno. Its showing its age now, so @sleepless1917 is working on lemmy-ui-leptos, which hopefully will supercede lemmy-ui.

The stack is overall amazing, but not perfect. Waiting for the Rust code to compile is sometimes very annoying, but I wouldn’t want to use a different language. And we had to implement somewhat complicated things that existing Rust libraries did not do. For example, I made the “i_love_jesus” library so Lemmy could have cursor pagination that uses indexes well and allows bringing back the “back” button, we have a few custom QueryFragment impls because of diesel’s limitations, and we have a custom migration runner to do fancy stuff (see crates/db_schema/src/schema_setup.rs).

The stack is great, I wouldnt want to change anything. Postgres is very mature and performant, with a high focus on correctness. It can sometimes be difficult to optimize queries, but there are wizards like @dullbananas@lemmy.ca who know how to do that. Anyway there is no better alternative that I know of. Rust is also great, just like Postgres it is very performant and has a focus on correctness. Unlike most programming languages it is almost impossible to get any runtime crashes, which is very valuable for a webservice.

The high performance means that less hardware is required to host a given number of users, compared to something like NodeJS or PHP. For example when kbin.social was popular, I remember it had to run on multiple beefy servers. Meanwhile lemmy.ml is still running on a single dedicated server, with much more active users. Or Mastodon having to handle incoming federation activities in background tasks which makes the code more complicated, while Lemmy can process them directly in the HTTP handler.

Nevertheless, scaling for more users always has its surprises. I remember very early in development, Lemmy wasnt able to handle more than a dozen requests per second. Turns out we only used a single database connection instead of a connection pool, so each db query was running after that last one was finished, which of course is very slow. It seems obvious in retrospect, but you never notice this problem until there are a dozen or so users active at the same time.

With the Reddit migration two years ago a lot of performance problems came up, as active users on Lemmy suddenly grew around 70 times. You can see some of that in the 0.18.x release announcements. One part of the solution was to add missing database indexes. Another was to remove websocket support, which was keeping a connection open for each user. That works fine with 100 users, but completely breaks down with 1000 or more.

After all there is nothing I would do different really. It would have been good to know about these scaling problems earlier, but thats impossible. In fact for my project Ibis (federated wiki) Im using the exact same architecture as Lemmy.

Youre right, I also noticed some other problems while testing registrations:

• https://github.com/LemmyNet/lemmy/issues/5547
• https://github.com/LemmyNet/lemmy/issues/5548#issue-2949361836

For the email validation it could also make sense to send out another email saying “your email has been validated”, so its not only shown on the website.

This generally goes against security best practices as it can be used for attempted user enumeration. A better version would be “we’ll send you an email with your account status if this user exists” but obviously that results in a fair amount more complexity (and cost) to implement

I’d need more detail here. If registration emails aren’t being sent out correctly, we need to handle that.

You can hide them (three dots menu - hide post) is muting different?

https://github.com/LemmyNet/lemmy/issues/1883

Yes I’m very excited about the growth of other fediverse software, and a lot of the cool new features they’re adding. Its a great eco-system where we can experiment, be creative, and learn from each other.

the apps! the app support is really great for Lemmy

Yes this is a major benefit of an open network. Lemmy is a very large project already, so it takes a lot of effort to implement new features, because they have to meet high standards for quality and performance and also work together with all the existing features. A project like Piefed is much smaller and can implement new features more quickly. This allows for more experimentation, and successful features can later be added to Lemmy.

Also users who are not happy with Lemmy for any reason can switch to a different platform while still interacting with those on Lemmy. So if Piefed and Mbin grow that is also a benefit for Lemmy.

I would reply directly to that post, but it looks like the admin (who is also the Tesseract dev) has completely blocked federation with lemmy.ml by IP block or useragent block. So Im going to respond here to his complaints:

Lemmy didnt have a single breaking change since version 0.19 which was released 1 year and 4 months ago. And the breaking changes in that version were quite minor. Before that was 0.18, 1 year and 6 months earlier. That version only removed websockets, so most third-party app devs who used the HTTP API didnt notice any difference. Meaning the API has been almost unchanged for over three years which is quite long for a project that hasnt reached a stable version yet. 1.0 includes all the breaking changes that were held back over the years, so that we dont need any more breaking changes for a long time.

That said it would be great if we could keep backwards compatibility with the existing API in Lemmy 1.0. Problem is with all the major changes we are doing now, it would take a huge amount of work to implement this kind of backwards compatibility. If we had twice as many fulltime developers working on Lemmy this would be doable, but our resources are very limited so we have to make some compromises.

Divas have problems no matter what you do.

Having a tantrum because breaking changes were announced is asinine. The Tesseract developer comes across like a proper twat.

This is all a matter of dev resources. If we had maybe 6 full-time devs, we could handle things like backwards compatibility.

People forget that lemmy, like other open source hobby projects, don’t have the resources that large corporations do. People understandably get frustrated when there’s breaking changes, but they also need to not put enterprise-level expectations on a small number of people.

If someone wanted to work on that, of course we wouldn’t be opposed, but you should know how monumental a task that would be.

No seriously he’s retired and cooks his brain watching fox news all day. If he got off that drug for even a month he’d return to being a sweet and caring person.

Kindergarten cop right?

I can answer the first point.
We’ve already tackled part of that problem with the Parallel Sending feature that can be enabled on instances with a tremendous amount of traffic. Currently the only instance that makes sense to enable that is LemmyWorld and the only reason is so servers in geographical far away can get more than 3-4 activities/second.

With that feature, servers that eventually house and generate the biggest amounts of traffic will be able to successfully communicate all of those activities to everyone else who needs them.

I predict a 10x increase is well in our grasp of easily accessible by all of our current systems. 1000x? That’s a different story which I don’t have the answers too.

1. There is no specific maximum capacity, in theory it can scale indefinitely with horizontal scaling.
2. 0.19.10 already includes a fix to remove private messages when a user gets banned which should help a lot. There is an issue about disabling private messages by default, but Im not sure if that will be necessary. Also 1.0 will include a plugin system, so other devs and instance admins can write their own checks. That way spam waves can be fought in a more flexible way, without having to get a change merged into Lemmy and then waiting for a new release.

I can confirm the sections around downvotes as Reddthat has the stance exact what you are talking about (re your child comments)

A downvote disabled instance creates it’s own algorithm/feed/ranking based purely on all other metrics, because as far as the data is concerned, it sees every post having 0 downvotes. It does not take into account external instances.

They did managed hosting before but everyone freaked out that the communist devs were controlling the narrative or some shit. It was a mess, I think they stopped doing it now that there are more instances.

Down votes should remain. It expresses dissatisfaction with peoples cringe bad takes

will you ever take into consideration to eliminate downvotes?

There is an option in your settings so you don’t see upvotes or downvotes.

Lemmy (AFAIK) doesn’t even show you your total upvotes (karma… whatever it’s called) by default either. None of these imaginary points matter.

So why don’t you do yourself a favor and uncheck these boxes and not give a fuck what others think about your comment.

I know I have.

(Lemmy is rad as fuck)

There’s a forum sort called NewComments, that servers and any user can use to turn lemmy into a forum-style feed.

Instances can already disable downvotes site-wide, but we also already have fine-grained vote display settings:

Merging communities is no more possible than merging mastodon users.

Which mod tools do we need?

We already have RSS feeds.

We already have the ability to save posts and comments.

Word filters and flairs are in the works.

There’s too many other things here for me to answer.

do you realize that the power of the threadiverse is that a forum can even fully exist alone and the federation between them is a plus while for microblogging it’s kinda a shit to not have the big reach? basically, are you going to bring lemmy in a ‘‘more forum’’ direction or a ‘‘more social’’ direction?

Im not a fan of microblogging, so for me Lemmy should definitely be more like a forum.

will you ever take into consideration to eliminate downvotes? it’s clear that the reddit effect is already here and people are not incentivized to read the article and comment on point or discuss less agreable stuff just because posts gets downvoted?

As mentioned by others, downvotes can already disabled by the instance, so that local users cannot downvote and federated downvotes are ignored. Lemmy 1.0 will also add per-community downvote settings.

if on my instance downvotes are deactivated, do they still influence my home when I browse subs from other instances that have downvotes?

Yes

more UI mod tools! they are never enough because a community manager has not to be also a sysadmin or a linux poweruser just to take care of the community; stuff like subscribing to blocklists and allowlists, stuff like deleting cached media and so on

I only work on the backend, lemmy-ui and other frontends could definitely use more contributors to work on these things. Im not familiar with all the different apps but they are probably missing many features that already exist in the backend. That said subscribing to blocklists and allowlists seems a bit risky, as you can end up with most instances subscribing to the same list, giving the creator a lot of power. I believe Mastodon or Twitter had some drama like that. Anyway this could be implemented with the API.

how is the plugin stuff going?

Practically finished, you can already start developing plugins.

wouldn’t it be better to drop the android client and the federated wiki to fully focus on making lemmy the best federated threadiverse software? now that nodebb has federation the competition is existent (mbin and piefed were never enough e.e) and other frontends are generally cooler (voyager basically brought me back on being active here)

Lemmy is not a company with a boss ordering the workers what to do. Everyone including me and Dessalines are volunteers, and chooses for himself what he wants to work on. As its all open source its not really competition, more users on NodeBB is also good for Lemmy as it means more user choice and activity.

One reason Im working on Ibis is because I waited for a long time for someone to start a federated wiki project. Its a major thing thats missing from the Fediverse. As no one else did, I have to do it myself. The other reason is to have something different that Lemmy to code on. Working on Lemmy can be quite exhausting because the project is already very mature, so every new change needs to pass tests, be approved by other maintainers and work with the existing features. Ibis is still in early stages and under my control alone, so I can do whatever I want.

can we have a lemmy-first approach regarding comunication and contributions? basically i don’t want to make a github account to push some opinions and it seems like they kinda get ignored when on the lemmy community about lemmy

I checked your profile and it looks like you received adequate replies for all the latest posts.

ability to merge communities having them mirrored in a basic way i guess it’s already on his way

There are open issues for these, but developer time is very limited so we need to set priorities.

would be cool to have tags/flairs but i understand that it is not easy (tags could also become a way to follow stuff on par with communities, with their pros and cons obv)

Theres an open pull request for post tags.

would be cool to have tags/flairs but i understand that it is not easy (tags could also become a way to follow stuff on par with communities, with their pros and cons obv) would be cool to have lists to be able to browse lemmy from lemmy in a more rss way: for example there are communities i want to check once in a while but totally don’t want em in my home and having lists would help changing ‘‘favorite’’ posts into ‘‘bookmarks’’/‘‘saved’’ would be cool to have the possibility to have a favorite users list to check what your friends are up to any other suggestion would basically be ‘‘can this thing that forums have also be ported to lemmy?’’, i just think that lemmy has to evolve into a forum first with a link aggregator ui; it’s kinda easy to use discourse as a bug tracker and feature request tracker for example (observation made because of the previous question of using lemmy instead of github for non code stuff) would be nice to have word filters and user notes also lobste.rs invite tree would be nice

A lot of things would be nice to have, but with the very limited resources we have there is only so much we can do. So we need to focus on the main functionality, its basically the unix philosophy: “Do one thing and do it well”.

have you taken into account that maybe offering a service of lemmy hosting managed by you could help?

Yes, but in the end I dont think the profit would be enough to justify the workload.

dulcis in fundo, always about empowering non tech people, what about having lemmy on yunohost as one of the curated methods by the devs?

We dont have time to manage yet another installation method, but anyone can help out and contribute there.

Wow these were a lot of questions :D

This is a serious problem, that we didn’t anticipate during the first reddit migration wave. Since then, we added a join dialog to join-lemmy.org, and tried to make its join page sort by random, to spread out users more evenly.

Unfortunately, the people evangelizing lemmy on other platforms like reddit, continue to link specific popular servers, rather than join-lemmy.org or server pickers that sort by random. And people also tend to just link their own home server as a sign-up, instead of join-lemmy.org, so we’ll likely continue to see centralization problems.

We’re doing what we can to fight it, but other need to also.

I would love to see some community driven livestreams or events, where we could fund the developers ourselves through donations. We’re all refugess from reddit, but that doesn’t mean we have to be “libre reddit.” I think we could easily fund ourselves if we fostered more of a connected sense of community through events and conversations, turn this group of websites into something more than just friendly social media.

@nutomic recently added Donation dialogs, which adds support for wikipedia-style banners (which are annoying, but they work). I think most of lemmy’s problems could be solved if we were able to add a few more full time devs. We currently don’t even have a single dev funded.

Admits should defederate as they wish.

New users should be able to join a “default instance” that is federated with all instances so people can window shop for the instance they prefer.

That way they aren’t intimidated by the many choices available right away.

So, larger instances like .world and .ml will have more foot traffic and more new signups

Lemmy.ml is only 5th by monthly active users: https://lemmy.fediverse.observer/list

voyager as downloaded for android contains ads.

That’s Boost or Sync? Never seen an add on Voyager @aeharding@lemmy.world

Any possibility for hash tags to be added? Cross instance topics would be so much easier to browse especially when similar topics are discussed across different community names across difference instances.

I’d like to be able to browse the federation for tv show discussion with #tvshows or #fringe or something