Where do rules come from in online communities? This study investigates how and why online communities adopt and change their rules. We conducted a grounded theory-based analysis of 40 in-depth interviews with community leaders from subreddits, Fandom wikis, and Fediverse servers, and identified seven processes involved in the adoption of online community rules. Our findings reveal that, beyond operational reasons like regulating behavior and solving problems, rules are also adopted and changed for relational reasons, such as signaling or reinforcing community legitimacy and identity to other communities. While rule change was often prompted by challenges during community growth or decline, change also depended on volunteer leaders’ work capacity, the presence of member feedback mechanisms, and relational dynamics between leaders and members. Our findings extend prior theories from social computing and organizational research, illustrating how institutionalist and ecological explanations of the relational origins of rules complement operational accounts. Finally, we build on these explanations to offer a set of design propositions that reflect the relational aspects of rules and rulemaking across communities’ lifecycles.

…

Although leaders often adopt rules to regulate behavior and content, we find that this is only part of the story. Rules also reinforce a community’s distinctive identity within an online platform and establish a community’s legitimacy in broader networks. This insight complements and challenges prior operational accounts of the sources and purposes of rules in social computing work, from both social engineering and community governance perspectives, and reveals underappreciated relational aspects of rulemaking. Some of these relational aspects are external, such as when rules draw distinctions or signal alignments between communities. Others are internal, as when rules reinforce identity or consensus among a community’s leadership team or between leaders and regular members.

Both internal and external relationships are important in the processes of rulemaking; they draw attention to problems, help form solutions, and shape decisions about changing the rules. Our work also extends prior quantitative research in CSCW on changes in community rules [31, 74] by showing how leaders think about rule creation and change, as well as how different community platforms may shape rulemaking processes by constraining relations in different ways.

In the rest of our Discussion, we consider the implications of relational dynamics of rules in governance systems for online communities. We then reflect on how our findings inform theories of institutional design and change in online communities as well as directions for future research on community governance. Along the way, we highlight a set of design propositions that suggest future work—both system building as well as empirical evaluation—derived from a more relational understanding of online community rules. We present these as tentative propositions for future design and evaluation work to illustrate the applicability of our theoretical framework, rather than as definitively proven guidelines.

…

A prevailing assumption in prior scholarship is that rules formalize social norms that regulate interactions within communities [9, 16, 36, 56, 77]. Rules are treated as instruments for directing human interactions in computer-mediated environments. We find that, in addition to advancing this operational purpose, rules also serve relational purposes as leaders design rules with respect to other communities, leaders, and users.

First, rules set and sustain community boundaries, particularly to protect community identity amid evolving membership dynamics. The challenge of protecting identity is important—particularly for communities prone to influxes of new members who may alter the community’s composition or undermine its focus [60]. In response, communities discoverable on large platforms and open to broad participation often implement rules that restrict off-topic content. While prior work has suggested that rules contribute to identity formation [9, 28, 81], our findings show that communities may defend their identity over time by prescribing strict guidelines for participation, often through reference to related communities. We extend prior work by Hwang and Foote [44] and TeBlunthuis et al. [89] who emphasize the importance of membership size and niche audiences within ecosystems of interdependent communities. This relational use of rules helps explain the concept of “nested niches,” in which communities thrive through their embeddedness in a broader socio-informational ecosystem [44]. Rules may provide tools for drawing and maintaining boundaries between specialist and generalist spaces—especially on platforms, such as Reddit, where communities often emerge from one another and share overlapping members and topics [85, 86, 87].

…

A prevailing assumption in prior scholarship is that rules formalize social norms that regulate interactions within communities [9, 16, 36, 56, 77]. Rules are treated as instruments for directing human interactions in computer-mediated environments. We find that, in addition to advancing this operational purpose, rules also serve relational purposes as leaders design rules with respect to other communities, leaders, and users.

