ActivityPub 플러그인

글쎄요, 마스토돈(Mastodon) 사용자는 타임라인의 컨텍스트 안에서 이를 보게 되며, 타임라인은 일반적으로 제한적입니다. 마스토돈에서는 기본적으로 전체 타임라인이 400개 이상의 게시물을 넘지 않습니다. 원본을 보고 있다면, 어쨌든 Discourse에서 보고 있는 것이므로, 이론적으로는 맞지만 실제 혼란을 일으킬 것 같지는 않습니다. 콘텐츠를 보려면 이미 팔로우를 하고 있어야 하며, 원본으로 연결되는 링크를 클릭하면 혼란이 해소되는 Discourse로 이동하게 됩니다.

완벽하지는 않지만, 아마도 “가장 나쁘지 않은” 옵션일까요?

대안으로, 소유권 이전으로 인해 대체되었다는 주석을 달기 위해 편집을 연동하는 방식도 고려해 볼 수 있습니다. 마치 "이 포럼에서 이 주제에 대해 논의하세요"라는 링크를 추가하는 것과 유사한 방식이죠.

물론, 그것이 차이가 아니라고 주장하는 것은 아닙니다. 유용하고 실제로 사용되고 있는 Discourse 기능을 차단하는 것에 비해 허용 가능한 차이로 보일 뿐입니다.

원본을 삭제하면 연동 대상이 되는 다른 플랫폼들의 컨텍스트 내에서 고아 스레드(부모가 없는 스레드)가 됩니다. 편집을 통해 활동(activity)과 연관된 액터를 변경할 수 없기 때문입니다(제 이해로는요).

대안으로, Discourse의 게시물이 처음 연동되었을 때와 작성자가 다르면 편집을 전혀 연동하지 않는 방식도 있습니다. 아마 경고 메시지와 함께? “소유자를 변경하면 이 게시물의 연동이 비활성화됩니다. 계속 진행하시겠습니까?”

네. 일반 사용자(변경 사항을 검토하기 위해 연필 아이콘을 클릭할 수 있다는 것을 알지 못하거나, 그렇게 할 권한이 없는 사용자)에게는 Discourse에서 그렇게 보입니다. 제 생각에 이는 일반적인 Discourse 사용에 깊이 뿌리내린 관행입니다:

  • 게시물을 위키로 만드는 것은, 다른 사람의 편집이 일반 사용 시 내 이름으로 표시되는 것을 수용한다는 것을 의미합니다.
  • 위키가 아니더라도, 사이트 설정에 따라 충분한 권한을 가진 사용자가 Discourse에서 내 게시물을 편집할 수 있습니다.

제 관점에서, 기초 모델의 차이점을 고려할 때 이것이 가능한 한 가장 동등한 방식입니다.

제 생각에, “클릭하여 원본 사이트에서 게시물 보기” 기능은 이미 페디버스 우선(fediverse-first)인 구현들 사이에서 다른 콘텐츠를 표시합니다. 이 플러그인을 무시하더라도 말입니다. 보이는 댓글 세트가 다르고, 마크업이 다르고, 게시물(article) 처리 방식이 다릅니다. 따라서 이 플러그인을 통해 일부 차이가 보이는 것은 놀라운 일이 아니며, 필연적이라고 생각합니다.

(이 아이디어들에 대한 세심한 고찰에 다시 한번 감사드립니다. 이는 어려운 경계 사례임을 인지하고 있으며, 그 노력에 감사하며, 제 아이디어가 최선이라고 가정하지 않습니다. 또한 이 단계나 이 작업의 어떤 단계에서도 의무감을 느끼게 하거나, 제가 작성하는 특정 내용에 대해 반드시 응답해야 한다는 인상을 주려는 의도는 없습니다.)

1개의 좋아요

