#fep

9 posts · Last used 7d

Back to Timeline
Boosted by fedicat @fedicat@pc.cafe
silverpill
@silverpill@mitra.social · Jun 11, 2026
FEP-5219: Groups and permissions has been added to the FEP repository. #fep #fep_5219 RE: https://mitra.social/objects/019e87e9-62a6-71d1-8edc-3a8a63e96c9f
0
0
1
Boosted by fedicat @fedicat@pc.cafe
silverpill
@silverpill@mitra.social · Jun 04, 2026
FEP-f228: Backfilling conversations has been updated: https://codeberg.org/fediverse/fep/pulls/853 I added tootik and Lemmy to the implementation list and did a little cleanup. This FEP feels complete, so I am requesting final comments. Full text: https://fediverse.codeberg.page/fep/fep/f228/ #fep_f228 #fep #fedidev
0
0
1
julian
@julian@activitypub.space · May 22, 2026

FEP-baf5: Administrator Collection

<p>This is the discussion thread for the draft FEP-baf5: Administrator Collection</p> <blockquote> <p>This FEP introduces a mechanism for discovering the administrators of an ActivityPub instance. It extends the "Group Moderator" pattern from [FEP 1b12][1b12] and the "Application Actor" concept from [FEP 2677][2677] by defining an <code>OrderedCollection</code> of administrators referenced from the instance's application actor.</p> </blockquote> <p><a href="https://codeberg.org/devnull/feps/src/branch/instance-admins/fep/baf5/fep-baf5.md" rel="nofollow ugc">The full draft can be read here</a>.</p> Hover or focus to reveal Sensitive
This is the discussion thread for the draft FEP-baf5: Administrator Collection This FEP introduces a mechanism for discovering the administrators of an ActivityPub instance. It extends the "Group Moderator" pattern from [FEP 1b12][1b12] and the "Application Actor" concept from [FEP 2677][2677] by defining an OrderedCollection of administrators referenced from the instance's application actor. The full draft can be read here.
0
9
0
julian
@julian@activitypub.space · May 20, 2026

Question re: Origin Based Security Model (FEP-fe34)

<p>I received a security vulnerability report regarding NodeBB's handling of <code>Update</code> and <code>Delete</code> activities.</p> <p><strong>tl;dr</strong></p> <ul> <li>NodeBB implementes FEP fe34, and treats <code>Update</code> and <code>Delete</code> activities as valid if the activity's <code>actor</code> and the object's <code>attributedTo</code> differ <strong>but the origins are identical</strong>.</li> <li>e.g. <code>@alice@example.org</code> is allowed to federate <code>Delete(Note)</code> on <code>@bob@example.org</code>'s <code>Note</code>.</li> <li>The origin-based security model allows for moderator-style actions (third-party post editing and deletions) in the absence of explicit moderator claims.</li> <li>The reporter disagrees that this should be allowed.</li> </ul> <p>Are they right? [...]</p> Hover or focus to reveal Sensitive

I received a security vulnerability report regarding NodeBB’s handling of Update and Delete activities.

tl;dr

NodeBB implementes FEP fe34, and treats Update and Delete activities as valid if the activity’s actor and the object’s attributedTo differ but the origins are identical. e.g. @alice@example.org is allowed to federate Delete(Note) on @bob@example.org’s Note. The origin-based security model allows for moderator-style actions (third-party post editing and deletions) in the absence of explicit moderator claims. The reporter disagrees that this should be allowed.

Are they right? […]

I responded that FEP fe34 allows for this behaviour because we do not have ready access to an instance’s admin or moderator list. By conducting same-origin checks and allowing Update and Delete through for same-origin (but different identifier), we allow for moderators to federate their actions across instances.

Their response:

I respectfully disagree that FEP-fe34 permits this behavior. Below are direct quotes from the specification that contradict your assessment.

ActivityPub spec (quoted in FEP-fe34 Rationale, Section 7.3 Update Activity):

