Comment on Unified Fediverse App - a browser solution?
lime@feddit.nu 2 days agohm, i think there’s some confusion regarding AP here. there’s no “deciding where things should go”; every frontend can “see” every type of post, even if the format is off. what you’re describing by is essentially how it already works, no multiple accounts needed. the frontend just needs to decide how to handle it. for lemmy-to-masto the handling is pretty basic, you can see it by going to a mastodon server and searching for your lemmy account (formatted as @yourname@yoursite.blah).
for the “gossip” thing, every server already publishes every new thing. it’s up to other servers to decide how to handle it.
regarding the automated tagging system, i actually had a similar idea recently. i think a big flaw with lemmy/mbin/piefed is the keeping of communities from reddit; if the already extant tags were used instead, the cross-posting problem would go away completely since comments would be attached to posts rather than communities.
anyway: it would not be difficult to just use words in a post to assign it tags, but i question the usefulness of doing that. some sort of analysis would help, as you say, but then we’re introducing nondeterministic behaviour. there is definitely a discoverability problem on fedi, and something like this could definitely help with some polish.
Coopr8@kbin.earth 2 days ago
Regarding "where content should go", I mean like which community to post a lemmy post in, or which account to post to if a person manages multiple topical accounts (or accounts in different instances specialized for specific services), or whether to format it for loops vs peertube for video, etc.
Gossip wise, I'm imagining compressed data posted in a format only intended to be ready by the automation systems which happens before the suggestions are made, so that the suggestions can include dynamicly grouping content before publication by appending the relevant metadata/format (like posting in a lemmy community).
lime@feddit.nu 2 days ago
the formatting is up to the client that displays the content, interestingly enough. AP just has a “message type” fields and different clients care about different types.
i’m not really sure what that gossip method achieves. surely if it’s just post metadata we’re talking a hundred bytes at most. running it separate from the main feed seems like it would just bork every single AP client that tries to use content published by this hypothetical one.
Coopr8@kbin.earth 2 days ago
Yes, the automation datastream would need to be segregated, and probably ephemeral.
The point is that if you want posts to spontaneously coalesce with some kind of shared Metadata, you want the ML content analysis information of the post to go out before the actual post is published so the final post Metadata can include the "group" tag or whatever you want to call it.
Alternately you could do it after the fact by editing the post, but that seems like there would probably be some degree of chicken and egg scenario.
All of this could be done by the client completely independent of post metadata of course, but then how do you make the relation of the posts to each other consistent between multiple users? Is that even a desireable/necessary goal is a question I suppose.
lime@feddit.nu 1 day ago
i don’t understand this assertion at all. the post is the post. surely we want to classify the post based on the content of the post? tags are contained in posts. your client can just add the relevant info before sending it. figure out potential categories locally, query the server for which of them are popular, and either pick one or have the user select one.