Lobste.rs 의견들
  • 더 낫고 단순한 방법은 강한 반 LLM 정책을 만들고 제대로 집행하는 것임. GitHub처럼 LLM 사용을 장려하거나 친 AI 성향인 플랫폼에서도 벗어나야 함
    100% 효과적이진 않지만, LLM 사용을 숨기려는 경우도 대개 드러나고 그때 바로 금지하면 됨. 기업이 LLM 스팸을 밀어붙이면 기업 전체를 차단하고, 자체 호스팅 포지라면 방화벽에서 그 회사 네트워크를 막으면 됨
    작업 증명 같은 어설픈 시스템은 처음 기여자와 지나가던 기여자에게 불이익을 주며, 신뢰 보증도 결국 작업 증명임. 약한 사람을 괴롭히지 말고 나쁜 행위자를 빠르게 때리는 쪽이 더 효과적임

    • Tangled의 목표는 LLM 자체를 피하는 것보다 스팸 회피에 가까워 보임
      인용문에서도 “이 도구를 오용해 유지보수 부담을 만드는 기여자”를 보증하거나 비난한다고 되어 있음
    • 그러려면 완전히 새 플랫폼이 필요하고, 효과도 크지 않을 것 같음. 많은 프로젝트는 LLM 제출을 받아들이고, 많은 개발자는 프로젝트별로 사용 여부를 바꾸는 데 괜찮아함
      누군가 LLM 마녀사냥을 벌인다는 이유로 플랫폼 차원의 금지를 감수하게 만드는 건 역효과임. 여기나 HN에서도 글이 LLM으로 쓰였다는 잘못된 의심이 가끔 보이는데, 그걸 PR에서 처리해야 한다면 정말 피곤해짐
    • 여기서 명시한 목표는 “LLM”이 아니라 스팸을 피하는 것임
      이 시스템은 도구를 오용해 유지보수 부담을 만드는 기여자를 피하려는 것이고, 예전 방식으로 유지보수 부담을 만드는 기여자에게도 쓸 수 있음. 더 발전된 커밋 권한 모델처럼 보임
    • 이건 어떤 구체적 정책을 어겼는지가 아니라, 누군가가 정책을 어겼을 때 쓰는 답에 가까움
      반 LLM 정책이 있으면 이걸로 집행할 수 있고, 괴롭힘 금지 정책이 있으면 그것도 이걸로 집행할 수 있음
  • PR 제출 여부와 직접 연결되지 않는다면, 이건 좋게 봐도 쓸모없고 나쁘게는 유해한 조정 시스템이 될 것 같음. 누군가는 LLM을 쓴 적 있는 사용자를 대량으로 비난할 것이고, 이후엔 다른 이유의 집단 공격도 시작될 수 있음
    웹 오브 트러스트 자체는 멋지지만, 이 프로젝트는 기술적 측면만 다루고 사회적 측면은 다루지 않음. 조정 시스템을 만들면서 “남용 없이 어떻게 확장할 것인가”를 시스템 결과에 녹여낸 큰 섹션이 없다면 놀랄 일이 생길 것임

    • 보증은 내가 한 것 또는 내가 보증한 계정이 한 것만 보이므로, 모르는 사용자를 향한 대량 비난은 보이지 않게 설계되어 있음
    • 그런 일이 생길까 봐 걱정되지만, 실제로는 첫 번째 유명한 취소 사건이 터질 때까지 기다려 봐야 확실히 알 수 있을 듯함
    • 감쇠 개념이 들어가 있는 건 올바른 방향의 한 걸음임. 지금은 정책을 직접 제어하지도 않음
      사회적 문제를 해결하기 위해 사회적 동기를 먼저 붙인 실험이라 꽤 흥미롭고 설계도 영리해 보임
  • “비난받은 사용자에게는 아무 결과도 없습니다. 모자만 생깁니다”라면, 대체 무슨 의미가 있나? 결국 PR 처리는 그대로 해야 함

    • 시스템이 어떻게 동작하는지 보기 위한 시작점이고, 나중에 신뢰 수준 기반 차단 같은 기능이 추가될 것으로 보임
    • 나중에 추가할 수도 있음. 처음에는 @yorickpeterse가 말한 것을 테스트해 보고 싶고, 이후에는 사용자가 비난받은 사용자에게 어떤 “반응”을 할지 선택하게 하고 싶음
      예를 들면 차단, 우선순위 낮추기 같은 방식이 가능함
  • 도메인을 여러 개 만들고 각각 백만 명의 사용자를 생성해 서로 보증하게 하는 걸 막는 장치가 있나? 그러면 다른 사람들은 분리하기 어려운 평판 묶음을 나한테서 살 수 있게 됨
    차라리 lobste.rs의 초대 트리 모델이 더 나아 보임. 누군가 남용을 시작하면 하위 트리 전체를 잘라내기 쉽고, 더 느리게 성장하는데 그게 오히려 장점임

    • human.json 모델이 마음에 듦: https://codeberg.org/robida/human.json 특히 확장에서 시각화되는 방식이 좋음. 신뢰하는 사이트와의 최단 경로를 찾고, 거리를 색으로 표시하며 경로도 보여줌
      human.json에서는 아마 아무도 그런 네트워크의 노드를 보증하지 않거나, 들어오는 연결이 너무 적어서 거리가 크게 나올 것임. 네트워크에 사이트를 넣을 수 없다는 뜻은 아니지만, 보증과 불신이 빠르게 밀어낼 수 있음. 실제로 어떻게 작동할지는 아직 봐야 함
    • 라벨링은 사용자별임. 내가 수백만 개의 임의 계정을 보증하지 않을 사람만 보증한다면, 시빌 공격식 활동은 내 보증에 전혀 영향을 주지 않음
      “X, Y, Z가 보증함”을 인라인이나 마우스오버로 볼 수 있는 petnames 비슷한 UI 계층이 있으면 좋겠음
    • 보증의 서로 다른 정도를 점수화하는 모델이 있으면 흥미로울 것 같음. lobste.rs식 초대 트리를 활용해서, 100명이 보증했지만 모두 같은 조상을 공유하는 경우와 5명이 매우 다른 경로에서 보증한 경우라면 후자의 5개를 더 크게 세는 식임
      이런 방식이 “평판 농사”를 얼마나 막을 수 있을지 궁금함
    • 봇끼리 자기들만의 보증 서클을 만드는 정도만 가능할 것임. 나머지 네트워크는 그 봇 계정들을 보증하기 시작하지 않는 한, 그 서클의 결정을 볼 수 없음
      결국 모든 데이터는 공개이므로 누군가 tangled2.org를 만들어 전역 그래프를 만들 수도 있지만, UI에서는 의도적으로 자기 서클 밖으로 보증이 약해지도록 되어 있음
  • 아이디어는 좋지만, 그냥 자연스럽게 소통하면 어떨까 싶음. 사소한 커뮤니케이션까지 너무 잘 정리되고 일관적임
    타이핑한 글에 오타를 남겨 두면 진짜 사람다운 지문이 생김

  • 이 아이디어가 좋음. lobste.rs 자체가 쓰는 tree of trust가 떠오름

    • 또는 human.json도 있음. 내 사이트에서는 meat.json으로 이름을 바꿀까 생각 중임
  • 오픈소스 탄생과 거의 같은 시기에 진행됐던 trust metric research를 우리가 빠르게 재현하는 느낌임. @raph가 이걸 어떻게 볼지 궁금함

    • 옛날에 보던 이름이라 반가움. Slashdot의 3중 메타 조정 시스템도 인정받을 만함
      완벽하진 않았지만, 아무것도 없는 것보다는 확실히 훨씬 나았음
  • 이미 이런 게 여섯 개쯤 있는 것 같은데, 왜 기존 것에 합류하지 않고 또 하나를 만들까?