ActivityPub로 만든 주제는 카테고리가 없나요?

무슨 일이 일어나고 있는지, 혹은 ActivityPub가 무엇인지 정확히 알지는 못하지만, 이 문제가 발생하는 원인이 ActivityPub인 것 같습니다:

이 토픽에는 카테고리가 없고 태그만 있습니다. 의도된 설정이 아닐 텐데 말이죠.

관련 스크린샷:

아, 흥미롭네요. activitypub 태그는 ActivityPub 프로토콜을 통해 다른 커뮤니티에서 주제를 받는 것으로 설정되어 있습니다(양방향 동기화이므로 메타의 주제와 답변도 다른 커뮤니티로 전송됩니다).

그러나 플러그인이 생성하는 주제에 대해 기본 카테고리를 선택하지 않는 것으로 보입니다. 이것이 엄밀히 말해 플러그인 문제인지 메타 자체의 문제인지는 확신이 서지 않습니다.

@tobiaseigen 지정된 카테고리가 없을 때 선택할 '기본 카테고리’에 대한 사이트 설정이 있나요? default composer category(기본 작성 카테고리)는 존재하지만, 이는 정확히 같은 개념은 아닙니다.

의도된 것입니다.

현재 Discourse에는 엄밀히 말해 ‘기본 카테고리’라는 개념이 없다고 생각합니다. 말씀하신 대로, 작성기(composer)의 기본 카테고리는 별개의 문제입니다.

@angus 이 문제가 여기에서도 발생했습니다. ActivityPub를 통해 게시물을 작성할 때 카테고리를 지정할 수 있는 방법이 있나요? (제 이해로는 이것이 Discourse (@Discourse@mastodon.social) - Mastodon 인 것 같습니다.)
아니면, ActivityPub를 통해 생성된 주제를 특정 카테고리로 이동시키는 설정이 있을까요?

@NateDhaliwal님, 조언해 주셔서 감사합니다.

링크하신 그 토픽은 원래 socialhub.activitypub.rocks에서 생성되었습니다. ActivityPub 정보에서 원본 게시 위치를 확인할 수 있습니다.

이것이 어떻게 작동하는지 조금 더 자세히 설명해 드리면, 왜 그런 제안이 적합하지 않은지 이해하실 수 있을 것입니다.

Discourse는 게시물을 게시하고 수신할 수 있는 두 가지 유형의 ActivityPub 행위자(actors)를 지원합니다: 카테고리(categories)와 태그(tags). 현재 meta에는 ActivityPub가 활성화된 두 개의 카테고리와 네 개의 태그가 있습니다. 여기서 확인해 볼 수 있습니다.

제안하신 것을 달성하려면, 카테고리 행위자를 생성하는 것이 방법입니다. #announcements 또는 Contribute > Feature(즉, announcements@meta.discourse.org 또는 feature@meta.discourse.org로 전송된 게시물)로 수신된 게시물은 해당 카테고리로 바로 이동합니다(카테고리 행위자에 "full topic"이 활성화되어 있는 경우).

당신이 주목하고 있는 부분은 태그 행위자로 수신된 게시물, 예를 들어 #activitypub의 경우 activitypub@meta.discourse.org로 수신된 게시물이 자동으로 특정 카테고리로 이동하지 않는다는 것입니다. 제가 설명한 맥락에서 생각해보면, 만약 자동으로 이동한다면 그것은 다소 이상할 것입니다.

태그의 역할은 서로 다른 카테고리 간의 토픽을 분류학적으로 그룹화하는 것입니다. activitypub@meta.discourse.org로 전송된 모든 게시물이 들어가는 기본 카테고리가 있다면, 태그 대신 activitypub 카테고리를 생성하고 해당 카테고리를 위한 행위자를 생성하는 것이 더 적절할 것입니다.

한 발짝 뒤로 물러서서 더 넓게 생각해보면, #activitypub과 같은 일반적인 분류학(taxonomy)에는 카테고리가 아니라 태그를 사용하는 것이 더 나을 수 있으며, 필요한 경우 수신된 토픽을 수동으로 분류하는 것이 좋습니다. 특정 카테고리와 관련된 더 구체적인 행위자들이 있지만, #activitypub은 다양한 유형의 토픽을 포함할 수 있기 때문입니다.

결국 이것은 커뮤니티가 스스로를 관리하고 Fediverse와의 관계를 어떻게 설정하느냐의 문제입니다. 적어도 아직은 기술적인 해결책이 필요하지 않다고 생각합니다. @tobiaseigen님이 이 문제를 어떻게 접근하고 싶은지에 대해 추가적인 생각을 가질 수 있을 것입니다.

아, 그렇군요. 설명해 주셔서 감사합니다!