카테고리 변경의 경우와 마찬가지로, 이는 시나리오에 따라 정말로 달라진다고 생각합니다. 예를 들어 다음을 고려해 보세요.

  1. 사용자 1(액터 1)이 카테고리 1에 게시물 1을 생성합니다.
  2. 2분 후, 사용자 3(관리자)이 게시물 1의 작성자를 사용자 2(액터 2)로 변경합니다.
  3. 카테고리 1은 20개 도메인과 5가지 서로 다른 소프트웨어 플랫폼에 걸쳐 타임라인과 콘텐츠 발견 기능의 구현이 약간씩 다른 400명의 액터에게 팔로우되어 있습니다.
  4. 게시물 1이 생성된 지 2분 이내에, 동일한 내용이지만 다른 액터에 의해 작성된 2개의 노트(Note)가 해당 400명의 팔로워에게 POST됩니다.

이는 상당한 수의 팔로워에게 혼란을 줄 가능성이 높다고 생각합니다. 게다가 사용자 2가 20개 도메인에 걸쳐 자신이 작성하지 않은 중복 콘텐츠에 자신의 이름이 연결된 사실을 인지하지조차 못할 수 있다는 점도 무시할 수 없습니다. 단일 인스턴스 내에서 관리자가 그렇게 하는 것은 허용할 수 있을 것이며, 해당 인스턴스에 게시물을 올리는 것으로 어느 정도 암묵적 동의가 이루어진다고 볼 수 있지만, 특히 콘텐츠가 중복되는 이러한 불완전한 상황에서 그 암묵적 동의를 전체 페디버스(Fediverse)로 확장하는 것은 매우 신중해야 한다고 생각합니다. 게시물 소유자 변경은 Discourse에 특화된 강력한 관리 기능이며, 단일 인스턴스의 "사회적 계약"과 암묵적으로 연결되어 있습니다.

위키에 대한 논거가 더 강력하다고 생각합니다. 하지만 이미 암시하신 바를 다시 한번 지적하고 싶습니다. 위키는 일반적인 Discourse에 깊이 뿌리내린 개념입니다. 누구든(스태프뿐만 아니라)의 편집을 원본 작성자와 연결 짓는 것은 ActivityPub에 유사한 개념이 없는 Discourse의 개념입니다. ActivityPub의 표준 방법을 사용하여 이 개념을 전체 페디버스로 확장하는 것은 신중해야 합니다. 이러한 Update 활동은 수많은 다른 인스턴스와 소프트웨어 플랫폼에서 다른 Update 활동과 마찬가지로 처리되어, 원래의 위키 맥락에서 분리(decontextualised)될 것입니다. 또한, 이미 암시하신 대로, 스태프와 매우 신뢰할 수 있는 사용자가 다른 사람의 게시물을 편집할 수 있는 기능에 이미 이 맥락에서 잠재적인 문제가 있습니다. 위키라는 질문에 도달하기 전에, 이 더 제한적인 질문에 대해 더 많은 고려가 필요하다고 생각합니다.

저는 이러한 기능에 대해 Discourse와 ActivityPub 사이의 이분법적 선택을 설정하려는 것이 아닙니다. 제가 말하는 것은, 신중하게 결과를 고려하지 않고 민감한 Discourse 기능을 페디버스로 단순히 매핑하려 해서는 안 된다는 것입니다. 상당한 수의 사용자나 사용 사례를 해치거나 놀라게 하지 않을 것이라는 확신이 조금 더 생길 때까지, 이러한 더 민감한 기능은 ActivityPub 게시물에서 비활성화되어 있어야 한다는 것이 기본값이어야 합니다.

개인적으로는 아직 그 단계에 도달하지 못했다고 느끼며, 비록 위키 사례가 이 시점에서 더 많은 잠재력을 가진다고 직감하고 있지만, 아직 좋은 해결책을 완전히 보지는 못하고 있습니다.

8개의 좋아요

이 두 항목도 이제 완료되었습니다. @angus님의 OAuth를 통한 신원 인증 PR을 병합했습니다. 버그 수정과 성능 개선 사항을 제외하면, 이는 플러그인에 추가된 현재 단계의 기능이 완료되었음을 의미합니다.

