Magazines can be deleted. There is a Delete Magazine button in the Magazine Panel of any magazine you own (on the General tab, first one).
However at this time it does not appear to be an automatic thing (I believe Ernest has to clear then manually). I've deleted around a dozen so far (which were taken care of within 24h) and have had over a dozen more as well waiting for deletion (which have been sitting there for a month+ as Ernest has been busy as of late, and then the holidays and such).
I came to the Threadiverse because Reddit was closing its APIs and building the walls higher around its garden.
I will be supremely disappointed if the Threadiverse collectively turns around and does the same thing.
Instances should be defederated when they do something harmful. Preemptively defederating is counterproductive, it gives Meta no incentive to do things right.
Yep, the Reddit metaphor really backfired. If Reddit joined the fediverse I would happily consume their content. It would actually be a wonderful compromise where reddit wouldn’t have to provide direct app support and instead just publish out via ActivityPub and people could build third party clients through that.
I left Twitter because they killed Tweetbot and I left Reddit because they killed Apollo. I genuinely hate the experience of those sites with their native apps, and I use these kinds of services almost exclusively on my phone.
While I also hate Elon Musk and Spez, I strongly dislike most tech CEOs so while a motivator, it wasn’t the biggest factor for me. It’s important to remember we’re not all here for the same reason, and user-level instance blocking is the real solution here.
You don’t like some fediverse member? Then block them at the user level and move on, or start your own server and block them there. Don’t force everyone else on your server to not even have the option just for you.
I came to the Threadiverse because Reddit was closing its APIs and building the walls higher around its garden. I will be supremely disappointed if the Threadiverse collectively turns around and does the same thing.
So instances on the fediverse have some obligation to let entities who (A) will control 99% of the content, against our values of a decentralized, more evenly distributed fediverse; (B) have zero interest in an open fediverse; and (C) have all the incentive in the world to prevent its growth and get more people on their own platform to ensure profit? As usually hesitant as I am about preemptive defederation, if the fediverse is to preserve its values of openness and ensure its growth, it can't let in for-profit corporations that will control most of the activity and that go directly against those values of openness we care about so much. Just as tolerance doesn't mean letting in those who are intolerant, an unwalled fediverse can and should put its guards up against those who want to take everything for themselves.
it gives Meta no incentive to do things right
Meta already has zero incentive to do things right. In fact, they have negative incentive, as people being on Mastodon or Kbin instead of Threads actively harms them. You will never see Mark Zuckerberg suggest that people spread out to other instances so that no one gains too much control, but you will see him try to get as many people from the other instances on Threads as possible. We are talking about making our activity dependent on a for-profit tech corporation. If we were way larger so that Threads wouldn't control such a massive portion of activity, I wouldn't be as concerned, but as things stand now, we're letting our content pool be dominated by a company that has interests in direct opposition with ours. I can't see a scenario where any of this ends well.
Nothing makes it special. My point is not that I think Facebook will do no wrong, my point is that it's counterproductive to defederate from them before they've done something wrong.
Big takeaways, emphasis preserved from the original:
Threads is entering a space in the fediverse which is dominated by Mastodon, so it's Mastodon and other fediverse microblogging services (including, to some extent, /kbin) which will most heavily feel the impact of Threads.
Defederating another server means your instance will stop requesting content from that server. ... Defederation is about what data comes in, not what goes out. ... Defederation doesn't make you invisible, it doesn't block anybody else from seeing you, it doesn't protect your content, it only means you never have to see their content.
Firstly, the fediverse is a drop in the ocean compared to Threads (104 million registered users). Obviously, Meta wants everybody, but their specific goals in terms of user-poaching are far more likely to center around the ~350 million active Twitter users than the ~12 million fediverse users (~3.5 million active). The threadiverse [Lemmy, Kbin, et al] is smaller again, at something like 100,000 active users.
"Threads will overwhelm the fediverse with their inferior content and culture." Like the EEE fears, this one is legitimate but once again something that will primarily be felt by microblogging providers (/kbin included). Toxic users, advertisers, etc. can push garbage into feeds all day, but they will largely not be targeting the threadiverse because there's some 100 million sets of eyes to put that crap in front of on the microblogging side and it will be difficult-to-impossible for them to push that content into Lemmy/kbin threads from their interface that was never made to interact with the threadiverse.
Is there any chance Meta has good intentions?No. But it might have intentions that are both self-serving and fediverse-neutral. The absolute best intention I can possibly ascribe to Meta is that joining the fediverse is a CYA (cover your ass) mechanism to head off regulations, especially in the EU, [e.g.] the newly-applicable Digital Markets Act ...
Defederation is about what an instance allows in, not what an instance allows out. Defederation stops you seeing the defederated instance's content, but it does not stop them seeing your instance's content.
Threads poses some danger to the fediverse, in particular the portion of it centered around microblogging (mostly Mastodon, but also Pleroma, parts of /kbin, etc.), but very little risk to the threadiverse.
The worst thing about the fediverse is all the fondue, but you don't have to eat it.
Emphasis from the original post.
This is a detailed summary, thank you for linking.
I have also read some other POVs here; my fears are not totally allayed and I still think Meta is only engaing with Activity Pub to prevent new, potential competitors arising from it.
I hope the OP is right about it being very little risk to the Threadiverse. The good news is that Threads is focused enitrely on microblogging and not the Threadiverse. Perhaps that means Kbin and Lemmy users will be able to sit on the sidelines and see how it plays out for a bit, idk. Mastodon users will be seeing the most change.
The issue is that this does affect Kbin because Kbin is a microblogging platform. It's also a thread aggregator, but it has microblog functionality that some people do actually use. Should we not defederate, stuff from Threads will flood the microblogs of Kbin. If your home page is set to use the All Content feed (like mine is), you'll see microblogs from Threads there. This doesn't have as much of an effect as it does on a purely microblogging-focused platform like Mastodon, but it does still affect a big way that Kbin is used.
Right, and that’s part of why I remain a skeptic. Kbin’s microblog being overtaken by Thread’s content could very well limit kbin’s growth and viability as a microblogging platform - especially if Meta pulls the plug later.
But, I have also seen the opinion that not having Threads content could make kbin unappealing as a microblogging platform. (I’m not sure if I agree with this, but I have seen it mentioned.)
I guess the questions are, Can Kbin grow with Threads content? And, Will the lack of Threads content make it unappealing to new users?
Also, another problem I think is that kbin might not have the userbase and content yet to be self-sustaining when faced with a goliath company like Meta; if we produced as much content as Threads will (or enough to the point that defederating kbin would hurt Threads) then there wouldn’t be much of a concern.
Idk, Threads is ultimately the one forcing the situation (probably intentionally) where federating with them is risky but also refusing to do so could be self-isolating. I still maintain that they’re doing it now while the fediverse is still young for a reason, and that is so they can grab so much of the “fondue” that everyone comes to them anyway.
I would like to see kbin succeed, and I don’t trust Meta. Whatever kbin decides to do I will be here for it, but I’m definitely a Meta skeptic.
To put my own skin in the game, I quite like the microblogging side of kbin. I like that I can swap between the thread and blog sides, I like that I can combine them into one view if I choose, and I like that I don't need a separate account to use either service. Using kbin's microblog was the first time I ever blogged, period. I'd hate to see that stream be overwhelmed by Threads users.
Exactly one of the reasons why I remain a skeptic.
I don’t want sound too much like I’m complaining about “Eternal September” but I quite like how kbin’s microblog is right now. Having millions of threads users suddenly flood it with random… crap… would change it forever.
I haven’t used instagram in more than half a decade. When I hopped on to see what it was like recently, I hardly recognized it and all the content was completely irrelevant. I would hate to see that happen to the microblog.
I'm not a mod, just an active user so my opinion on the first two doesn't really matter (even though I do think these would be good additions). I agree with the need for wikis as well.
That said, personally I could not care less about whether someone is online or how many people are reading specific thread - what I care about is actual interaction with other users, i.e. discussion. I treat kbin/lemmy like a forum rather than a constantly moving social-media site like Twitter so take this as you like. It's not like it would affect my use of the platform in any meaningful way.
They appear to have stopped for now.
The only one I saw is u/locutor99 which was created 11 hours ago but I am not sure if it connected to the other ones since the posts are about dubbing and not watching movies.
When it comes to /kbin as a platform, the federation of downvotes will certainly work and will be configurable per instance. Today, I started the initial work on implementing new ActivityPub services from scratch. This is a good time to start a discussion on how it should work on kbin.social - to your points, I would also add:
Downvote federation only applies to remote threads from other instances, without affecting local therads
This is a good time to start a discussion on how it should work on kbin.social
A while back, I made a thread on /m/AskKbin about this. While it's not solely kbin.social users, there's still a lot of good input, and you could use KES to sort through those who are and aren't on the instance if you want. My two cents are that it's important for downvotes to exist, be federated, and be shown separately so that (A) people can easily express that they feel something doesn't helpfully contribute to the discussion and (B) similar expressions from other instances aren't drowned out.
Downvote federation only applies to remote threads from other instances, without affecting local threads
To be clear, what exactly do you mean by this? Does this mean that downvote federation is one-way (i.e., that downvotes federate from Kbin instances but not to Kbin instances)?
I understand what you are saying here, and I have flip-flopped on the issue myself. At the moment I personally am a fan of the limited downvote federation because I do think it acts as a hivemind barrier; to use reddit as an example, as it got bigger the downvote was used as a means to disagree without adding any value to the discussion or to simply silence a dissenting point of view.
That is not to say there were not times when a downvote was warranted - hateful comments, racism, sexism, homophobia, transphobia, and general bigotry are all more than deserving of a downvote. There are also bots and general off-topic posts & comments that may warrant a downvote.
Overall though, I think the problem is how the downvote was used (on Reddit, at least) was not conducive to discussion. However, due to the fact that upvotes and downvotes are public on kbin it is possible that behavior could change, but then that could create problems with other instances where none of that information is public to begin with. (Nobody wants to have a crazy person come after them over a downvote.)
Right now, the fediverse is pretty small and Kbin is actually the most welcoming instance I have found so far. I am not sure if the lack of downvote federation has anything to do with this, but so far I actually like it. Maybe once kbin and the expanded fediverse grows larger my opinion will change, but right now I feel like it’s helping to make it more hospitable than reddit.
A key difference here is we can see who downvoted which I think makes people more cautious to downvote. I guess Lemmy users aren't used to that however (but it might change their behaviour when they realise we can see!)
Right! I sometimes wonder if that could not lead to a schism in the future; many, many people on lemmy value their complete anonymity and they could see kbin exposing their upvotes and downvotes as a violation of that. (Not saying that people on kbin don’t, but I think we act knowing that people can see who upvoted/favorited or downvoted/reduced a post.)
I can say that public voting has definitely changed my use of the downvote; I was much more trigger happy with it on reddit whereas I don’t think I have used it at all since I joined kbin. Lemmy users seem to use it the same way Redditors do, largely because voting isn’t public on their end.
Ill be honest, voting being public is a big deterrent from kbin for me, after having experiences in the past of having people harass me on the assumption that I had downvoted their content.
The risk of being targeted for harassment over a downvote basically cements kbin as an unusable platform for me.
E: And, on thinking about it? It also has me doubting the quality of kbin sourced content. Downvotes on reddit style forums, which this is, work as a community driven content filter. Actively discouraging the use of that filter means higher quality posts are harder to discern. And sifting through more chaff per good post is not appealing.
I see where you're coming from, but this to me seems more like a property of the fediverse than an issue with Kbin in particular. Right now, anyone can make an instance and choose to show downvotes. Someone could make their own instance, gather downvotes federated from other instances, and make a list of who's downvoted who. Being on an instance that doesn't show downvotes doesn't hide your downvotes from everyone — just you and others on instances that don't show them.
On this end, I feel that Kbin instances are just being transparent about the publicity of your votes. If anyone can see your downvotes just by looking at an instance that shows them, I think it's important that people are aware of that. Showing public votes is sort of telling you, "Hey, people can see how you voted on the fediverse," and that's preferable to pretending that nobody can see them.
That just drives me to use instances that dont federate with instances who show that information.
Like. Lets apply that logic elsewhere. I could make an instance that makes your ip address public, because that information is also available. Could stick it next to your username.
Would you use that service? Or do you prefer using an instance who keeps the information they can access private?
Obviously, if my instance was sending my IP address off to other instances, I would get off that instance. However, downvotes are different situation. To my knowledge, for votes to work and be somewhat reliable, instances need to have a user attached to each vote. It would be very problematic if an instance was sending userless votes and other instances were just accepting them without issue. Nothing about the fediverse requires sending my IP off to other instances, whereas votes need to have corresponding users to be trustworthy.
Yes, thank you, obviously my exaggerated example to highlight the point was exaggerated. But you get my point, yes?
E: here, since you responded my just describing the function of how votes work. Lets try a different example.
Servers can track what posts you look at. That is something they can do, and many websites do. Would you be pleased to have every single post you viewed listed on your profile?
Kinda? Your example wasn't really an exaggeration of the situation with downvotes but a different situation entirely, so it didn't really address my point. Again, as long as there are downvotes on the fediverse, the people behind them will be visible to anyone who wants to know just by looking at an instance that shows them. Thus, being on an instance that doesn't show who you downvoted doesn't make your downvotes more private than if you were on an instance that did.
I 100% get being worried about people seeing who you downvoted, but in that case, I'd suggest being on an instance that just doesn't have downvotes. Those exist, and I've seen plenty of people who prefer things that way.
Not having downvotes at all makes the exact reason I dont like kbin even worse. A lack of downvotes is, in part, what made facebook so vividly toxic and rife with hate speech and fake news. When a site lacks upper moderation and a method of inter-community moderation, there is no way to filter out bad content and bad users.
Removing downvotes is something wanted by people who dont want content filtered. Showing downvotes is something wanted by people who want to weaken filters. Weak or nonexistent filters is what allows the worst aspects of the internet to fester and rot.
I did literally say I am drawn towards instances that would refuse to federate with privacy free instances, which includes the ones that make votes public. In the exact same way I would not want federation with instances that make your ip or view history public.
Understandable. I don't view showing downvotes as weakening filters—I see how it could deter downvoting to some extent, but in my experience, it leads to people handing out downvotes less freely and when it's more justified as opposed to not downvoting at all. Nevertheless, I see where you're coming from, and I want to stress that I think it's completely fair to not want people to see if you've downvoted them.
Note: I don't think defederating from an instance prevents them from seeing your content (according to this thread), so I'm not sure if defederation would make your votes private.
Back in the day facebook only had a like button and people demanded a dislike button. I don't know what facebook thought internally.
I think what kbin really needs is reasons. (like slashdot - though I havne't been there in 20 years so I don't know what is current). Upvote because it is funny is different from upvote because it is insightful (I may want to filter on that). Downvote because it is SPAM vs downvote because it is insightful on how someone who is wrong thinks (which probably should count as an upvote) Of couscous I don't know what the fedration protocol allows.
At the moment I personally am a fan of the limited downvote federation because I do think it acts as a hivemind barrier;
I think it's a lot less straightforward than this. While it definitely drowns out the "hivemind" of the wider fediverse, it also creates a bubble within your own instance. If a lot of people outside of your instance think you made a bad comment but few inside your instance do, limited downvote federation creates an inaccurate representation of what people think.
Additionally, having downvotes but limiting their federation makes them extremely unintuitive and only serves to further confuse new users. It's actively misleading—you'd think that if you see 0 downvotes that nobody clicked the downvote button, but that might actually be 5 people or 10 people or 30 people. At least if you don't have a downvote counter at all, it's clear that downvote functionality just isn't recognized on the instance. I'd much prefer that over a straight up incorrect counter.
Overall though, I think the problem is how the downvote was used (on Reddit, at least) was not conducive to discussion.
I agree that there's a big problem with how downvotes are used. I personally use downvotes if something is:
spam
straight up hateful
completely off-topic
a nonsensical take that the poster doesn't support
In other words, if something isn't a reasonable contribution to the discussion, I'll likely downvote it.
However, lots of people seem to use the downvote button as a disagree button. I see this less on kbin.social than I do on other instances, and that could be a potential reason to not federate downvotes. If downvotes are used differently on kbin.social than on other instances, then I can see it making sense to not lump them all together. However, that only makes sense if people on kbin.social aren't using the downvote button as a disagree button (which they are, just less so than on other instances). And even still, there's the problem of an unfederated downvote counter still being misleading.
Rambling aside, I see three ways of handling this:
Remove the downvote button entirely.
Remove the downvote button, but replace it with reactions that people can use ("This is spam," "This is hateful", "This doesn't contribute to the discussion," etc.). If other instances adopt this set of reactions, reactions from those instances could federate.
Keep the downvote button and federate downvotes.
I don't like #1 very much because then you don't have a great way of indicating spam, hateful posts, unhelpful comments, etc. outside of reports that only moderators can see. #2 seems really nice, though both it and #1 come with the downside of filtering out negative feedback from instances with downvotes. #3 is also good, though it comes with the problems of downvote misuse.
Might be interesting to have per-instance weighted voting. So local votes would count as 1x, votes from other instances could count as 0.5x, and votes from that one instance that has a lot of vote brigading would count as 0x. Would be useful for smaller, specialized instances that tend to get harassed by outsiders.
Like you mentioned, that could be interesting for specialized instances used by a small group of people, but that wouldn't work for any general instance due to the vote counters being really unintuitive. If an instance were to do that, I imagine they'd also want to have something you can click that shows how many votes were local, how many were from other instances, how many were blocked, etc.
I imagine they'd also want to have something you can click that shows how many votes were local, how many were from other instances, how many were blocked, etc.
Actually, that would be really cool and worth doing regardless. Have a voting statistics view for each post where upvotes and downvotes are broken down per instance, and maybe by other criteria too. @ernest
Come to think of it, I think downvotes should become a message to the mod - either delete this unacceptable content, or remove the downvote. I'm not sure what the logistics of that are though - I'd be shocked if there are not serious unintended consequences of that.
If you want to get the mods to take something down, that's what the report button is for. Downvotes shouldn't also play that role, especially if they stay as downvotes. That down arrow is inevitably going to be used by a lot of people to express mere disagreement.
I don't want downvote for disagreement. Learn to debate a point and then leave it. Downvote for disagreement just discourages people from holding forth on complex unpopular positions ,even if they are correct. Of course it is most abused in politics where we can't objectively give a correct answer, but elsewhere i've seen real experts downvoted when they point out the popular narrative doesn't fit the facts.
If a lot of people outside of your instance think you made a bad comment but few inside your instance do, limited downvote federation creates an inaccurate representation of what people think.
But we're cooler than anyone else. :P
It's much more important to me to know what kbin thinks about my comment, than it is to know what the aggregate of kbin+hexbear or kbin+lemmy.world thinks.
And if you do want to know you just hit view on original instance and see all the votes.
That's not really a culture I want to be fostered here on kbin.social. Kbin instances are part of the wider fediverse, and there's nothing about someone on kbin.social that makes their vote more important than someone else's vote. If Kbin had a reaction system (like I mentioned in another comment) instead of downvotes, then not federating downvotes would make more sense, as specific "this is spam" or "this doesn't contribute to the discussion" reactions are more useful than just a down arrow. But the system we have right now is extremely unintuitive to new users and promotes a culture of "Eh, downvotes from people on other instances don't really matter. What's important is what people who are arbitrarily on my instance think."
If you really want to know which votes are local and which ones aren't, it'd be much better to either
have an indicator next to each user in the activity tab showing whether they're local or not, like what KES does with threads & comments, or
have something you can click that lists the numbers of local votes and remote votes separately.
I don't think instance membership is all that arbitrary. I'm on kbin.social not hexbear or beehaw or lemmy.world for good reason, and it's not only because kbin is technically better.
It definitely is to some extent, and voting culture isn't a huge part of why people go to kbin.social. Kbin.social is the main Kbin instance. If someone prefers the Kbin's UI to Lemmy's or wants to have microblog support, many will just default to kbin.social. I came here because I thought Lemmy looked ugly and Kbin looked really nice.
When you're introducing the fediverse to people, a lot of people are just going to go to the default instance, and it's honestly good advice to tell people to just do that to start out (lest they turn away from the fediverse entirely due to not being able to make a choice). Voting culture has nothing to do with that. Just because someone's on lemmy.world doesn't mean their downvotes are worth less than ours, and just because someone's on kbin.social doesn't mean they don't just hand out downvotes in order to disagree.
Right now, the fediverse is pretty small and Kbin is actually the most welcoming instance I have found so far. I am not sure if the lack of downvote federation has anything to do with this, but so far I actually like it.
Me too. I'm with you on this, I find our current voting culture way better and more welcoming than most of the lemmys.
But while I've also gone back and forth on the question, I've basically settled on the view that public downvoting encourages _responsible _downvoting, and the risks associated with downvotes being public are exaggerated given how much else of one's activity is public anyway.
(B) similar expressions from other instances aren't drowned out.
Some other instances are so much bigger than ours though. The "drowning out" will likely come the other way.
I don't have time to go through and find it right now but somewhere in my comments is screenshots of the difference in voting patterns on a comment thread (it happened to be one where someone was saying kbin is mostly trolls, so it was polarizing).
Kbin had voted in a completely different way to the lemmy, but because they were so much bigger than us, the aggregate would have looked like lemmy was the consensus.
Part of the appeal of an instance for me is its culture. It's hard to develop that when we risk being drowned out.
Well how does it work at the moment? I have the feeling that downvotes from some instances were synchronized in the past while others are not. Is it really that absolutely NO downvotes are synchronized at the moment from kbin?
We on kbin have not developed a knee-jerk "downvote everything I disagree with" behaviour that reddit had and lemmy.world is starting to have.
I think this is because we can see each other's downvotes and so we use them more responsibly. People from other instances don't have that so they behave differently.
Downvote-to-disagree has an offputting effect on discussion and creates echo chambers.
Not federating downvotes from much bigger instances allows us to develop our own culture here on kbin without it being buried in an avalanche from elsewhere.
Brigading from places like hexbear doesn't really affect us.
I'd prefer that kbin communities continue to develop based on the ethos of the people here, rather than potentially having our upvotes cancelled out by downvotes from a larger instance.
I responded in another comment of yours, but I'll also respond here for the sake of visibility.
We on kbin have not developed a knee-jerk "downvote everything I disagree with" behaviour that reddit had and lemmy.world is starting to have.
I completely agree with this. From what I can tell, public voting has made people on kbin.social much more reserved with their downvotes — tending to only use them for spam, hate, off-topic, or noncontributory posts and less for just disagreement — without having the risks that come with a complete lack of downvotes (i.e., not having a quick way to give negative feedback on posts that are off-topic, noncontributory, etc.).
Not federating downvotes from much bigger instances allows us to develop our own culture here on kbin without it being buried in an avalanche from elsewhere.
This is a good point, but there are a lot of issues with not federating downvotes. Yes, not federating downvotes DOES help to emphasize the downvoting culture on kbin.social, but it also means that the downvote counter is misleading and unintuitive. New users would reasonably think that, like the upvote counter, the downvote counter represents anyone who's downvoted your post (outside of people on defederated instances). Having downvotes act like they do right now makes kbin.social less approachable and more confusing to new users.
Also, as long as we're using the same system as other instances, I don't want to push the idea that negative feedback from other instances doesn't matter. A downvote is ultimately a downvote, whether it's from kbin.social, another Kbin instance, or a Lemmy instance. The last thing I want is for the main Kbin instance — the one to which many will default — to have an exclusionary culture.
If we don't federate downvotes, I think we'd be better off just ditching downvotes entirely and instead having something more conducive to how we want instant negative feedback to be used. As I've mentioned in other comments in this thread, it'd be great to have a set of reactions people can use. "This is spam," "This is hateful," "This is off-topic", "This doesn't meaningfully contribute to the discussion," etc. would be a much better system for promoting the voting culture we want here on kbin.social. And if other instances adopt such a system, we could federate those reactions with them as well.
If we don't federate downvotes, I think we'd be better off just ditching downvotes entirely and instead having something more conducive to how we want instant negative feedback to be used.
Out of curiosity, how would the current system be preferable to specific reactions? The whole idea of "we should only count downvotes on our instance" only makes sense if everyone on our instance is using downvotes in a more reserved manner, which isn't the case for everyone. Different people on kbin.social use the downvote button in different ways, and that'll be even more so as the instance grows. If we really want to preserve this voting culture we have, wouldn't it be better in every way to replace downvotes with reactions specific to how we'd want downvotes to be used?
@ThatOneKirbyMain2568 like I said, it's my second preference.
If you're asking why it's not my first choice, the answer's partly that I'm happy with the status quo for reasons I've already gone into, and partly pragmatism.
@ernest has a really long to-do list and figuring out how to implement it in a way that wouldn't undermine the report button or do something crazy e.g to reputation is probably not the best use of his time right now.
Definitely agree that Ernest has a ton to do and implementing a whole new system shouldn't rlly be the top of his priority list. If it's too impractical, I'd prefer that downvotes just federate instead of the unintuitive system we currently have, but I've already discussed that at length.
Indeed, and then there is a whole raft of searching, sorting and filtering options for Microblog posts (aka Toots) which kbin does, and which Lemmy can't even see.
This is one of the biggest issues and barriers to discoverability with the Fediverse in my opinion.
As I understand it, unless an instance has already subscribed to a community (magazine in kbin parlance), then in order to make that community (magazine) appear in your own instance, you need to:
First search for the community (including the community's home instance) name in the magazine search function.
The search will come up blank, but the act of searching for it will trigger a backend request for your instance to start federating content from that community. However there's no message to tell you that it's doing that. It just looks like that community doesn't exist.
Further, it may take up to several days (in my experience) for federation to start, ie, you have to repeat the search for the community and only then can you subscribe to (follow) that community
And when it does start, it only starts grabbing new content. So first it looks like the community doesn't exist, then it takes a long time for content to appear, and then it looks like the community is sparsely populated unless you go back to the community's home instance, rather than staying in your own instance, to catch up on old content.
Further pinned posts aren't federated (at least between lemmy and kbin I believe), so you can't even rely on a "here's what you need to know" introductory post to orient new members.
Contrast this to reddit, where (because it's a centralised system) searching for a subreddit produces immediate results, you can join a subreddit immediately, and you can immediately see all current and past content for that subreddit. Much more intuitive and useful to users.
Unfortunately the activitypub protocol that underlies lemmy and kbin doesn't appear to have been designed for reddit-like communities in mind. Ie communities that tend to feature long-form content, posted relatively sporadically, and where having access to the community's archive is very useful to members. It works somewhat better for twitter-like communities where it's easier to jump in "mid-stream" and - because posts tend to be only a few words long - you're more likely to start seeing new content after only a short delay.
I wish that this is something that's addressed at the Fediverse level.
there actually is a way to "backfill" content, being the outbox. (although it was not meant to be used this way, from what i can see from reading what little documentation is out there)
lemmy uses it to federate about 10 or so (i think it was?) of the latest posts, and most microblog implementations use to federate the "pinned" posts of an account
activitypub has quite a lot of quirks, both spec-wise and implementation wise, and there are many reasons including an apparent near civil war inside the working group which resulted in this messy state it's ended up in
honestly the fact that this protocol works at all is a miracle
@Doll_Tow_Jet@kbin.social I don't know if that's the official word for it but I'm using "backfilling" to refer to loading the history of a person or group after first federating with it.
the outbox is a special collection (list in activitypub speak) that's intended to work kinda like an old school email outbox where you put messages to be delivered and it would deliver them to the inboxes of people (and servers that were offline at that time would later pull them in from the outbox)
or, well, that's what the spec says. nobody uses it like that in reality because activity pub was intended for a completely different kind of social media than how it ended up being used (it seems to expect more "everything apps", including an entire client api that would completely abstract away the instance into nothing more than a dumb pipe for activities unlike the current reality where instance software dictate what you can do)
this probably confused you even more but it's getting pretty late here so I can't words good, sorry!
i update kbin.run to stay in sync with the most recent commit to the dev branch on a regular basis, although the update frequency is much lower now compared to 4 months ago... it's a "bare metal" install (no docker), so i made a very simple shell script to update it. half the time no one notices until they refresh the page or get inadvertently logged out due to a backend cache getting cleared. you're welcome to try it out if you'd like.
kbin.social
Hot