Post B4tXR3miyjsxLL1FYW by kura@hai.z0ne.social
(DIR) More posts by kura@hai.z0ne.social
(DIR) Post #B4tWi0Ih5RJPVOUKTw by privateger@plasmatrap.com
1 likes, 4 repeats
New blog post!“We deserve better boorus in 2026Boorus haven't evolved since 2005. Tags are flat strings, notes are unsearchable, and the query language is space-split.”https://blog.lattemacchiato.dev/we-deserve-better-boorus-in-2026/Tell me your thoughts! :)
(DIR) Post #B4tXNhzHZ4LAs3ILFg by kura@hai.z0ne.social
0 likes, 0 repeats
@privateger@plasmatrap.com tags should stay flat strings IMO. though there are some tags with a specifier. but I wouldn't add too much specifier logic.space split query language fit great with flat string tags, so I wouldn't change that. why overhaul something, that works great as is. searching notes or titles, I agree with you though.
(DIR) Post #B4tXR3miyjsxLL1FYW by kura@hai.z0ne.social
0 likes, 0 repeats
@privateger@plasmatrap.com I'm reading now the article. and revse possibly my opinion
(DIR) Post #B4tZBUm93n6wKPSDXU by kura@hai.z0ne.social
0 likes, 0 repeats
@privateger@plasmatrap.com well written article. thumbs up for that. i called it tags with specifier, you called it namespaces tags. i don't care about the name. but I wouldn't add too much.i at first understood it as a more finer granularity. like "hair:long hair:blonde". i dislike that idea. but for the high level stuff, that you explained in your post, I agree. though, I looked at it from an outside perspective and assumed it worked already like that. so it was a misunderstanding on my part. notes I already agreed. regarding the query language, I agree with support for data type native selectors. also with better concatenation options. so I revert my previous critic.regarding the graph approach versus simple tag list or whatever you wanna call it (this was meant as I have no idea and never did research in this) - I can't tell you what the best solution is. though personally, i want a solution that works with common DBMS available (SQL rdbms with maybe a kvdb). unless you can explain me the pros of using a full blown graph db for this.so in the end, I would probably tend forwards agreeing for your proposed changes.
(DIR) Post #B4tevEpdAdBjyGiR72 by toatrika@plasmatrap.com
0 likes, 0 repeats
@privateger tag namespaces are something that ive been wanting for so damn long. glad im not alone
(DIR) Post #B4tevF22QV74akWLS4 by toatrika@plasmatrap.com
0 likes, 0 repeats
@privateger oh, your suggestion is a lot more basic than what i want. that is good too, but id like tags to be relational more than just in general categories like "character". in the case of characters, theres many different characters who share names across franchises for example. another one: if "red_hair" and "green_eyes" is tagged, you have no guarantee that these are there to tag the same character. if there was a way to relate tags to one another, this could be solved. in that case youd likely want the top-level tags to be meta, object and character tags. then "detail" tags can be subordinate to them. a character could have red_eyes and belong to touhou. or it could be specified that inside the fire emblem franchise specifically the three houses entry is the relevant one.ive not thought much about how this would be implemented though tbf, i think itd be achievable though. searching could stay similar to how it is now or as described in the blog post for the most part. something like character:(red_hair green_eyes) could guarantee that both tags are applied to the same character. character:hatsune_miku:red_hair could guarantee that its miku who has red hair. something like that.a huge benefit of this is that it entirely eliminates the need for parentheses in tag names as what would traditionally be in there (mainly disambiguation) is now solved via relational/sub tags
(DIR) Post #B4tevFO16mh5gunti4 by privateger@plasmatrap.com
0 likes, 0 repeats
@toatrika what you describe would be more hierarchical tags I think. Funnily enough, also a perfect opportunity for the DAG-powered tag resolver! you'd just need a new edge type to mark tags as belonging to a parent tag (or just re-define encompasses to mean that). follow the subtree and you'd get a hierarchy that you then do not cast into a flat result, boomthis would probably work best with a real graph engine backing it, but it sounds very achievable. i focused on keeping it more "classic" in this one, but many new possibilities emerge with a graph model
(DIR) Post #B4tfPkoeombRr8oNGq by privateger@plasmatrap.com
0 likes, 0 repeats
@kura@hai.z0ne.social You can actually implement a DAG on top of Postgres quite easily, without ever even needing to leave SQL! you just need two tables: nodes and edges. Cycle detection can be implemented as a recursive CTE or a simple traversal at insert time. Implication expansion is another recursive query or a cached walk.The practical stack would probably be Postgres + some search engine (Meilisearch/Typesense) for FTSa dedicated graph DB (Neo4j for example) would theoretically help if your traversal patterns become deeply nested and highly variable. for most boorus the graph would be relatively shallow (maybe 3-5 levels deep), and the traversal patterns are predictable and easily cacheable by postgres
(DIR) Post #B5ypbp7kdyc1pBS3Ps by vftdan@mastodon.ml
0 likes, 0 repeats
@privategerEach image having its own wikidata-like pageMaybe some combination of wikimedia and wikidata -structured wikis
(DIR) Post #B9RYIZeqA64hhFKbyq by toatrika@plasmatrap.com
0 likes, 0 repeats
@privateger randomly was thinking about this blog post again. how does the DAG-method deal with situations like the following?: in the example, -blonde_hair removes all marisa_kirisame posts from the result. however, sometimes a character is drawn with a different hair color. such an image would be excluded here (as far as i understand) even though blonde_hair wouldnt actually be present in the image
(DIR) Post #B9RYIZsJM0qmN1dMye by privateger@plasmatrap.com
0 likes, 0 repeats
@toatrika you raise a very good point :niko83C:take a look at the comment section at the very bottom, I made a reply to a similar question that basically covers that