Yea, i’m working on my own Fedi software and i’m struggling with the point of boosting in the link aggregator context. It’s an odd overlap with Reddit-style reposting to appropriate subs, but based on the user.
It makes sense in the Twitter UX, but i struggle to find it’s place in the Reddit UX.
I think boosts have potential to be used for crossposts, and the current implementation are just crossposts to your profile. Though they’re likely here right now just because Kbin is a mix between thread and microblog software
Boosting is super important in all contexts in the Fediverse.
When am instance subscribes to a content source - be that a user actor or a group actor - on behalf of a user, it only requests future content. Back catalogues are not fetched by default. Boosting re-publishes the content, so that it is received by new followers.
With a group actor, the boost triggers the actor to reboot the content itself, sending it out to new subscribers to the group, and filling in that back catalogue.
Users who use the website that the community is hosted on have access to the full library of it. They need to boost stuff. And people who subscribe from remote sites need to boost older content that they’ve seen.
but relevant users cant see it, its never fetched for them to see it. Sure users on the home instance can see it, but they’re on the home instance, it’s already fetched for them. Ive run into this problem on here, where there is a lot of content on other instances that isnt visible from kbin. I have the option of visiting the home instance to see it, but it takes me completely off of kbin, I cant boost it from that page.
Someone just needs to follow. The community owner either needs to seed the community to big instances using accounts on them, or people who find the community via other instances need to subscribe and know that fresh content will come. Then they can boost older content from the hosting site.
Things take some conscious effort here. That isn’t necessarily a bad thing.
“Then they can boost older content from the hosting site.” No that’s the problem. Like you yourself said back catalogues arent fetched. They can’t see the older content to be able to boost it, they’ll only see new content.
If my instance follows a community at time t = T, and your instance starts following it at time t = T+10, I can boost content posted between T and T+9 so that you can see it.
Meanwhile, if people on the hosting instance boost things posted from times earlier than T, we both get to see them. Then, once they’re visible to us, we can continue to boost them for new instances to see.
If boosting is meant to be a solution to the back catalogue problem, then it’s a horrible way to do it. You’d have to go through and boost every single post from before the hosting instance was followed, and then it’d only show up the user page of the guy who went to all of that effort? (or, realistically, bot).
If what I’m saying is accurate (and I’m still not sure because this is admittedly a bit too complicated for me) then it doesn’t sound very useful since individual profiles aren’t nearly as important in a forum context when compared to something like twitter, and especially when you can just upvote something and have that show on your profile. Unless I’m mistaken and anything you’ve upvoted doesn’t propagate to another automatically instance while boosts do… but I don’t think that’s a big enough distinction to have two different buttons? You could just have an upvote also do that.
I see it as similar to the “save” function on Reddit, except it’s public. I’ve started using it on things that I think I might like to read again later (and so by extension anyone who’s “like me” would probably want to read it too).
Yea, i’m working on my own Fedi software and i’m struggling with the point of boosting in the link aggregator context. It’s an odd overlap with Reddit-style reposting to appropriate subs, but based on the user.
It makes sense in the Twitter UX, but i struggle to find it’s place in the Reddit UX.
I think boosts have potential to be used for crossposts, and the current implementation are just crossposts to your profile. Though they’re likely here right now just because Kbin is a mix between thread and microblog software
Boosting is super important in all contexts in the Fediverse.
When am instance subscribes to a content source - be that a user actor or a group actor - on behalf of a user, it only requests future content. Back catalogues are not fetched by default. Boosting re-publishes the content, so that it is received by new followers.
With a group actor, the boost triggers the actor to reboot the content itself, sending it out to new subscribers to the group, and filling in that back catalogue.
I like this comment but I don’t know what im supposed to do about it
Boost things.
if old content isnt fetched for a newly subscribed instance to see, how are users going to boost that content in the first place?
Users who can see the content need to boost it?
Users who use the website that the community is hosted on have access to the full library of it. They need to boost stuff. And people who subscribe from remote sites need to boost older content that they’ve seen.
but relevant users cant see it, its never fetched for them to see it. Sure users on the home instance can see it, but they’re on the home instance, it’s already fetched for them. Ive run into this problem on here, where there is a lot of content on other instances that isnt visible from kbin. I have the option of visiting the home instance to see it, but it takes me completely off of kbin, I cant boost it from that page.
Someone just needs to follow. The community owner either needs to seed the community to big instances using accounts on them, or people who find the community via other instances need to subscribe and know that fresh content will come. Then they can boost older content from the hosting site.
Things take some conscious effort here. That isn’t necessarily a bad thing.
“Then they can boost older content from the hosting site.” No that’s the problem. Like you yourself said back catalogues arent fetched. They can’t see the older content to be able to boost it, they’ll only see new content.
If my instance follows a community at time t = T, and your instance starts following it at time t = T+10, I can boost content posted between T and T+9 so that you can see it.
Meanwhile, if people on the hosting instance boost things posted from times earlier than T, we both get to see them. Then, once they’re visible to us, we can continue to boost them for new instances to see.
If boosting is meant to be a solution to the back catalogue problem, then it’s a horrible way to do it. You’d have to go through and boost every single post from before the hosting instance was followed, and then it’d only show up the user page of the guy who went to all of that effort? (or, realistically, bot).
If what I’m saying is accurate (and I’m still not sure because this is admittedly a bit too complicated for me) then it doesn’t sound very useful since individual profiles aren’t nearly as important in a forum context when compared to something like twitter, and especially when you can just upvote something and have that show on your profile. Unless I’m mistaken and anything you’ve upvoted doesn’t propagate to another automatically instance while boosts do… but I don’t think that’s a big enough distinction to have two different buttons? You could just have an upvote also do that.
This seems needlessly convoluted.
This is why the functionality was hidden behind the upvote button initially, but people wanted the arrows to match the arrows on Lemmy.
I see it as similar to the “save” function on Reddit, except it’s public. I’ve started using it on things that I think I might like to read again later (and so by extension anyone who’s “like me” would probably want to read it too).