Community post tags (part 1) #4997
Conversation
phiresky
requested review from
dessalines,
dullbananas,
Nutomic and
SleeplessOne1917
as code owners
| published timestamptz NOT NULL DEFAULT now(), | ||
| updated timestamptz, | ||
| deleted timestamptz | ||
| ); |
There was a problem hiding this comment.
How about renaming this to post_tag and later adding a flag global: bool? Then global tags wont need their separate table, query and api endpoints.
Also the name post_community_post_tag could be simplified to post_tag_relation then
There was a problem hiding this comment.
yeah, if we only expect global tags then it makes sense I think. I'm just not sure whether we should plan for more unknowns, because
- the same tag elements are also incoming from other AP software, but those might have pretty different structure, so can potentially not be handled in the same table
- there are other types of tags we might want, for example foreign community tags (e.g. fact-checking posts in communities by third parties similar to Community Notes on twitter), or tags with values etc, that are also "post tags" but need to be handled differently as well
There was a problem hiding this comment.
the same tag elements are also incoming from other AP software, but those might have pretty different structure, so can potentially not be handled in the same table
Everything that federates needs to fit into our data formats, otherwise it gets ignored completely.
there are other types of tags we might want, for example foreign community tags (e.g. fact-checking posts in communities by third parties similar to Community Notes on twitter), or tags with values etc, that are also "post tags" but need to be handled differently as well
Sounds like an entirely separate feature so I wouldnt worry about it now.
There was a problem hiding this comment.
I would go ahead and create the global tag table, that contains all those columns above (except community_id). We can use that table as the primary store for all kinds of tags in the future, and be the main table that's joined to.
When tagging things later, we can check that its one of the allowed tags for that item. IE we can check that a given tag is in the person_tag table, or the community_post_tag table, before we let the item be tagged via the API.
| published timestamptz NOT NULL DEFAULT now(), | ||
| updated timestamptz, | ||
| deleted timestamptz | ||
| ); |
There was a problem hiding this comment.
I would go ahead and create the global tag table, that contains all those columns above (except community_id). We can use that table as the primary store for all kinds of tags in the future, and be the main table that's joined to.
When tagging things later, we can check that its one of the allowed tags for that item. IE we can check that a given tag is in the person_tag table, or the community_post_tag table, before we let the item be tagged via the API.
| @@ -0,0 +1,18 @@ | |||
| -- a tag for a post, valid in a community. created by mods of a community | |||
| CREATE TABLE community_post_tag ( | |||
There was a problem hiding this comment.
Pry just rename this one tag.
| CREATE TABLE community_post_tag ( | ||
| id serial PRIMARY KEY, | ||
| ap_id text NOT NULL UNIQUE, | ||
| community_id int NOT NULL REFERENCES community (id) ON UPDATE CASCADE ON DELETE CASCADE, |
There was a problem hiding this comment.
Remove this linking column, and create a new table called community_post_tag, with a primary key of (community_id, tag_id) . Also add a published column
Check out any of the other bridge tables, like post_read, community_block, etc for examples.
| -- an association between a post and a community post tag. created/updated by the post author or mods of a community | ||
| CREATE TABLE post_community_post_tag ( | ||
| post_id int NOT NULL REFERENCES post (id) ON UPDATE CASCADE ON DELETE CASCADE, | ||
| community_post_tag_id int NOT NULL REFERENCES community_post_tag (id) ON UPDATE CASCADE ON DELETE CASCADE, |
There was a problem hiding this comment.
This can just reference tag_id , and in the API we can double check to make sure that tag exists and is one of the allowed ones in community_post_tag.
And also of course, in the front-ends, it should only show the correct subset of tags anyway (probably via a searchable dropdown or something).
| @@ -183,7 +183,10 @@ pub fn config(cfg: &mut web::ServiceConfig, rate_limit: &RateLimitCell) { | |||
| .route("/follow", web::post().to(follow_community)) | |||
| .route("/block", web::post().to(block_community)) | |||
| .route("/delete", web::post().to(delete_community)) | |||
| // .route("/post_tags", web::get().to(get_community_post_tags)) | |||
There was a problem hiding this comment.
Can mark as draft until this is ready.
There was a problem hiding this comment.
I would do this in a separate pr after this is merged
| CREATE TABLE post_community_post_tag ( | ||
| post_id int NOT NULL REFERENCES post (id) ON UPDATE CASCADE ON DELETE CASCADE, | ||
| community_post_tag_id int NOT NULL REFERENCES community_post_tag (id) ON UPDATE CASCADE ON DELETE CASCADE, | ||
| PRIMARY KEY (post_id, community_post_tag_id) |
There was a problem hiding this comment.
Then this would become (post_id, tag_id)
This is the first part of an implementation of post tags based on LemmyNet/rfcs#4.
It implements the following:
What is missing:
I would like to propose that we work on and merge this (and potentially other larger changes) in multiple parts, as soon as each part is ready and ofc doesn't negatively affect the existing functionality. That way the branches don't live for months and diverge more and more and each chunk stays simple and can be reviewed quickly.
There's some somewhat open questions wrt this code:
community_post_tag (id, apub_id, name, url)so it's clear this is a tag that belongs to one community and tags posts in that community. This way we can later more tag types that may have different meanings and especially different properties and access control. For exampleglobal_post_tagfor tags that are the same / interpretable globally (like NSFW). The n:m association table is calledpost_community_post_tag (post_id, tag_id).