▎ “The receiving server MUST take care to be sure that the Update is authorized to modify its object. At minimum, this may be done by ensuring that the Update and its object are of same origin.”

Note: “at minimum” means same-origin is the floor, not the ceiling. Authorization must still be verified.

  1. FEP-fe34 — Authorization > Ownership:

▎ “The actor that creates an object MUST be its owner.”

▎ “The owner of an object is permitted to modify and delete it.”

▎ “Update and Delete activities, and objects indicated by their object property are expected to have the same owner.”

“Same owner” means the same specific actor — not any actor on the same domain.

I responded back with the following:

“The actor that creates an object MUST be its owner.”

Correct, the creator must be an owner, no impersonation allowed.

“The owner of an object is permitted to modify and delete it.”

A strict reading of this does not preclude the ability of a same-origin moderator to modify and delete the object. This is my argument.

“Update and Delete activities, and objects indicated by their object property are expected to have the same owner.”

Again, “expected to” does not rise to the level of MUST.

I agree out of principle that the security implications exist, but if you follow through with the exploit, it requires a non-compliant server to allow users to publish Update and Delete for other users on the same instance, and even then the exposure is limited to users of that origin only (e.g. your server cannot arbitrarily delete my posts). This is the foundation of the Origin-based security model.

So we are at an impasse as to whether my strict reading of the FEP is adherent to the spirit of the FEP itself. Here’s where you come in… do you agree with me, or the reporter?

Directly tagging @silverpill@mitra.social (as FEP author), @trwnh@mastodon.social and @evan@cosocial.ca (both subject matter experts) for their thoughts.

0
25
0
lauti
@lauti@bonfire.cafe · Apr 25, 2026
Hey @mariusor@metalhead.club, we are looking into your #Go #Activitypub library to implement federation in #LAUTI One thing we need to do is implement the #FEP 8a8e by @linos@graz.social Do you have time for a quick call to get an overview?
0
4
0
silverpill
@silverpill@mitra.social · Apr 25, 2026

FEP-8b32 (Object Integrity Proofs) is getting updated: https://codeberg.org/fediverse/fep/pulls/839

I added two new requirements:

  • Objects identified using fragment IDs SHOULD NOT have integrity proofs. It is enough to secure the top-level document.
  • Verifiers SHOULD ignore proofs that use unsupported algorithms and verification methods. This requirement provides forward compatibility, which is important because sooner or later we will need to use different algorithms.

#fep_8b32 #fep #fedidev

0
0
0
In reply to
smallcircles
@smallcircles@social.coop · Apr 13, 2026
cc @evan@cosocial.ca relating to earlier #TagsPub discussion we had on the matter. This bot is already combining logic, has multiple 'profle logic' tags. Dunno if "NoBots" is also already common protocol-decaying practice. Maybe a solution might be that an #ActivityPub bot actor - OT: which I'd personally perhaps had chosen to be Application, not Service actors - would have a botFlags property. Simple to implement, and #FEP that. More involved but also much more versatile might be a "Botiquette" as:Profile, or even a bots:Botiquette type, and a namespace to register them at, and where others may find what they mean and how they operate exactly. #NoBots #nobot #fedi22 #NoTagsPub #Botiquette
4
22
0
Profpatsch
@Profpatsch@mastodon.xyz · Apr 10, 2026
Arnold Schrijver (@smallcircles@social.coop) just published a fairly long thinkpiece on the future of ActivityPub and the fediverse and how we could achieve a grassroots improvement of the standards. It's well worth a read! https://coding.social/blog/grassroots-evolution/#fediverse-tomorrow #activitypub #fediverse #FEPs #fep #fedidev
11
2
14
silverpill
@silverpill@mitra.social · Mar 07, 2026
FEP website now displays the number of implementations for each implementable proposal: https://fediverse.codeberg.page/fep/final/ These numbers are based on the information that authors provide in the "Implementations" section of a proposal. By default, proposals are informational, so authors need to opt in by adding type: implementation to the metadata block. #fep #fedidev
0
0
0

You've seen all posts