this post was submitted on 19 Aug 2023
2 points (75.0% liked)

Lemmy Project Priorities Observations

5 readers
1 users here now

I've raised my voice loudly on meta communities, github, and created new [email protected] and [email protected] communities.

I feel like the performance problems are being ignored for over 30 days when there are a half-dozen solutions that could be coded in 5 to 10 hours of labor by one person.

I've been developing client/server messaging apps professionally since 1984, and I firmly believe that Lemmy is currently suffering from a lack of testing by the developers and lack of concern for data loss. A basic e-mail MTA in 1993 would send a "did not deliver" message back to message sender, but Lemmy just drops delivery and there is no mention of this in the release notes//introduction on GitHub. I also find that the Lemmy developers do not like to "eat their own dog food" and actually use Lemmy's communities to discuss the ongoing development and priorities of Lemmy coding. They are not testing the code and sampling the data very much, and I am posting here, using Lemmy code, as part of my personal testing! I spent over 100 hours in June 2023 testing Lemmy technical problems, especially with performance and lost data delivery.

I'll toss it into this echo chamber.

founded 1 year ago
MODERATORS
 

Ok, taking a total fresh approach based on all the months I've been reading people's suggestions and [email protected] kind of things....

All / All Remote / Local / Remote Specific-Isntance

I think server operators should at minimum want the ability to view Remote-only, and even per-instance. Further, I think proxy of API to a community should be something to head towards... where a Lemmy API call can be forwarded as an API call on another Lemmy server for a specific community.

Small, Medium, Large, Trending, Featured Community

Some stock multi-community lists, some of which are dynamically generated like Small / Medium / Large based on number of active posts, users, or other tunable parameters. Encourage people to engage in topics that they normally would not see...

Multi-community sharing

I think foundation is that it should use words and not numbers. Right now, the entire Lemmy system is built upon using localized index numbers for community. Even if it just becomes a JSON blob to throw into PostgreSQL and recall by name...

Maybe have them like communities. And people can subscribe/unsubscribe to a specific list. And the list can have moderators who regulate it (editors). And an option to clone a list to new name.

/mc/ multi-community, name. And no ID numbers. A Trigger or something would have to build the ID numbers in the background.

And a browser of these, much like communities are browsed... and maybe even voting on them. Lemmy doesn't have voting on communities - subscribe alone - but sometimes you don't want to subscribe because they have too much content - but you would still vote for it or recommend it.

top 8 comments
sorted by: hot top controversial new old
[–] [email protected] 1 points 1 year ago

These are the kind of things I think I need to start experimenting with as we nail down performance-concerned compromises.

I really wanted a design of filtering posts with LIMIT 1000 per-community, as in the back of my mind browsing Small or Medium community is really at the heart of Lemmy as opposed to Active / Hot kind of browsing that way favors popularity (memes, etc).

[–] [email protected] 1 points 1 year ago (1 children)

ok, what's really the easiest way to do this?

  1. create a community, set it hidden...
  2. create a person, set it as bot account. associate the person as owned by the community...
  3. Allow switching to another person for a session. Create posts, comments, subscribe/block/unsubscribe/unblock from that person.
  4. Most important, list posts as that person you switch to. That has to be available as read-only to anyone.
[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

The problem is that I don't think follow of community and block of community gets federated to other instances/servers (other than the home for remote communities). So a downstream instance wouldn't be able to view a person's community whitelist and blacklist. Fundamentally, the data isn't there.

Humm. Then there is the issue of not wanting to create any new federation protocols.

A community can be created, published, and inside that community a message that gets edited with the list... but then only the person who creates a post can edit a post.

Is the only entity that gets fully replicate the list of moderators for a community? And a community itself. We could edit the community to have a list inside it.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Pros and cons

Community
con, does not have a community subscribe and block list
pro, has moderators list that spans instances

Person
con, you can't login to a person account on a remote instance. So that's less like a community
con, no moderator list for a person
pro, has all the ability to build list of communities to whitelist or blacklist
pro, can also blacklist persons (which I guess a community can too, ban list)

More observations
A Person who can login is a local user, and there is an alternate table for that.
A community does have a home instance as does a Person. So it does matter where created. [email protected]
non-Lemmy federated things get confused by communities name clashing with persons. Which even email systems I have used with public folders assigning an email address, it's basically treated like a person. Lemmy allows a@person and a@community, do we follow that convention, a@multipass ?

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

Some random thoughts on how to build this in a hurry...

Clone the Community tables

community
community_aggregates
~~community_block~~
community_follower
~~community_language~~
community_moderator
~~community_person_ban~~

Try to figure out how the main SELECT queries for listing posts will use this. We don't want another JOIN ... so ultimately maybe make it a virtual Person (hat ends up being a security role, borrowing from PostgreSQL that USER/ROLE are same?) and these get dumped into the community_follower table with a different parameter passed for the PERSON when the query runs?

Browsing should basically be a new button next to Join to "Add to multi-community"

Maybe name this all multipass in reference to 5th Element ;)

[–] [email protected] 1 points 1 year ago (2 children)

Federation already knows how to replicate Community and replicate Moderator list for a community.

A Person profile lists the communities someone moderates. Maybe create a Person as the multipass? And add a new bot-like attribute to be Role/Multipass?

[–] [email protected] 1 points 1 year ago

namespace clashes... prefix with a normally unallowed character? Person and Community?

Community has a hidden attribute. That could be converted to Smallint.

[–] [email protected] 1 points 1 year ago* (last edited 1 year ago)

That's right... when you browse the community list there is a subscribe/unsubscribe for local person. Maybe pass the mutlipass id on URL?

A Person doesn't have moderators like a community. So this is a hybrid concept.

Simulating login as a person would allow browsing and subscribe/unsubscribe ... and even allow a password for that community. But there wouldn't be a way to list moderators for a person.... hum. Can we hack a moderator list into a person profile?