왜 Discourse는 IndexNow을 지원하지 않나요?

기여 기능
1

오늘날 빠르고 빠르게 구식이 되는 정보 환경에서, 인덱싱 속도는 성공을 위한 가장 중요한 요소 중 하나입니다.

그런데 왜 Discourse는 이 프로토콜을 전혀 지원하지 않을까요? https://www.indexnow.org/

3개의 좋아요
2

누구도 이 기능을 지원하기 위해 플러그인이나 풀 리퀘스트를 만들 만큼 관심이 없었기 때문입니다. 제 생각에는 Google이 IndexNow를 지원하지 않는다는 사실이 그 원인이 아닐까 싶습니다. Google은 대부분의 사람들이 가장 중요하게 생각하는 검색 엔진이니까요.

하지만 이 기능을 추가하는 플러그인을 만들어서 기여하고 싶다면 환영입니다!

14개의 좋아요
3

커뮤니티에 기여하고 이 확장 기능을 개발하고 싶지만, 우리는 프로그래머가 아닙니다.

구글은 IndexNow에 대해 테스트 중이며 결과를 지켜볼 것이라는 입장입니다.

4

Index Now에 관한 새로운 소식은 없나요? 이제 OpenAI조차 Bing 인덱스를 기반으로 하고 IndexNow와 연결된 검색 엔진을 운영하고 있으니, 그 중요성이 더욱 커진 것 같습니다.

5

그렇다면 #marketplace에서 플러그인을 의뢰할 수 있습니다. 500달러에서 2,000달러 사이의 비용이 든다고 생각할 수 있습니다. 저보다 더 나은 견적을 제시할 수도 있습니다.

3개의 좋아요
11

동의합니다. 지금이 Discourse가 IndexNow를 지원하기에 정말 좋은 시기인 것 같아요 :))

1개의 좋아요
12

IndexNow 기능을 검토한 결과, 이것이 핵심 기능/플러그인 중 하나가 되어야 한다고 동의합니다. 개발자 자원이 제한적이라는 점도 이해하고 있습니다.

핵심 팀을 지원하기 위한 필수 플러그인에 대한 제 의견을 아래에 정리했습니다. 추가 의견을 자유롭게 남겨 주세요.

전제 조건:

  1. IndexNow 플러그인은 예약 시간 모델을 기반으로 일괄 알림을 사용합니다 - 설계 고려 사항 #1 참조
  2. 일괄 알림은 시간 간격으로 설정됩니다.
  3. 알림은 공개 주제만 사용합니다.
  4. 플러그인이 활성화된 경우, 알림은 새/변경/삭제된 주제에 대해서만 전송됩니다.
  5. 플러그인은 과거의 변경 사항/이벤트에 대해 소급하여 알림을 보내지 않습니다.

사용자 안내:

  1. 원하는 IndexNow 검색 엔진에 가입합니다.
    • API 키를 발급받습니다.
    • 검색 엔진 엔드포인트 URL을 발급받습니다.
  2. 플러그인을 설치합니다.
  3. 관리자를 설정합니다.

사용 사례 - 관리자 설정

  1. 사용자가 자동 제출 기능을 켜고 끌 수 있도록 합니다.
  2. 사용자가 IndexNow 검색 엔진 엔드포인트를 입력할 수 있도록 합니다. 설계 고려 사항 #3 참조.
    • 입력 필드는 텍스트 매개변수입니다.
    • 입력 필드는 유효한 URL이어야 합니다.
    • 기본값은 https://www.bing.com/indexnow인 Bing URL입니다.
  3. 사용자가 API 키를 입력하고 저장할 수 있도록 합니다.
    • API 키를 저장하기 위한 문자열 입력 필드입니다.
    • 입력 필드는 영숫자여야 합니다.
    • 기본값은 ""입니다.
  4. 사용자가 일괄 알림을 위한 예약 시간 매개변수를 정의할 수 있도록 합니다.
    • 시간 매개변수는 시간 간격으로 설정됩니다.
    • 시간 값을 저장하기 위한 문자열 입력 필드입니다.
    • 유효한 입력값은 정수입니다.
    • 유효한 입력값은 1에서 24까지의 범위입니다.
    • 기본값은 12입니다.

사용 사례 - 텍스트 키 파일

  1. 시스템은 indexnowkey.txt라는 이름의 파일을 생성합니다.
  2. 키 파일은 루트 레벨에 저장되어야 합니다.
  3. 시스템은 파일에 API 키를 입력합니다.
  4. 파일은 http/https를 통해 원격 사용자/시스템에서 접근 가능합니다.

사용 사례 - 일괄 알림 프로세스 예약

  1. 시스템은 관리자 설정에서 정의된 설정에 따라 간격 기반으로 작업을 예약합니다.
  2. 간격 값은 작업 사이의 지연 시간을 시간 단위로 정의합니다. 예를 들어, 입력값이 2이면 작업이 2시간마다 실행되어야 함을 의미합니다. 값이 4이면 작업이 4시간마다 실행되어야 함을 의미합니다. 값이 24이면 작업이 하루에 한 번 실행되어야 함을 의미합니다.