First, rules set and sustain community boundaries, particularly to protect community identity amid evolving membership dynamics. The challenge of protecting identity is important—particularly for communities prone to influxes of new members who may alter the community’s composition or undermine its focus [60]. In response, communities discoverable on large platforms and open to broad participation often implement rules that restrict off-topic content. While prior work has suggested that rules contribute to identity formation [9, 28, 81], our findings show that communities may defend their identity over time by prescribing strict guidelines for participation, often through reference to related communities. We extend prior work by Hwang and Foote [44] and TeBlunthuis et al. [89] who emphasize the importance of membership size and niche audiences within ecosystems of interdependent communities. This relational use of rules helps explain the concept of “nested niches,” in which communities thrive through their embeddedness in a broader socio-informational ecosystem [44]. Rules may provide tools for drawing and maintaining boundaries between specialist and generalist spaces—especially on platforms, such as Reddit, where communities often emerge from one another and share overlapping members and topics [85, 86, 87].

A pretty refreshing look at how communities form and establish boundaries, and it features the Fediverse too! I think what makes this a good fit for this community is that it is easy to flatten and invisibilize dynamics this paper captures beautifully and brings to the forefront.

In The Open Society and Its Enemies [53], philosopher Karl Popper introduces the “paradox of tolerance:” unlimited tolerance can undermine itself by allowing intolerance to flourish. This philosophical insight highlights an ongoing challenge for online communities: determining which behaviors to accept and which to reject to maintain inclusive and civil discourse.

Online communities operationalize this principle through content moderation, the process of shaping information exchange and user activity by deciding upon and filtering posted content according to established rules [30, 42, 68]. In centralized social media like Facebook [20] and Reddit [17], previous studies have examined content moderation practices at three levels: platform [17, 28, 55], community [33, 35, 60], and personal [20, 37]. However, these studies predominantly reflect centralized contexts, leaving significant gaps in understanding moderation within decentralized platforms, where even the very notion of a “platform” is contested.

Decentralized systems are built based on “protocols” that define standards for building interoperable digital infrastructure [49]. Consider, for example, Mastodon [4], a widely used open-source software implementation of the ActivityPub protocol [63]. Mastodon is a decentralized alternative to mainstream centralized social media platforms like X. With Mastodon, people can create or join independently operated servers commonly referred to as “instances” (e.g., mastodon.social, mstdn.party), which are part of the “Fediverse.”

The Fediverse refers to the network of thousands of such instances running Mastodon and other ActivityPub implementations. And the process of peering between instances to allow information exchange in the Fediverse is referred to as federation [9]. Instances can interact with one another through the ActivityPub protocol. However, each instance in the Fediverse is independently administered by a user or group who sets local rules and moderation policies, effectively functioning as a self-governed online community. This independence allows communities to reflect local values but also creates challenges around consistency and coordination across instances [9, 21, 32, 34, 56].

A key moderation mechanism available to Mastodon instances to moderate cross-instance interactions is community-level blocklists. This allows the moderators of an instance to block entire instances of users they believe are problematic [14, 19]. These decisions can completely shape the experience of their own users. For example, if the instance users reside in blocks or are blocked by the most popular instances, they would be cut from a broad swathe of content and interactions in the Fediverse.

Prior work has examined blocklists at the personal level — when individuals use them to block other individuals — on centralized platforms, noting their potential for collective action [26] as well as individuals’ contestation of harassment [37]. In comparison, decentralized systems enable community-level blocklists, which both constrain who makes blocking decisions (only the instance admins) and expand the scale of the decision’s impact (everyone in the instance). Prior work already highlights concerns about transparency [40] and democratic decision-making by communities in online spaces [57]. As social media systems like Mastodon become more widely adopted [46, 69], understanding blocklists in this context is crucial for improving content moderation in decentralized settings. However, despite their prominence, little is known about how Mastodon moderators currently manage these blocklists, what tools they use, and what additional support they need.

…

Summary of Results. We found that existing blocklists and tools differ substantially in their purposes, inclusion criteria, transparency, and accountability. Some prioritize broad consensus across instances, while others focus on severity-based or manual curation (RQ1). Through interviews, we identified how moderation styles shape the understanding and usage of blocklists. Different styles embody different trade-offs of how open, safe, and context-specific moderation should be (RQ2). Finally, we identify several avenues for improvement in the design of blocklist tools, including category filters, severity toggles, comment receipts, and collaborative moderation features (RQ3).

