Consensus
Wed 8 Oct 2025 1:15AM

Revising the Node requirements list

AB Alyaza Birze Public Seen by 12

currently the Node Requirements we ask would-be node operators to conform to are listed on Infortmation as follows:

Node Requirements

These are the requirements for a Node to be added to the Website League. Fulfillment of these requirements must be verified before the node can be added to any allowlists. 

  1. The Node must adhere to the Website League Code of Conduct The rights and responsibilities of users and node staff is laid out in detail in the code of conduct. A node's individual Code of Conduct may be more restrictive than the Website League's, but it may not be less restrictive.

  2. The Website League Code of Conduct must be accessible from your instance's about page, Terms of Service page, or similar. 

  3. The node must require approval for new members. Nodes may use an invite-only or open registration scheme, but all new members must be approved by a moderator before they can join. 

  4. All federated timelines must be disabled. Federated timelines encourage conflict-seeking behavior, which the League seeks to minimize. They also create a vector for potential harassment. 

  5. Numbers that encourage dark patterns must be disabled. This includes like and boost counts, follower counts, and similar stats. 

  6. The node must run on allowlist (or whitelist) mode, and must only federate with members of the Website League. The Website League is a closed network. Nodes that federate with the wider fediverse are not permitted. 

  7. The node must have Authorized Fetch enabled. Authorized Fetch essentially ensures that only allowlisted nodes can retrieve posts and timelines from your node. Here's a longer explanation of what it does (Mastodon docs).

however, i am pretty sure at least some of this no longer conforms to our applied practice; and separately, it is probably a good idea to review the year-old wording we have here to ensure it's as unambiguous as possible for would-be node operators.

i'd also like any revisions, notes, and changes we make to these to be in a better format to scrounge up format than instant messages, so this is a thread to do all of that in going forward.

AB

Alyaza Birze Wed 8 Oct 2025 1:26AM

my quick suggestion off the bat here, and part of what prompted this, would be we revise requirement 5

Numbers that encourage dark patterns must be disabled. This includes like and boost counts, follower counts, and similar stats. 

to align in wording with how we talk about this on the FAQ page for the League (both the old and new website). that would mean it reads more like:

[Nodes must,] to the greatest extent technically possible, disable any visibility of post metrics, the federated timeline, and the ability for users to access each others' lists of following and followed users.

we should also probably and explicitly link to our League-specific forks of GTS and Akkoma here so people don't think they have to patch this stuff out themselves

R

ruby Wed 8 Oct 2025 2:18AM

@alyazabirze fwiw our akkoma tree does have metrics entirely patched out, so the relevant config options should always be enabled there. unsure what the gotosocial situation looks like

WS

wenchcoat system Wed 8 Oct 2025 1:28AM

ha! rule #2 can't get me if I don't have any such page! 😒 (I remember it being added after mellivora was live, damn that's a dusty to-do...)

afaik I'm fine on the rest? local-only feeds were discussed in advance of #4 being codified, and it's worded to allow them. not 100% sure on #7, but this would have come up before and didn't register as a snag so it's probably default on Akkoma?

no personal gripes with any of these, curious whether they actually deviate from practice for anyone else.

KL

Kit Lotor Wed 8 Oct 2025 2:23AM

I think 4 and 5 are the two I could imagine taking a closer look at. The rest feel solid; 1 and 2 are kinda obvious, there's too much of a spam problem with fediverse software for me to feel comfortable relaxing 3, and 6 and 7 are basically essential for this to function as an island network.

I like the rephrasing of 5. For 4, I'm mainly thinking about the local timeline thing. I think as long as nodes don't become too huge, local feeds are alright, but it should be re-evaluated in the event node(s) end up with a large enough active user count for the local timeline to feel less like a community and more like a firehose.

R

ruby Wed 8 Oct 2025 2:47AM

@kitlotor i'd counter the size thing with membership limits. i know i intend to close registrations on posting once we hit 50 members - i feel like it'd be wise to encourage other nodes to set similar caps

KL

Kit Lotor Wed 8 Oct 2025 3:12AM

@ruby This can work, but I worry a little about a potential future scenario where all nodes have their member caps reached, or at least enough nodes reach their caps that trying to join the weblyg becomes frustrating.

This may ultimately be okay if we want there to be a limit to the number of users we want on the league in total - but if not and we're relying on something like more people spinning up their own multi-user nodes, this may become a problem in the long term if we can't find enough people with the time, know-how, and interest to do that.