GN⁺ 5달전 | parent | ★ favorite | on: 프로젝트 Gemini(geminiprotocol.net)
Hacker News 의견
  • 예전에 Gemini 프로토콜을 가지고 놀 때 정말 즐거웠음
    하지만 직접 실험하는 단계를 지나자, gemtext의 제약이 흥미를 많이 떨어뜨렸음
    텍스트 중심의 마크업 언어라서 글을 쓰는 사람에게는 완벽하지만, 내가 주로 공유하는 그림이나 시각 자료에는 불편했음
    이미지나 썸네일 디렉터리 노출 방식이 산만함을 유발할 수 있다는 주장도 이해하지만, 시각 예술도 중요한 표현 수단임
    결국 Gemini는 본래 목적에는 잘 맞는 프로토콜임. 내 필요에는 안 맞지만, 맞는 사람은 분명 좋아할 것임

    • 일부 Gemini 클라이언트는 인라인 이미지를 지원함
      방문자가 원하면 썸네일 목록을 볼 수 있도록 설정할 수 있음
    • 동의함. 사실 Gemini는 Gopher가 남긴 빈틈을 메우지도 못함
      그냥 “motherfuckingwebsite.com” 같은데, 너무 진지하게 굴고 있음
  • 나는 smol web을 즐기며, 기술 애호가들에게 정말 좋은 공간이라고 생각함
    그래서 내 사이트 sava.rocks에 finger://, gemini://, gopher://, https:// 미러를 모두 만들어둠

  • 나이 때문일 수도 있지만, 왜 굳이 모든 걸 새로 만들지 이해가 안 됨
    약간 수정된 HTML 2.0이나 3.2로 돌아가도 충분하다고 봄
    나도 현대 웹의 문제점을 싫어하지만, 이미 존재하는 “비현대적 웹”을 개선하는 게 더 낫다고 생각함
    상호운용성(interoperability) 을 절대 과소평가하지 말아야 함

    • 별도의 프로토콜을 쓰면 모든 사이트가 동일한 제한을 가진다는 장점이 있음
      제한된 브라우저로 검색해도 읽을 수 있는 결과만 나오기 때문에 발견성(discovery) 문제를 줄일 수 있음
    • Gemini는 웹의 부정적 변화에 대한 반작용
      웹이 확장 가능하게 설계된 게 근본적 실패라고 보고, Gemini는 확장 자체를 어렵게 만들어버림
      하지만 나는 이런 태도에 공감하지 않음. 웹의 문제는 출판자 중심으로 발전했다는 점임
      결국 사용자는 “Google의 에이전트”를 쓰게 되었고, 나는 그런 출판자 중심 소프트웨어보다 사용자 중심 도구를 원함
    • HTML 2.0과 NOSCRIPT는 서버와 클라이언트 양쪽에서 강제하기 어렵음
    • 흥미로운 결론임. 상호운용성이 이 프로토콜의 큰 이유 중 하나일 것임
      직접 Lagrange를 설치하고 gemini://bleyble.com/cgi-bin/random 에 접속해보면 느낌이 다름
    • 무언가를 새로 만들면 사람들이 참여감을 느끼고, 구현이나 설계에 기여할 수 있음
      사람들은 이런 과정에 함께하는 걸 좋아함
  • 나는 Gemini용 검색엔진과 Wayback Machine을 직접 구축했음
    gemini://kennedy.gemi.dev
    약 4천 개의 호스트와 100만 개의 문서·이미지·파일이 있음
    크롤러나 인덱서 실험을 하기 좋은 놀이터이고, 대부분 정적 사이트지만 CGI로 약간의 상호작용성을 추가함
    예: gemini://gemi.dev/cgi-bin/moon.py

  • 이름의 유래는 NASA의 우주 프로그램에서 따온 것으로 기억함
    Gopher는 Mercury, Web은 Apollo, 그리고 Gemini는 그 중간 단계임
    Gemini는 새로운 인터넷 프로토콜로서

    • Gopher보다 무겁고
    • Web보다 가볍고
    • 둘 중 어느 것도 대체하지 않으며
    • 최대 효율 대비 최소 복잡성을 추구하고
    • 사용자 프라이버시를 매우 중요하게 여김
    • 이미지가 없다는 점은 대부분에게 결정적 단점일 것 같음
    • 문서들이 단순히 링크로 연결되어 있다면 검색과 발견은 어떻게 작동하는지 궁금함
      Gemini 외부에 검색엔진이 존재해서 연결해주는 구조인지 알고 싶음
  • 팬데믹 시기에 Gemini를 다루는 게 정말 즐거웠음
    단순한 프로토콜을 새로 배우는 도전감이 있었고, 직접 GUI 클라이언트를 만드는 재미도 있었음
    세상을 뒤흔들 정도로 성공하진 않았지만, 여전히 인터넷의 아늑한 구석으로 남아 있음

    • 나만 그 시기를 완전히 놓쳤음 ㅠ
  • 100단어 소개문을 읽었는데도 여전히 뭔지 모르겠어서 그냥 나왔음

    • FAQ에 설명이 있음
      Gemini는 경량 하이퍼텍스트 형식을 지원하는 클라이언트–서버 프로토콜로, 파일 배포에 초점을 둠
      URI, MIME, TLS 같은 표준 기술 위에 구축되어 있고, 단순함과 비확장성을 핵심 철학으로 함
      요약하자면, 극도로 축소된 웹 스택
    • 기본적으로 HTTP와 HTML의 대안 프로토콜
      복잡도는 초기 HTTP/1과 Gopher의 중간쯤이며, 텍스트 중심으로 설계되어 멀티미디어나 인터랙티브 기능은 없음
    • 나도 같은 반응이었음. 소개문이 너무 공허한 수사로 가득 차 있어서 실망스러웠음
    • 결국 Gopher + TLS + UTF8 + 텍스트 래핑 + 헤더 + 비정렬 리스트 정도임
    • 요약하자면, 이미지나 스크립트가 없는 웹
  • 나는 Gemini의 철학 — 인라인 이미지 없음, 추적 없음, 산만함 없음, 확장 불가, 보안 중시 — 에 공감했음
    그래서 안드로이드용 Gemini 브라우저 Buran을 설치하고 여러 링크를 탐색했음
    그런데 gemini://hellomouse.net에 들어가자마자 인라인 이미지가 보였음
    Gemini의 원칙에 어긋나는 것 같은데, 내가 뭘 잘못한 건지 모르겠음

    • 잘못한 건 없음. 실제로 Gemini 사용자들도 인라인 이미지의 유용성을 인정함
  • 2021년부터 Gemini Capsule(웹사이트/블로그)을 운영 중임
    방문자는 거의 없지만, 저녁에 small web을 탐색하며 흥미로운 콘텐츠를 찾는 재미가 있음

  • 이 사이트는 너무 수다스러워서 핵심을 잡기 어려웠음
    하지만 요약하자면 “현대화된 Gopher”라는 설명이 크게 틀리지 않은 것 같음