현재로서는 이 플러그인이 상당히 풍부한 기능을 갖추고 있습니다. 주요 기능을 간략히 요약하자면, 이 플러그인은 다음을 지원합니다:

  • ActivityPub에서의 Followers Only 게시물 게시(기본값은 Public)
  • First Post 또는 Full Topic 게시(기본값은 First Post)
  • Full Topic 게시 사용 시 양방향 동기화, 즉 주제 내에서 Discourse로 생성된 모든 게시물이 ActivityPub에 게시되고, 반대로 ActivityPub의 답변은 Discourse에 게시됩니다.
  • 게시물을 Note(짧은 콘텐츠 서비스인 Mastodon 등) 또는 Article(긴 콘텐츠 서비스에 더 적합)로 게시하는 옵션
  • 신원 인증

다음 단계에서는 현재 기능을 세밀하게 조정하고 사용성을 개선하는 데 집중할 것입니다. 물론 여전히 피드백을 환영합니다. 특히 일반 사용자에게 이 모든 것이 어떻게 작동하는지 설명하는 방법에 대해 특히 관심이 많습니다. 쉬운 작업은 아니기 때문입니다.

저는 @angus님과 매우 같은 생각을 하고 있습니다. 우리의 목표는 합리적인 노력으로 실용적이고 달성 가능한 일을 하는 것입니다. 이를 위해, 현재로서는 Discourse의 일부 기능 제한을 수용할 의향이 있습니다. 이는 특정 제한 사항이 해결해야 할 중요한 문제인지 아닌지(예: 플러그인 사용자가 위키-ActivityPub 제한에 자주 부딪히는지 등)를 파악하는 데 최선의 방법이기 때문입니다.

6개의 좋아요

그렇다면, 지금이 제한 사항을 명확히 설명할 시점이라고 이해해도 되는 건가요?

안녕하세요 :slight_smile:

우선, 이 모든 것을 개발해 주셔서 감사합니다.

그리고 저는 서로 다른 ActivityPub 서비스를 연결하는 데 정말 관심이 있습니다. 제가 읽은 바로는, 이는 주로 Discourse와 Mastodon 사이에 메시지를 주고받는 것에 관한 것인 것 같습니다.

프로토콜은 서비스와 무관하다는 점을 알고 있지만, 예를 들어 서로 다른 Discourse 인스턴스를 연결하거나, Nextcloud 또는 PeerTube 등을 통합하는 방법에 대한 문서가 있는지 궁금합니다.

1개의 좋아요

이미 언급한 이유(기본적인 ActivityPub 환경에서는 해당 가정이 작동하지 않기 때문)로 인해, 현재 ActivityPub 주제에서 게시물 작성자 변경 및 위키 기능을 비활성화했습니다. 이 방식으로 ActivityPub 주제에서 일시적으로 비활성화된 기능은 이 두 가지뿐입니다. 다른 기능 축소 사항은 모두 이슈로 보고해 주십시오.

이것은 ActivityPub 사양을 엄격히 따르는 ActivityPub 플러그인이므로, 해당 사양을 따르는 모든 서비스와 함께 작동하도록 설계되었습니다. 여기에는 귀하가 언급한 모든 서비스(그리고 기타 서비스)가 포함됩니다. 실용적인 관점에서 보면 한 번에 하나의 서비스와의 호환성을 보장해야 하므로, 우리는 가장 큰 ActivityPub 플랫폼인 Mastodon과 통합하는 데 초점을 맞추고 있습니다.

4개의 좋아요

https://meta.discourse.org/u/rokejulianlockhart/preferences/activity-pub 에서 두 번 시도해 보았습니다.

{
	"errors": ["You are not permitted to view the requested resource."],
	"error_type": "invalid_access"
}

어떻게 해야 하나요?

2개의 좋아요

Hey @roke_julian_lockhart, 피드백 감사합니다. 인증 플로우를 어떻게 진행 중이신가요? 위에서 공유한 스크린샷의 “Authorize” 버튼을 브라우저에서 클릭하고 계신 건가요 (어떤 브라우저를 사용 중이신지도 알려주세요)? 아니면 어떤 방식으로든 URL을 복사/붙여넣기하고 계신 건가요? 이렇게 여쭤본 이유는 게시글에 해당 URL들이 포함되어 있기 때문입니다. meta.discourse.org에서 표준 플로우가 정상적으로 작동하는 모습을 담은 영상을 공유합니다.

