저와 제 에이전트들이 이 페이지를 바이브 코딩(vibe coded)했습니다: https://llama.garden
어떤 모델을 보고 싶은지 알려주세요. 기능 요청을 보내주세요.
시더(seeder)가 없나요? 아래에 댓글을 남겨주시면 제가 시도해 보거나, 다른 분들이 보고 시딩(seeding)을 시작할 수 있습니다.
현재 저는 단일 리스팅 큐레이터이지만, 시간이 지나면서 신뢰 네트워크(web of trust)에 의존하여 커뮤니티가 스스로를 관리할 수 있기를 바랍니다.
모든 것은 바이브 코딩(vibe coded)되었습니다. 아무것도 보장되지 않습니다.
피드백을 환영합니다! 방문해 주셔서 감사합니다! <3
github 링크: https://github.com/etemiz/llama.garden 곧 더 많은 스크립트를 오픈 소스로 공개할 계획입니다.
제 바이브 코더(vibe coder)가 생성한 추가 정보입니다:
단일 호스트에 의존하는 오픈 웨이트(Open weights)는 진정한 의미의 오픈이 아닙니다.
BitTorrent를 사용하면 설계 단계부터 대역폭 풀링(bandwidth pooling)이 발생합니다. 모든 다운로더는 잠재적인 업로더이므로, 인기가 높아질수록 용량이 늘어나며 부하가 가중되지 않습니다. 5,000명이 동시에 원하는 바이럴 70B 릴리스는 단일 HTTP 오리진(origin)을 마비시키겠지만, 스웜(swarm)에서는 그 5,000명의 피어(peer)가 곧 스웜이 됩니다.
토렌트 배포의 진정한 약점은 시더 마모(seeder attrition)입니다. 즉, 오래된 스웜은 사멸합니다. 이 프로젝트는 두 가지 측면에서 이를 처리합니다. 첫째, 웹시드(webseeds): 모든 .torrent 파일에는 HTTP 웹시드 URL이 내장되어 있어, BEP-19를 인식하는 클라이언트(Transmission이 참조 모델임)는 피어가 전혀 없는 상태에서도 HTTP를 통해 전체 페이로드(payload)를 가져오고 토렌트의 해시값과 대조하여 조각을 검증할 수 있습니다. HuggingFace에 미러링된 모델의 경우, 웹시드는 huggingface.co/<org>/<repo>/resolve/를 가리킵니다. 이는 모든 웹시드 다운로드가 큐레이터의 스냅샷과 대조하여 HF가 제공하는 바이트를 지속적으로 암호학적 감사(cryptographic audit)를 수행함을 의미합니다. 만약 HF가 조용히 샤드(shard)를 교체하거나 CDN 에지가 잘린 파일을 캐싱한다면, 조각 해시(piece hash) 검증에 실패하게 됩니다. 서명된 hf_match 태그는 토렌트가 HF 리포지토리의 바이트 단위로 정확한 미러인지 확인하며, 웹시드 메커니즘을 통해 누구나 HF, 큐레이터, 또는 릴레이를 신뢰하지 않고도 이를 독립적으로 검증할 수 있습니다.
둘째, 프로토콜 상의 수요 신호 전달(on-protocol demand signaling). 사용자는 작업 증명(proof-of-work) 기반의 Nostr 이벤트(kind 30103)를 통해 사멸한 스웜을 알립니다.

PoW(작업 증명)는 스팸 비용을 높여 신호가 의미를 유지하도록 만듭니다. 릴레이(relay)를 모니터링하는 큐레이터들은 사람들이 실제로 원하는 모델이 무엇인지 파악하고 이를 다시 시딩(re-seed)할 수 있습니다. 이를 통해 "누구도 이것이 도달 불가능하다는 사실을 모른다"는 상황을 "이번 주에 12명이 이것을 요청했다"는 상황으로 바꿉니다.

Nostr가 추가로 제공하는 것
BitTorrent는 전송(transport)을 제공할 뿐, 발견(discovery)을 제공하지는 않습니다. 역사적으로 토렌트 카탈로그는 웹사이트에 존재했으며, 이는 압수되거나, 고소당하거나, 부패할 수 있었습니다. 이 프로젝트는 Nostr를 카탈로그로 사용합니다. 리스팅(Listings, kind 30099)은 .torrent URL, 메타데이터, 소스 참조를 포함하는 서명된 이벤트이며, 서로 다른 운영자가 관리하는 9개의 릴레이를 통해 전파됩니다. 하나의 릴레이가 사라지더라도 나머지 8개가 모든 리스팅을 계속 서비스합니다. 만약 운영자가 특정 모델을 싫어한다면 자신의 릴레이에서만 리스팅을 해제할 수 있지만, 다른 사람의 릴레이에서는 할 수 없습니다. 검열은 전역적인 삭제가 아닌 로컬 수준의 옵트아웃(opt-out)이 됩니다.

