RoundSparrow

Lemmy is pretty immature as code to actually run in production. It may be well over 4 years old, but the whole thing seems to have very little in the way of information that a server operator can look at to check the health and problems under the covers. It also doesn't deal with unrecognized data very well and hides a lot of errors in a log where the messages are often not very much of a hint what is going on.

Lemmy surely is unique, as I almost never see people using it actually criticize the code for quality assurance and testing. More often than not, I see people cheering and defending it. I've had to look through this experience and code as it is more run like an art project or a music band than any serious focus on data integrity or performance concern.

if it were me right now with Lemmy 0.18.4, I'd take the server offline, do a PostgreSQL dump file - keep a copy, then hand-edit the sequence numbers in the dump file - and do a restore.

you probably only had a few users, so I would set user to 100, person id can be higher because of federation - but jump ahead to 10000 maybe. Post and comment set ahead to 10000 ... and community set ahead to 10000 because that gets federated

the PostgreSQL sequence numbers should only get used on newly created objects here-forward.

Right now lemmy backend only supports a single 'subscribed' list, that would be like a music player only having a single playlist. I know people are using multiple logins just to have more flexibility in managing their lists.

GitHub issue about this topic: https://github.com/LemmyNet/lemmy/issues/3782

Some of it might be avoided by tweaking the PostgreSQL database with higher key values after the new install, but the whole situation isn't really planned for or recognized in the code

You really have blind faith that federation even works, when I've been validating data and highlighting that delivery is not reliable when it has so much overhead it crashes servers.

This basically shuts my idea down

it's not very difficult to modify the code for something like this.... and closing off registration wont' let anyone else login and create new content form your istance.

Personally the load on the major servers by having one more instance that subscribes to everything is why I think people should back off from creating more than the 1500 instances Lemmy network already has. Delivery of every single vote, comment, post 24 hours a day just so one person can read content for an hour or two a day.

That makes sense for email systems where all that content doesn't have to be sent, but for Lemmy it's a huge amount of overhead.

ok, I'm going to delete this post. People actually aren't discussing privacy and are just debating if they think Lemmy needs Multi-Reddit. And I just want to get the code finished. I am probably moving ahead on the code with ZERO sharing of any existing data.

dismissing client-side techniques as nonsense without seeming to understand why they were being discussed in the first place.

I'm the one who started a post about a server-side solution that entirely is based on Reddit's code for a server-side solution. YOU are the one coming along with this wild idea that a server change isn't needed at all. yet, you have not demonstrated this wild claim you made!

I’m not interested in any multireddit feature that reduces sub privacy. I’d consider it a net loss for lemmy.

It does NOT require it. I will repeat it: IT IS NOT REQUIRED! It is a sub-feature that facilities better openness that I am suggesting be added as part of the core feature I'm developing.

On Reddit, multi-reddits personal in nature.

10 years ago Reddit announced it as entirely not being personal! That sharing them was the whole point. I again question if you even understand what multi-reddit is!

shouldn’t require relaxing privacy constraints in any case.

It isn't at all essential to the feature.

I have already coded it so that it does NOT require sharing of anyone's data, at all. No way shape or form. I'm proposing it as a discussion topic because it's easy to implement and goes along with the whole spirit of a public forum where people share their public stuff. That people might actually want an easy way to help others out...

But, it's easier for me just to avoid any privacy topic entirely and not allow sharing of anything. Just build the whole design with opt-in only empty list.

I’m suggesting that multireddits are a “local” function. Theu are so local that they’re possible without server-side support at all,

Again, how? If I want a blend of 50 different communities, how can Reddit or Lemmy do that without 50 API calls if you do not add server-side MultiReddit code?

50 API calls is the overhead and nonsense that is being avoided here....

It could also be a filtered view based on the subscribed/all feed which provides a single API call that can return material from multiple communities.

"that can return material from multiple communities" - that's exactly how Reddit does multi-reddit, what feature do you think multi-reddit is?

But it should definitely be off by default and have a clear warning when you try to enable it.

I was afraid people would say that. The easier way is to just not touch it at all, as adding new code to opt in/opt out is more Rust code programming that is in rare supply with developers.

The easiest solution is to avoid it and not introduce sharing of personal communities at all. Which was what I was afraid this discussion would yield. So we start fresh with empty MultiPass lists and build them up from scratch.]