this post was submitted on 06 Sep 2023
104 points (94.8% liked)
Open Source
28934 readers
348 users here now
All about open source! Feel free to ask questions, and share news, and interesting stuff!
Useful Links
- Open Source Initiative
- Free Software Foundation
- Electronic Frontier Foundation
- Software Freedom Conservancy
- It's FOSS
- Android FOSS Apps Megathread
Rules
- Posts must be relevant to the open source ideology
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon from opensource.org, but we are not affiliated with them.
founded 4 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What about the federated picture?
An instance doesn’t just have its tags, it has all tags for all communities and instances. tags require storage (disk); retrieving and searching by tags require compute.
So if you have x instances each with infinite tags, but each tag referring only to a tiny … this may not be great for the server.
Great point about frozen tags.
Maybe archived/frozen tags generally should not be transported to federating servers, except when actually needed like for showing them in a list, or when a post that is being viewed has some of them. Even then, these ones could be only stored in a cache-like fashion, possibly with an upper limit on storage.
A count of such tags may still be useful to transport, though.. to show it on the UI to the user, and possibly for the server to decide whether it wants to preload them right now.
There could be limits though on the number of tags a post can have (10?), and the number of non-archived tags a community can have (50?), with both of these being configurable for a server by an admin, and preferably also allowing community specific overrides for these limits.
Also, yes this sounds a little scary, but is it really a problem? Posts and comments can be infinite too, and they contain much more data, a long blob of text. Compared to that, tags should only contain a label, a color code, maybe a description, and that's it. Maybe some simple properties in bitflags later.
And tags should also accumulate much slower than posts and comments.
But, if a federating sever or a client would load all the tags at once (which does not happen with posts and comments, right?), that may be a problem, but the limit on non-archived tags could solve this I think, and a conservative limit on tag label and description length (details may as well go into a wiki (I think we don't have those yet, though) or a post like that)
A binary large object (blob) is trivial for a database; a post is only loaded once & rendered in full exactly once.
Tags are a search key and will be constantly rendered & used as a filter.