위 내용과 다른 부분을 수행하고 계신가요?

2개의 좋아요

@angus,

  1. rokejulianlockhart@mastodon.social

  2. 사용자 이름 “rokejulianlockhart”로 사이트 “mastodon.social”에 로그인하려고 하고 있지만, 해당 웹사이트는 인증을 요구하지 않습니다. 이는 당신을 속이려는 시도일 수 있습니다.

    “mastodon.social”이 방문하려는 사이트인가요?

    여기서 저는

    예

    를 클릭합니다.

  3. Log in - Mastodon

    권한 부여 필요
    meta.discourse.org가 귀하의 계정에 액세스하려면 권한이 필요합니다. 이는 제3자 애플리케이션입니다. 신뢰하지 않는 경우 권한을 부여하지 않아야 합니다.
    권한 검토

    계정
    읽기 전용 액세스

    여기서 저는

    권한 부여

    를 클릭합니다.

  4. 그런 다음 이전의

    “mastodon.social”이 방문하려는 사이트인가요?

    프롬프트가 다시 나타나고, 저는 같은 조치를 취합니다.

  5. https://meta.discourse.org/ap/auth/oauth/redirect?code=s2H3Og_3oLTb8cAsYN9Kmgeh8xPySeOaWSp2bdZ2sEE

    1. .JSON

      {"errors":["You are not permitted to view the requested resource."],"error_type":"invalid_access"}
      
    2. Headers

      X-Firefox-Spdy: h2
      content-encoding: gzip
      content-type: application/json; charset=utf-8
      date: Mon, 25 Sep 2023 11:39:30 GMT
      referrer-policy: strict-origin-when-cross-origin
      server: nginx
      vary: Accept-Encoding
      x-content-type-options: nosniff
      x-discourse-route: o_auth/redirect
      x-discourse-username: rokejulianlockhart
      x-download-options: noopen
      x-frame-options: SAMEORIGIN
      x-permitted-cross-domain-policies: none
      x-request-id: 01276bd6-77ea-42ae-8f60-6fa365a70e1f
      x-xss-protection: 0
      
      Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
      Accept-Encoding: gzip, deflate, br
      Accept-Language: en-GB,en;q=0.7,en-US;q=0.3
      Connection: keep-alive
      Host: meta.discourse.org
      Sec-Fetch-Dest: document
      Sec-Fetch-Mode: navigate
      Sec-Fetch-Site: cross-site
      Sec-Fetch-User: ?1
      Upgrade-Insecure-Requests: 1
      User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/117.0
      

안녕하세요, 최신 업데이트 이후 사용자 프로필(/u/user)이 깨지는 것 같습니다. 사용자 이름과 프로필 사진은 표시되지만(상단의 사용자 오펜시브 목록도 포함됩니다)

플러그인 목록을 확인하면서 하나씩 비활성화해 보다가 문제가 사라졌습니다. 안전 모드(safe mode)를 활성화해도 문제가 발생하지 않았습니다. 클라이언트에서 발생한 일부 오류는 다음과 같습니다:

