Skip Navigation
Remote View
hexbear @hexbear.net
CARCOSA [mirror/your pronouns] @hexbear.net

How should Hexbear federate?

I wanted to open up a post to discuss the two main methods of federation: allow-list and block-list. As well as see how the majority of users felt with regard to the methods.

Due to some of the issues raised with the method of vote counting this will be considered only a check of user sentiment, not a promise of what to do

I will pin two comments, one in favour of a block-list and one in favour of an allow-list approach to federation.

Before the domain issue we were using an allow-list, this means that any instance that wants to be linked to hexbear must reach out to us or be nominated by a user for addition to the allow-list.

The benefits of this is that we are not automatically linked with any instance that spins up. The downside is that we miss federation with any small lemmy instance as well as with any other activity-pub instance (mastodon, peertube, etc.)

Lemmy.ml and lemmygrad.ml both use a block-list approach and for what it's worth they have done well, the majority of reactionary instances already block us (lemmy.world, sh.itjust.works, lemmy.ca, sopuli.xyz, slrpnk.net) and the pedo/porn/nazi instance are already on the hexbear block-list.

The biggest upside of a block-list approach is that new single person instances that get created will link up with us without any extra steps, and the biggest downside is that it will add an extra step for moderation (adding a new shitty instance to the block-list after they show their shit)

Within the following spoiler will be the hexbear allow-list and block-list.

Discussion may be had within comments, if you have specific instance additions/subtractions from the allow-list or block-list please comment underneath the respective pinned comment.

For example if you wish to add lemmy.ca to the block list comment under https://hexbear.net/comment/5951093

