洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

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, '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 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 .

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

Summary card of repository fediverse/fep

fep/fep/5624/fep-5624.md at main

fep - Fediverse Enhancement Proposals

codeberg.org · Codeberg.org

4
1
1

If you have a fediverse account, you can reply to this note from your own instance. Search https://hackers.pub/ap/notes/0196a01a-39bc-7666-aafb-a2567319d500 on your instance and reply to it.

洪 民憙 (Hong Minhee) @hongminhee@hackers.pub
Public

There would be some potential downsides to consider though:

  • Performance overhead: Each interaction requires policy verification, and approval object dereferencing adds network latency.
  • UX complexity: The three-tier permission model (allow/approve/deny) might confuse users compared to simpler binary choices.
  • State management burden: Servers need to persistently store approval objects and handle revocation edge cases gracefully.
0
0
0
0
1
0
silverpill @silverpill@mitra.social
Public

@hongminhee洪 民憙 (Hong Minhee)

I think the "interaction policy" part of GTS implementation is good, but their approach to managing conversations is wrong. They don't really have conversations, only independent posts loosely connected to each other:

https://docs.gotosocial.org/en/latest/federation/interaction_policy/#subsequent-replies-scope-widening

I think FEP-171b: Conversation Containers is a better conversation model. In that model, replies are not independent, but parts of a whole. interactionPolicy property can be used there too, but it would apply to a conversation and not to an individual post.

FEP-171b solves many problems, including synchronization of replies and reactions. The only advantage of the reply tree model is that each reply can be micro-managed by its author. But who really needs that?

Interaction Policy - GoToSocial Documentation

None

docs.gotosocial.org

1
0
0