Cannot read properties of null (reading 'getBoundingClientRect')
at Object.offset (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:5104:37)
at e.scrolled (https://amcforum.wiki/assets/discourse-9756bc4a118ac228ac6ac3f2b29c7d4a7d60a9f16ece25de4a772f0055c6eb94.js:2347:106)
at p.invoke (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4339:182)
at p.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4331:141)
at h.flush (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4346:207)
at $._end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4410:9)
at $.end (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4363:240)
at $._runExpiredTimers (https://amcforum.wiki/assets/vendor-db2360c46fde6d9039e575c45f307a3475f72fc389fad00414eaf0f83a1621a6.js:4417:192)

플러그인이 활성화된 상태의 모습입니다 (본인 계정 기준)

다른 사용자(이 경우 9pfs)의 모습입니다

플러그인으로 인해 발생하는 또 다른 재미있는 버그입니다:

현재 이 커밋의 3.2.0.beta2-dev 버전을 사용 중이며, 이 커밋의 플러그인 0.1.0 버전을 실행하고 있습니다.

1개의 좋아요

@roke_julian_lockhart 쿠키가 비활성화되어 있거나, 어떤 종류의 프라이버시 확장 프로그램이 실행 중인가요? 현재 인증 플로우(authorization flow)는 정상 작동하려면 보안 세션 쿠키에 의존하고 있습니다.

@aboutDavid 보고해 주셔서 감사합니다. 가능성은 있지만, 공유해 주신 문제가 이 플러그인의 문제로 인해 발생했을 가능성은 낮아 보입니다. 사이트 링크를 공유해 주실 수 있나요? 또한 현재 활성화된 테마나 테마 구성 요소가 있나요?

2개의 좋아요

세이프 모드 트러블슈팅을 통해 다음 사항이 확실하게 확인되었습니다:

  1. 비공식 플러그인입니다.
  2. 테마나 테마 구성 요소가 아닙니다.

제가 아는 한, 비공식 플러그인은 두 개입니다:

  1. Animate avatars (직접 확인 결과 원인이 아님)
  2. ActivityPub

사이트 링크는 다음과 같습니다:

3개의 좋아요

업그레이드 UI에서는 그 두 개를 제외한 모든 플러그인 옆에 체크 표시가 표시됩니다(이것은 해당 플러그인들이 공식 플러그인임을 나타냅니다).

2개의 좋아요

사이트의 문제는 user-profile-avatar-flair 플러그인 아웃렛을 사용하는 무엇인가에 의해 발생하고 있을 가능성이 높습니다. 이 플러그인은 해당 아웃렛을 사용하지 않습니다. 그러나 animated avatars 플러그인은 이를 사용합니다.

어떻게 확인하셨나요?

1개의 좋아요

@aboutDavid 님이 확인하여 플러그인에 클라이언트 측 JS가 없음을 확인했습니다. 문제가 일부 서버 측에서 발생하는 건가요?

1개의 좋아요

클라이언트 측 JS가 없다는 것이 반드시 클라이언트 측 문제가 없다는 뜻은 아닙니다. 이 경우 문제는 플러그인 아웃렛이 사용되는 방식, 아마도 템플릿에서 발생하는 것으로 보입니다. 애니메이션 아바타 플러그인을 제거해 본 후 결과를 알려주시겠습니까?

(참고로, 애니메이션 아바타 플러그인에도 클라이언트 측 JS가 있습니다. 예를 들어).

1개의 좋아요

최근 Meta에서 카테고리를 편집하려고 들어갔습니다(일부 그룹 접근 권한을 변경하기 위해서였죠). ActivityPub 관련 설정은 건드리지 않았는데, 스태프 로그에 다음 세 항목이 기록되었습니다:

기술적으로는 nil에서 기본값으로 변경된 것이므로, 실제 동작에는 변화가 없는 것 같습니다. 하지만 혼란을 피하기 위해 이러한 삭제 로그가 기록되지 않도록 하는 것이 좋을 것 같습니다.

2개의 좋아요

리포트 감사해요, 데이비드. 곧 확인해볼게.

1개의 좋아요

아이고, 오늘 좀 멍청하네요. 죄송합니다

수정: 네, 아마도 애니메이션 아바타일 것 같습니다. 시간 낭비시켜서 죄송해요 ㅋㅋ

3개의 좋아요

@angus, 제가 아는 한 그런 건 없습니다.

그리고 uBlock Origin은 비활성화했음을 확인했습니다. 어쨌든 프라이버시 목록을 사용하지는 않지만요.


하지만 오늘 이 기능을 테스트하다가 다른 문제를 겪었습니다.

Log in - Mastodon

클라이언트 인증이 실패했습니다. 원인은 알 수 없는 클라이언트, 클라이언트 인증 포함 안 됨, 또는 지원되지 않는 인증 방법입니다.