댓글 막기 옵션을 구현하려고 했더니, 연합우주에서 댓글을 막았다는 것을 나타내는 합의된 속성 같은 게 없는 것 같다. 내가 멋대로 어휘를 하나 정해서 써도 되겠지만… 음…
GitHubDisable replies · Issue #319 · w3c/activitypub
Pixelfed의 경우에는 commentsEnabled라는 단순한 불리언 타입의 속성을 정의해서 쓰고 있는데, 문서화는 안 되어 있다. 음, 그냥 이걸 구현하면 일이 쉬워질 것 같지만… 한다면 제대로 GoToSocial의 상호작용 방침 기능을 구현하고 싶기도 한데.
docs.pixelfed.orgActivityPub | Pixelfed DocsThe official Pixelfed documentation
@hongminhee has no one written a FEP for reply controls yet?!
@liaizon Oh, there's FEP-5624: Per-object reply control policies! However, I find GoToSocial's interaction policy spec more well-designed. 
w3id.orgMaking sure you're not a bot!
@hongminhee I guess GtS should probably add their implementation to the FEP!
@liaizon Yeah, I left my thoughts on my separate post:
RE: https://hackers.pub/@hongminhee/0196a01a-39bc-7666-aafb-a2567319d500
hackers.pub · 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:The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/denySeparating approval objects from interactions appears more secure against forgeryThe explicit handling of edge cases (mentioned users, post authors) provides clearer semanticsThe 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 #interactionpolicyAfter 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:The three-tier permission model (allow/require approval/deny) feels more flexible than binary allow/denySeparating approval objects from interactions appears more secure against forgeryThe explicit handling of edge cases (mentioned users, post authors) provides clearer semanticsThe 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