A sort of twin of the other paper I just posted about the Fediverse, but focused on blocklists rather than the process of making rules.

All of this is still so new (and kind of really old too) and that makes this kind of work super important. Definitely check this paper out!

⚠️ We recently released #PeerTube v8.3.1, which fixed several security issues. The full changelog is now available. If you haven’t done so already, please upgrade your platform as soon as possible!

SECURITY

• critical Fix potential XSS with remote storyboard in SVG format GHSA-jwcf-xj6w-xqm5
• high Do not allow moderators to act on 2FA/token sessions of other moderators/admins GHSA-xpw4-mxj2-rj8x
• moderate Prevent private video metadata leak GHSA-4hwq-4jr6-w3gg
• moderate Prevent ActivityPub DDOS GHSA-r8wm-f869-fpw3
• moderate Fix SSRF for webfinger, HTTP video import and JSON-LD context resolver GHSA-xgcr-r7cv-7xhv
• Security hardening

Bug fixes

• Force video encoding if there are rotation info
• Fix broken studio on only intro/outro/cut task
• Fix broken sorts/invalid sort checkers for channel syncs and ownership changes
• Fix downloading a download-protected video for admins
• Fix broken email title in some emails
• Fix broken notification window if the list contains a broken change ownership notification
• Fix table pagination after a search
• Include muted muted videos when admins/moderators display all videos of an account/channel

Today I merged many UI changes, mostly around how threads are viewed and navigated.

I took some of the good elements of Reddit, so now we have sorting by Old/New/Top (the default for the microblogging timelines is Old, and for forums it’s Top - both can change in settings) and a flexible replies section with collapsible/expandable branches.

Top-level posts now show the total number of replies under the whole thread, not just the direct/first level replies (but again you can change it back in Settings). I also saved much vertical space, so now you can read long threads with less scrolling.

If I may say so myself, I honestly believe it’s one of the best UIs on fedi, especially for reading conversations. I think that if anyone tried it, they would agree. Really, really happy with the results. It’s still fresh, so I will probably refine things here and there, but it’s pretty much exactly as I envisioned it.

Let us know what you think!

#catodon

This is a big one! Caught up with Misskey 2026.10.0, added ActivityPub C2S API support (we know there are not many clients, but we want to do our part for standardization in the Fediverse), added post languages and language filters, replaced Redis with Valkey and many more…

Read the release notes for a full list of everything we did this month!

Here is a lenghty part of the changelog, click on the link for the full version

The project is now a Misskey fork

• Dependencies brought up to current Misskey. Backend dependencies were brought up to the versions Misskey runs in one sweep, including the AWS S3 client
• Many Misskey features merged since the last Sharkey stable
• A Misskey server can move to Catodon directly
• The MFM parser was updated and patched to read emoji up to Unicode 17.0

Forum & Federation

• Forum discovery through the Threadiverse Catalog.
• A Lemmy-compatible API that lists this server’s public forums (/api/v3/community/list, /api/v3/community, /api/v3/site)
• Cross-posting in forums. A topic posted to several forums is published once and cross-posted to the rest
• Blocking a server, as its own thing beside the server mute. It removes the follows in both directions
• An ActivityPub client API (client-to-server), so ActivityPub apps can sign in and post, read, follow, react, upload and more.
• Reduced-relationship notices. When a moderator blocks a whole server, affected accounts are told which server and how many relationships in each direction it covered, served natively and as Mastodon’s severed_relationships

Mastodon

• Word mutes become Mastodon filters. /api/v1/filters and /api/v2/filters
  read and write the same filters the settings screen does

• Security and correctness ports from Misskey 2026.10.0

• Familiar followers (accounts/familiar_followers) and a native
  users/familiar-followers, with the privacy rules Mastodon applies.

• POST /api/v1/statuses/:id/translate, configuration.translation.enabled
  and /api/v1/instance/translation_languages, so Mastodon apps (Tusky, Moshidon, the official Android app) offer translation

• Bookmarks and blocked domains can be imported