카탈로그와 전송은 분리되어 있습니다: Nostr 이벤트는 토렌트가 존재한다는 사실과 .torrent의 위치를 알려주고, .torrent는 클라이언트에게 스웜(swarm)에 참여하는 방법을 알려주며, 스웜은 바이트(bytes)를 이동시킵니다. 어떤 단일 구성 요소도 차단될 수 없습니다. 모든 릴레이, 모든 .torrent 호스트, 그리고 모든 시더(seeder)를 동시에 차단해야만 합니다.

구조적으로 설계된 결함 없는 배포

• 발견(Discovery)은 독립적으로 운영되는 9개의 Nostr 릴레이를 통해 중복성을 갖습니다. 리스팅은 화이트리스트에 등록된 큐레이터의 npub에 의해 서명되고 클라이언트 측에서 검증되므로, 악의적인 릴레이가 이를 위조하거나 변경할 수 없습니다.
• .torrent 파일은 어디든 호스팅할 수 있는 작고 캐싱 가능한 블롭(blob)입니다. 클라이언트는 .torrent를 BT 클라이언트에 전달하기 전에 서명된 Nostr 이벤트와 정보 해시(info-hash)를 대조하므로, 해킹된 호스트가 변조된 토렌트로 교체할 수 없습니다.
• 가중치(weights)는 스웜에 존재합니다. 적절한 시간대에 있는 주거용 연결 기반의 노트북 한 대만 있어도, 다음에 필요한 사람을 위해 13B 모델을 계속 유지하기에 충분합니다.

개방적이고 포크(fork) 가능한 카탈로그
리스팅은 이 HTML 페이지의 사적 재산이 아닙니다. 모든 kind 30099 이벤트는 Nostr 네트워크에 존재하며, 누구나 서명하고 조회할 수 있습니다.

다른 UI를 원하는 개발자, 큐레이터의 취향에 동의하지 않는 개발자, 또는 특정 사용 사례를 위해 필터링된 목록이 필요한 개발자는 자신만의 클라이언트(웹 페이지, CLI, 데스크톱 앱 등)를 출시할 수 있습니다. 이들은 허가나 API 키 없이도 정확히 동일한 릴레이(Relay)를 통해 정확히 동일한 서명된 이벤트들을 가져올 수 있습니다. 카탈로그는 공개된, 추가만 가능한(append-only), 암호학적으로 서명된 이벤트 스트림(Event stream)입니다. 클라이언트는 해당 스트림을 바라보는 뷰(View)일 뿐, 특권적인 게이트키퍼(Gatekeeper)가 아닙니다. 누구나 이 HTML을 포크(Fork)하여 수정하고 그 결과를 게시할 수 있으며, 네트워크 효과는 특정 클라이언트가 아닌 프로토콜에 귀속됩니다.

독립적이며 스스로 업그레이드 가능함
HTML 클라이언트는 웹사이트, 백엔드, 또는 빌드 단계가 필요하지 않습니다. 디스크에 저장되어 file://로 열리든, 어떤 정적 호스트(Static host)에 미러링되든 동일하게 동작합니다. 모든 작업이 클라이언트 측(Client-side)에서 이루어지기 때문입니다. 중단시켜야 할 배포(Deploy)도 없고, 압수할 도메인도 없으며, 미납할 서버 비용도 없습니다. 클라이언트의 배포 자체도 피어 투 피어(P2P) 방식입니다.

클라이언트는 유지 관리자에 의해 업그레이드할 수 있지만, 업그레이드 경로는 변조 여부를 확인할 수 있습니다(Tamper-evident). 실행 중인 HTML은 큐레이터의 npub으로 서명된 kind 30100 이벤트를 Nostr에서 감시합니다. 이벤트가 더 높은 버전을 공지하면, 클라이언트는 이벤트 내의 Blossom URL에서 후보 HTML을 가져와 SHA-256을 계산하고, 이를 서명된 sha256 태그와 비교합니다. 해시가 일치할 때만(즉, 유지 관리자가 서명한 바이트와 호스트가 제공한 바이트가 동일함이 증명될 때만), 새로운 버전을 검증된 업데이트로 표시하여 로컬 Blob URL로 제공합니다. 해킹된 호스트는 악성 HTML을 밀어넣을 수 없습니다. 서명된 해시가 바이트를 승인하는 것이지, 호스트의 말을 승인하는 것이 아니기 때문입니다. 업그레이드는 선택 사항(Opt-in)이며 되돌릴 수 있습니다. 사용자는 별도로 선택하기 전까지 현재 실행 중인 버전을 유지합니다. 포크 가능성과 결합되어, 유지 관리자의 권한은 무엇이 업그레이드로 제공될지에 대해서만 엄격히 제한되며, 사용자가 무엇을 실행해야 하는지에 대해서는 권한을 갖지 않습니다.
제출자: /u/de4dee
[link] [comments]