<p>After reviewing <a href="https://w3id.org/fep/5624" rel="nofollow">FEP-5624: Per-object reply control policies</a> and GoToSocial's <a href="https://docs.gotosocial.org/en/latest/federation/interaction_policy/" rel="nofollow">interaction policy</a> spec, I find myself leaning toward the latter for long-term considerations, though both have merit.</p><p>FEP-5624 is admirably focused and simpler to implement, which I appreciate. However, <a href="/tags/gotosocial/" rel="tag">#GoToSocial</a>'s approach seems to offer some architectural advantages:</p><p>The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/deny<br>Separating approval objects from interactions appears more secure against forgery<br>The explicit handling of edge cases (mentioned users, post authors) provides clearer semantics<br>The extensible framework allows for handling diverse interaction types, not just replies</p><p>I wonder if creating an <a href="/tags/fep/" rel="tag">#FEP</a> 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 <a href="/tags/activitypub/" rel="tag">#ActivityPub</a>.</p><p>This is merely my initial impression though. I'd be curious to hear other developers' perspectives on these approaches.</p><p><a href="/tags/fep5624/" rel="tag">#FEP5624</a> <a href="/tags/fedidev/" rel="tag">#fedidev</a> <a href="/tags/fediverse/" rel="tag">#fediverse</a> <a href="/tags/replycontrol/" rel="tag">#replycontrol</a> <a href="/tags/interactionpolicy/" rel="tag">#interactionpolicy</a></p>