사용 사례 - 일괄 알림 프로세스

  1. 시스템은 관리자 설정에서 정의된 사이트 설정을 통해 알림 프로세스가 활성화되었는지 판단합니다.
  2. 시스템은 사이트 설정에서 API 키가 유효한지(빈 문자열 ""이 아닌지) 판단합니다.
  3. 시스템은 정의된 시간 간격 설정을 기반으로 주제 목록을 생성합니다. 쿼리 시간 범위에 대해서는 설계 고려 사항 #2 참조. 포함될 주제 매개변수는 다음과 같습니다:
    • 주제는 공개 보기만 허용됩니다.
    • 새 주제
    • 새 게시물이 있는 주제
    • 수정된 게시물이 있는 주제
    • 삭제된 주제
    • 주제 목록은 중복이 없어야 합니다.
  4. 시스템은 다음 형식을 사용하여 JSON 패킷을 생성합니다.
{
  "host": "current_site",
  "key": "api_key",
  "keyLocation": "https://current_site/indexnowkey.txt",
  "urlList": [
      "https://www.example.com/url1",
      "https://www.example.com/folder/url2",
      "https://www.example.com/url3"
      ]
}
  1. JSON 패킷은 다음으로 전송됩니다.
    • URL: sitesettings.search_engine_indexnow_endpoint
  2. JSON 패킷은 다음 헤더와 함께 전송됩니다.
    • Content-Type: application/json; charset=utf-8
    • Http/1.1
    • Host: bing
  3. HTTP 요청 수신 확인을 검증합니다.
    • http 200 - 제출 성공 - 프로세스 종료
    • Http 429 - 제출 시도 횟수 초과 - 간격 시간을 늘리도록 관리자에게 알림을 보냅니다.

설계 고려 사항:

  1. 일괄 알림 vs. 개별 알림—개별 알림은 작은 도메인의 경우 허용될 수 있지만, 대형 보드의 경우 모든 새/업데이트된 게시물에 대해 알림을 추가하면 많은 이벤트 프로세스가 생성될 수 있습니다. 검색 엔진 인덱싱 성능 관점에서 볼 때, 시간당 일괄 알림은 포럼의 80%에 대해 허용 가능한 수준입니다.
  2. 일괄 알림 쿼리 타이밍 - SideKiq가 간격 타이밍을 제어합니다. SideKiq가 과부하 상태인 경우, 일괄 알림 프로세스가 지연될 수 있습니다. 쿼리 시간 범위가 예약 간격과 같을 경우, 일괄 알림 프로세스가 새/업데이트된 주제를 놓칠 수 있습니다. 지연된 프로세스를 커버하도록 쿼리를 확장하는 시간 매개변수가 필요합니까? 아니면 스케줄러가 쿼리 시간 간격을 제어하도록 초기화된 타임스탬프를 전달할 수 있습니까? 아니면 제출된 주제와 타임스탬프를 위한 데이터베이스 테이블/값을 생성해야 합니까?
  3. 각 검색 엔진과 정의된 IndexNow URL 엔드포인트를 포함하는 내부 테이블을 구축해야 합니까? 사용자는 URL을 입력하는 대신 드롭다운 메뉴에서 선택할 수 있습니다. 이를 통해 잠재적인人為 오류를 제거할 수 있습니다.

무엇이 빠져 있습니까? 무엇을 추가하시겠습니까?

1개의 좋아요
13

기존의 발신 웹훅(outgoing webhook) 지원을 활용하여 원하시는 것 중 일부 또는 전부를 달성할 수 있는 방법이 있을까요?

1개의 좋아요
14

꽤 괜찮은 개요인 것 같습니다. 작성, 디버깅, 테스트, 유지보수를 해야 하는 메서드를 두 개로 늘리는 것을 피하기 위해 벌크/배치 제출만 수행하는 방식을 채택할 것 같습니다.

아니면, 단일 벌크/배치 작업을 통해 레이트 리미팅 문제를 피하면서 제출 방식을 하나로 통일하는 것도 방법입니다(단, 개별 게시물 단위가 아닌 항상 배치로만 제출하는 방식).

단일 엔드포인트에 제출하는 버전이라면, 작동하는 것으로 보이지만 에러 처리가 최소 수준인 경우 2,000달러, 테스트를 위해 최소한의 스펙이 갖춰진 경우 5,000달러 수준이 될 수 있습니다. 그리고 여러 엔드포인트에 대한 알림 처리도 가능할까요?

15

훌륭한 “How”(방법)에 대한 질문을 하셨습니다. 저는 Discourse에 “How” 질문을 할 때 가장 적합한 사람이 아닙니다.

저는 “What”(무엇이 필요한지)을 문서화하는 데 능숙합니다. "What"에 대한 명확하고 깔끔한 정의를 내리면 코딩 속도가 빨라지고, 따라서 비용도 절감됩니다.

웹훅에 대한 "What"을 답변하자면, 이는 단일 알림과 일괄 알림의 차이와 관련이 있다고 생각합니다. 저는 중간 규모의 포럼을 운영하고 있으며, 일괄 알림을 선호합니다.

  1. 주제가 생성되거나 업데이트될 때 검색 엔진에 알림을 받을 필요가 없습니다.
  2. 주제 및 게시글 생성과 같은 핵심 프로세스 내에 낮은 우선순위의 이벤트를 추가하는 것을 좋아하지 않습니다. 추가적인 이벤트는 사용자의 대기 시간을 늘립니다. 일괄 처리 방식은 하나의 SQL 쿼리와 HTTP 전송만 필요로 합니다. 이는 사용자 상호작용과 독립적으로 백엔드 이벤트로 처리될 수 있습니다.
16

플러그인은 단 하나의 엔드포인트에 대해서만 개발하면 됩니다. IndexNow 협정에 따라 검색 엔진들은 서로 제출된 데이터를 공유해야 합니다. 즉, Bing에 제출하면 Bing이 다른 IndexNow 준수 검색 엔진에 제출하는 방식입니다.

플러그인 개발을 위해 1인당 100달러씩 총 30명의 크라우드펀딩 참여자가 필요합니다.

1개의 좋아요