• Lists can be exclusive over the API, matching the native “Hide from home timeline” switch.
• A post’s language is now reported and accepted
• Smaller parity fixes

Posts, timelines and media

• Like and repost counts that match the origin. Popular posts from Mastodon
  show the counts Mastodon states

• Trending links, server side. Mastodon-style link trends with moderator review

• “Also discussed in”. Posts sharing a link now list the other posts discussing it, forum topics first
• Watching a post or a thread, with its own notification type and grouped notifications for busy threads.

• A focal point on images, honoured by every crop the client makes and
  federated as Mastodon’s toot:focalPoint

• Language filtering for timelines, with a per-timeline Show all languages override, plus per-post languages and a language pill in the composer.

• Hot was reworked so likes and votes carry more weight against age, and no longer lets forum posts crowd out Home, Social, Media, Local and Global.
• Double-tap media to like straight from the Media timeline, in the grid and immersive layouts.
• Grid and immersive layouts for custom feed tabs, and an Options menu on list and custom feed tabs.
• Hide URL previews entirely, a device setting under Settings > Posts and reactions.
• A landing page setting deciding what signed-out visitors see at the root.
• RSS, Atom and JSON feeds for hashtags (/tags/:tag.rss, .atom, .json).

Moderation

• Freeze an account. stop it signing in or acting on any path, with its profile and posts left in place. Suspension is still what takes an account out of view.
• IP address and range blocking in Control Panel
• An email domain can be held for approval instead of refused outright.
• A role can require two-factor authentication, the base role included.
• Announcements can be sent by email to every eligible local account, in resumable background batches.

• Moderators are notified in-app when someone files a report or signs up, as
  Mastodon’s admin.report and admin.sign_up.

• Reports carry what the reporter chose : category, rules and attached
  posts…and can be forwarded anonymously.

• Database connection pool logging, so db.extra.max can be set from evidence rather than guessed.

​:catodon:​ #catodon

We Distribute is teaming up with Bonfire to develop a new kind of social instance - one that elevates curation and discovery to promote all things Fediverse. It’s a social instance, but also a discovery portal.

Fedizen is a collaborative effort between ourselves and the Bonfire team to build a new kind of Fediverse instance, one built specifically for the network and the communities growing around it. It combines ActivityPub federation with curated aggregation to create a network-wide community portal

In a nutshell, Fedizen is almost like a grassroots approach to building Yahoo, but designed specifically to serve the space. It’s an effort to collect all of the news coverage, community opinions, development blogs, events, and media, and put it into one place that’s easy to find, easy to filter, and adjusts based on what you’re most interested in within this space.

Our first blog post about Catodon’s new chapter - please repost/boost!

In defence of our choice to use LLMs

I know AI is a sensitive subject on fedi, and I understand the arguments against it. But here’s what it’s actually done for us: First of all, the project wouldn’t exist without it. But even now that we have a dev on the team, we’re keeping it in our workflow.

In six months, it’s helped us ship features that projects with several full-time devs would need years to build:

• forums with full Lemmy compatibility

• an RSS timeline

• federated blogs
• a dedicated Direct Messages page with a chat-like interface
• New/Hot/Active sorting for forums and microblogging timelines
• a WYSIWYG editor for Pages and Blogs
• native Mastodon API support
• multi-protocol login that lets you use Catodon as a client for your Mastodon, Pixelfed, or Misskey account too.

It also recently helped us catch a vulnerability in upstream Misskey, which we reported and which has now been patched - meaning every Misskey fork will benefit.

We’ve also used it to spot 13 Misskey security patches that hadn’t been merged into Sharkey yet, which we flagged to the Sharkey team as well.

And to be clear, AI isn’t magic - we spend hours of real work on every feature, and everything is tested and reviewed before it ships. We also keep a close eye on Misskey and Sharkey upstream, so we can pull in security patches as soon as they land.

We’re not going to pretend this settles the debate about AI, and we don’t expect it to. More and more projects (including the Linux kernel) are utilizing LLMs - and there are actual, valid reasons for this. All we can do is keep being transparent about how we use these tools, and let our work speak for itself.