After reviewing FEP-5624: Per-object reply control policies and GoToSocial's interaction policy spec, I find myself leaning toward the latter for long-term considerations, though both have merit.

FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, #GoToSocial's approach seems to offer some architectural advantages:

1. The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny
2. Separating approval objects from interactions appears more secure against forgery
3. The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics
4. The extensible framework allows for handling diverse interaction types, not just replies

I wonder if creating an #FEP that extracts GoToSocial's interaction policy design into a standalone standard might be worthwhile. It could potentially serve as a more comprehensive foundation for access control in #ActivityPub.

This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.

#FEP5624 #fedidev #fediverse #replycontrol #interactionpolicy

Coda: The growth of BlueSky, and the novel features it launches with, point to a need for a 2.0 version of ActivityPub. One that fleshes out and updates the protocol based on dev experiences in the first decade of active use, and intentions going forward.

Ideally an AP 2.0 would include a formal mechanism for protocol extensions. One that learns from the experiences of the FEP process.

#ActivityPub #AP #AP2 #FEP #BlueSky

On the #W3C #SocialCG a related issue. For a good bottom-up standardization process that guarantees an open and inclusive #ActivityPub related ecosystem, there should be good alignment with the #FEP Process.

https://github.com/swicg/general/issues/43

What should #FEP Process be about? #ActivityPub et al? Or everything that vaguely represents #SocialWeb?

I took FEP codeberg chat to a #SocialHub thread that discusses how we can ensure and foster an open and grassroots ecosystem.

Imho the FEP Process should define its particular scope of protocols and technologies that are relevant, and that involves AS/AP and closely affiliated technologies.

FEP Process should NOT define what #Fediverse is. Leave that to Fedizens.

https://socialhub.activitypub.rocks/t/3-stage-standards-process-guaranteeing-an-open-and-decentralized-ecosystem/3602/42

#ActivityPub "The Good, the Bad and the Ugly" is a good article by @dominikDominik Chrástecký - Blog

https://chrastecky.dev/technology/activity-pub-the-good-the-bad-and-the-ugly

The two mentioned examples in "The Bad" are long-time issues that were also discussed at #SocialHub. I just responded to one of them on the forum..

The #Mastodon Update(Note) quirk. https://socialhub.activitypub.rocks/t/update-note-quirk/4545/14

The other one is around Direct Messages which are a hack (a Note with special sauce). #LitePub specifies ChatMessage object type here, which is the intended way to extend the protocol. #FEP

Progress on the FEP for Event objects

The FEP-8a8e (Fediverse Enhancement Proposal) had at lot of progress in the last months. In the meantime, the document has become somewhat more extensive than originally planned, but contains not only instructions for new features that have to be tediously implemented, but also a lot of advice and points that should provide orientation for developers of Fediverse applications that support events.

It now covers:

• Required attributes
• Events with Open End
• Timezone
• Physical and Virtual Locations
• Event status
• RSVP (Attendee Management)
• Event Banner and Poster Images
• Event Categories
• Discoverability
• Event Organizers
• Upcoming Events Collection for ActivityPub actors
• Term Definitions

Many thanks again to all reviewers and co-editors:

@lesionles @heiglandreasAlerta! Alerta! @naturzukunft @laurin

We warmly welcome further feedback from the communities of #Friendica, #Mobilizon, #Hubzilla, and other Fediverse platforms supporting events.
If you’re working on such an application or are part of these communities, your insights would be very valuable! @developers @mobilizon

#ActivityPub #Fediverse #FEP

How to subscribe to a thread?

Several days ago FEP-efda: Followable objects was published. I don't like this solution because ActivityPub spec only talks about "following" in the context of actors, and the proposed "proxy-following" mechanism forces us to change some well-established practices.

So here is an alternative: FEP-f06f: Object observers.

Object observer is an actor that can be followed to receive object updates. If conversation thread is a collection, its observer will broadcast Add and Remove activities that have thread collection as their target. Observer's followers will have an up-to-date view of the thread.

#ActivityPub #FEP

I've made some changes to FEP-521a: https://codeberg.org/fediverse/fep/pulls/482

- Many changes due to a rename of Controller Documents specification to Controlled Identifiers.
- Using https://www.w3.org/ns/cid/v1 context in example. I haven't tried it myself yet, but it works in JSON-LD playground.
- Key ID and actor ID are now recommended to have same origin.

#fep_521a #fep