172 comments
    • first we need to need to form gangs of 3-5 power posters that infiltrate the other instances to prepare the ground.
    • we need to spend the next Month to post subtile Agitation.. and Peripheral Videos of the non Western world (like cooking, Driving around , non english music- to reduce contact fears ). The Sleeper could even have a conversation going about "missing" the Hexbears...
    • The Sleeper then should "Warn" their instances of Hexbears expected return .. and demand that more Mods are need to deal with the consequences & offer themselfs..
    • When hexbear refederates , the Sleepermods will coup the Instances . So the gates can not be closed in time.
    • then with refederation bomb all comentsections with our Emotjies , theirby establising a New Hegemonic Hexbear Posting Meta.

  • Why the actual fuck are we even voting on shit that would never have been up for debate if this mistake never happened?

    I do not know why you want to give the community every single opportunity to generate unhappiness that is just completely and totally fucking needless.

    Worse still, changing to this method of voting completely prevents anyone except site admins from looking for people using multiple accounts to manipulate a vote.

    Genuinely can't fucking believe this is even up for debate... Again. Why is it being relitigated? It was a settled issue and now it's going to make everyone against the result angry as fuck?

    EDIT: Yeah I could word this less sweary but still.

    • Because we haven't done a site wide check in about federation approaches since we started with an allow-list.

      • Timing though Carcosa! Get the existing drama out of the way and let people have a few before starting a new one!

    • Same.ien 100% same. The site tore itself apart a few months ago over internal conflict over post content in a wave of brutal struggle sessions. Going from that to even considering re-federation with a blocklist seems like an extremely poor choice. We can all look at the recent past, and the first attempt at federation, and know that if we have a blocklist it's going to lead to a series of rolling disasters that will further divide the site and erode trust. Let's just quietly delete this and if we're going to federate at all federate very carefully with a small number of vetted instances.

      • I supported Block List originally and still do and just think this is a poor approach. I would have liked a month off from dramas once Hexbear is all fixed again. If there's an ongoing question about Federation it should be an annual consideration brought forwards at New Year. "New Year new Hexbear what do you want this year?" sort of thing.

        I actually think Block List is best for the site's health, it provides some growth sources and it provides more activity for those on Hexbear that want to roam. There are undoubtedly new users who will find leftism through it. But I still think seeding another drama on the back of a confusing "we're losing the domain" drama is just back to back stuff.

    • This whole thing is unwarranted. Things need to revert back to the pre-domain name kerfuffle status quo.

      This is reminding me of how various admins kept pushing for the mega portal even though most people thought it would suck. The mega portal was eventually pushed out under a trial run during the domain name kerfuffle, and it sucked exactly the way people thought it would. It's pretty obvious that some admin (not necessarily Carcosa since Carcosa is more like the PR rep of the admins) was overly attached to the idea and used the domain name kerfuffle as an opportunity to push out their pet project even though everyone else, including other admins I would imagine, thought the idea was complete ass. Pretty disingenuous.

  • I would rather block problematic instances when they become an issue. Tolerance does not have to be high. I think growing Lemmy as a whole is a good pursuit, even if we have to shit pile morons in the process. Plus it means we get to spread that unique Hexbear stank more farrer and more widerer. Mmmmmmmm.

    Edit: On further consideration, I do realize it jeapordizes the safety of our tovarischi here, which I am not okay with. While I don't like being insular, I recognize that the safety of my comrades is far more important. I am withdrawing my vote.

  • I think something being ignored about the benefits of a block list is the opportunity to educate and/or radicalize people instead of just dunking on them.

  • RETVRN

    • gotta be real here, public emote votes have their own problems and it's good that we're experimenting but imo we should scrap this poll and redo it with the tried and true method, because this is worse imo. the vote should be immediately accessible and there shouldn't be opportunities for individuals to sway the count other than arguing for or against options. in this case, there's an active incentive to bury the ballot itself if you like the top option more, essentially an in-built suppressive apparatus

      • Also liking the general experimentation idea but not sure this method is the way forward.

        If you want to have it by upvotes there should be NO COMMENTS allowed under the relevant pinned comments. So at least they will appear mostly equitably.

        I don't particularly like the secret ballot aspect of this method. I don't know that there were any complaints about votes being public.

        I do like that I can vote for multiple options. In this case there are only 2 choices so voting for both is very similar to voting for neither but with more choices it could introduce some fun chaos.

        I feel that it is more of a straw-poll than a binding decision especially since there is no timeframe for when the "voting" will close and a conclusion reached.

      • I completely agree with this, we can just use the

        and
        again, this is more transparent.

  • Is there any way to obtain stats about demands on mods/admins? Such as number/type of reports, how much time/actions are taken and so on? And to know about the users who do the things requiring admin/mod attention.

    If yes, then it would be interesting to see the effects of any changes. E.g. if we switch methods and reports from other instances triple immediately then it would be cause to reconsider.

  • It's mentioned that a block list would require more moderation, as it would require adding new entries to the block list. But as of now, the suggested block/allow lists in the OP have the number of entries in the allow list vastly outnumbering those in the block list. I'm not sure that has been indicative of anything, but if it does reflect that there are much more instances we'd like to federate with than there are instances that we know we want to stay away from, going with a block list just seems to make more sense. Any instance that becomes problematic can be recognized and added to the block list, whereas the other way around, newer or smaller good instances would pass unseen, and would only be known to be added to the allow list if some users actively go out and find those instances themselves and recommend it to be added. That seems like more work than blocking an instance if it turns out to be problematic.

  • To summarize what happened in IT parlance, a major incident with a sitewide scope happened, temporary workarounds were implemented, and the root cause was determined. What should happen next is that the major incident gets revolved and the site goes back to what it was before the major incident.

    If a support ticket has been opened regarding Hexbear's domain name incident, then the support ticket can't be resolved until every temporary workaround has been undone, and among that temporary workaround is federation being turned off. It was turned off as a precaution, and now that the root cause was determined, it needs to be turned back on.

    Asking about how federation should look like is no longer a question about incident management, but a question about change management since the question is about potentially introducing new changes to the website. And as we all know, request for changes (RFCs) operate under different processes from incident resolution. It's change management vs incident management. These are two different processes.

172 comments