Trust and safety considerations section

[evanp]

From 2026-05-01 CG meeting, @ThisIsMissEm recommends adding a section to the ActivityPub document that mentions trust and safety. "Social software has social consequences".

[evanp]

We think there may be a related issue, in which case this one should be closed.

[ThisIsMissEm]

A specific part of this is that this section should be informative and appear early in the standard document, perhaps between Section 1 & 2, or as part of Section 1. We want to frame that this specification is used for building social software, and therefore it has social impacts which means it implicitly has trust and safety considerations.

We discussed in the meeting that the section should be labeled as "Informative" instead of "Non-normative", even though those two terms specification wise mean the same thing, trust and safety should be a normal practice, and normative gives the wrong vibes.

(I couldn't find an existing issue)

[evanp]

I think it makes more sense to be part of the appendices, or specific sub-sections of security considerations.

[DeadSuperHero]

As someone who is a potential prospective developer of ActivityPub applications, I think the highlighting of Trust and Safety considerations ought to be front-and-center. There are a myriad of reasons why, but I think it might help to look at some case studies where this has not gone well:

• Bridgy Fed
• Content Nation
• Lemmy
• Maven
• FediOnFire

There are also plenty of stories about new developers being harassed and driven off the network for trying to build things like search engines, because they couldn't find resources on what user expectations were for this kind of thing.

I co-authored a guide a while back about setting user expectations regarding privacy and consent, but resources like this are at best a band-aid. They need to be top-level information to set developer expectations, with guiding principles on how to build for this network. The stakes of developing services and applications in a social sphere are huge.