RoundSparrow

joined 1 year ago
MODERATOR OF
[–] [email protected] 3 points 1 year ago (1 children)

I see it’s not active anymore

Been happening to a lot of communities. Good morning to you! https://www.youtube.com/watch?v=g9ixvD0_CmM

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

I could see this attribute picking for various opt-in features.... "allow voting plugin posts", "text-only posts, no url link post", "posting hours only allowed in daytime North America when mods are around", "postings only allowed on weekends and holidays!"

The API structure is already there to inform which of the 184 human languages a community has picked. So that gives a sense of just how many of these attributes can be created.

 

I've been pondering the way language works as an attribute in community.

Right now there are two attributes to highlight: NSFW and "only moderators can post".

There is an active pull request to add "only the home instance can allow posting", sort of a variation on the "only moderators" can post: https://github.com/LemmyNet/lemmy/pull/3889

Which is the 20 source file changes for the new feature.

I envision that new attributes will keep coming up, and I see need for an additonal one to make cleaner the [email protected] feature.

Observation

A general 'attributes' table could be created like the existing language table. And then duplicate the logic in Community Edit for picking the languages associated with a community... except you are picking the attributes associated with a community.

This could possibly cut down on the amount of lemmy_server code changes for each new attribute?

I envision in the future there will be 'members only can post' (subscribed only), and variations of NSFW that people want to implement... and it could be done by not having to add new PostgreSQL columns to tables... and just a general scheme to insert a new registered attribute ID...

 

When reading news, I want to know which website goes with the headline... just seeing a link to archive.org doesn't give that information. Cross-posting should be based on source URL, not the various archive sites hosting copies.

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

I've been experimenting with ways to design this and if anything federation holds it back. Lemmy kind of crams content into federation structures and this kind of showed me how limited it can be.

There isn't much in Lemmy that can be assigned multiple editors. A community is the only thing that federates, with a list of multiple moderators... so I'm playing around with a community as a means to edit.

 
  1. post primary key has gaps in it, the sequence is being used for transactions that are later canceled or some kind of orphan posts? This is observable from incoming federation posts from other instances.

  2. comment_aggregates has a unique id column from comment table id column. There is a one to one row relationship. Can the logic be reworked to eliminate the extra column and related INDEX overhead?

  3. Related to 2... Same issue probably exist in post_aggregates table and others that have one to one join relationships.