-- Leo's gemini proxy
-- Connecting to geminiprotocol.net:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
Última actualización: 2021-02-28
Gemini es un nuevo protocolo de Internet a nivel de aplicación para la distribución de archivos arbitrarios, con la consideración especial de brindar un formato de hipertexto ligero, que facilita el vinculo entre archivos. Tal vez pienses en Gemini como "la red, desnuda en su esencia" o como "Gopher un poco mejorada y modernizada", dependiendo de tu perspectiva (la última probablemente sea la más precisa). Gemini puede interesarle a personas que:
Se opongan al seguimiento omnipresente de los usuarios en la web
Están cansados de las molestas ventanas emergentes, anuncios desagradables, videos que se reproducen automáticamente y otras características erraticas de la web moderna
Están interesados en computación de baja potencia y/o redes de baja velocidad, ya sea por elección o por necesidad
Gemini pretende ser simple, pero no lo más simple posible. En su lugar, su diseño se esfuerza por maximizar su "relación potencia-peso", mientras mantiene su peso en límites aceptables. Gemini también pretende ser muy consciente de la privacidad, (algo difícil de extender en el futuro) por lo que *se mantendrá* simple y consciente de la privacidad, para que sea compatible con el ethos informático de "hazlo tu mismo". Por esta última razón, Gemini es técnicamente muy familiar y conservador: es un protocolo en el paradigma tradicional de cliente-servidor solicitud-respuesta, y se basa en tecnología madura y estandarizada como URI, tipos de medios MIME y TLS.
El Proyecto Gemini empezó en junio de 2019. Si bien el protocolo está finalizado en mayor parte, el software, los recursos y la comunidad disponibles, aún están en un estado prematuro de desarrollo (¡aunque próspero!).
El Proyecto Gemini fue creado originalmente por Solderpunk <solderpunk _at_ posteo _dot_ net>, quien continúa siendo el "Dictador benevolente" del proyecto. Sin embargo, el protocolo ha sido diseñado en colaboración de la comunidad informal de muchas partes interesadas a través de correos electrónicos, publicaciones en la "flogosfera" de Gopher y toots en el Fediverse. Muchas personas han formado partes importantes del protocolo, por lo que, a pesar de tener un único líder, no se debe pensar en Gemini como el trabajo de una sola persona.
En febrero de 2021, el colaborador de Gemini, Sean Conner, recibió cierta autoridad en la toma de decisiones, para ayudar a finalizar la especificación de Gemini durante el período en el que Solderpunk no pudo dedicar el tiempo y la energía necesarias al proyecto.
Es difícil saberlo con exactitud. Es probable que contar los nombres de host únicos de los servidores de Gemini exagere el tamaño del espacio, ya que algunos sitios multiusuario le dan a cada usuario su propio subdominio. Por otra parte, es probable que contar las direcciones IP únicas subestime el tamaño, ya que Gemini permite que múltiples dominios sean admitidos desde la misma IP. De todos modos, a principios de 2021 había alrededor de 200.000 URL Gemini conocidas, repartidas en unas 750 "cápsulas" (el término de la comunidad de Gemini para "sitios"), 500 dominios y 600 direcciones IP. Sin embargo, el espacio se está expandiendo rápidamente. Puedes encontrar las últimas estadísticas en el enlace a continuación.
La especificación actual (informal) del protocolo está mayoritariamente congelada, pequeños cambios de modulo para eliminar la ambigüedad y abordar los casos extremos. No se tomarán en cuenta las sugerencias para nuevas funciones, ya que el protocolo está completo. En el futuro, el enfoque primordial del proyecto será hacer crecer la comunidad alrededor del protocolo, así como trabajar para traducir la especificación existente a una versión más precisa y formal, que pudiese ser considerada para prsentarse a los organismos de estándares de Internet como IETF e IANA.
¡Ni por un minuto! Ninguno de los involucrados en Gemini quiere destruir el Gopherspace. Gemini no pretende reemplazar a Gopher ni a la web, sino que quiere coexistir pacíficamente con ellos como otra opción que las personas pueden elegir libremente si les funciona. De la misma forma en que actualmente algunas personas ofrecen el mismo contenido a través de Gopher y la web, las personas podrán "bihostear" o "trihostear" contenido en cualquier combinación de protocolos que consideren que ofrece la mejor opción para sus requisitos técnicos, filosóficos y estéticos, y los de su público objetivo.
Es una referencia a la era previa al transbordador de los vuelos espaciales tripulados de Estados Unidos y constaba de tres proyectos. El primero fue el Proyecto Mercurio, que era una "prueba de concepto" bastante minimalista y parte de la carrera para llevar a un humano al espacio lo más pronto posible (la cual ganó la Unión Soviética con su proyecto Vostok). Mercurio era una cápsula para un solo hombre, sin la capacidad para adaptarse a su propia órbita después del despegue y solo un vuelo de Mercurio duró más de un día. El último fue el Proyecto Apolo, que era grande, pesado, complicado y caro pero que podía llevar a tres hombres a la luna y regresar.
El menos conocido para el público moderno, el Proyecto Gemini era el "hijo del medio": una cápsula para dos personas que podía reunirse y acoplarse con otras naves en órbita, podía despresurizarse y represurizarse en órbita para facilitar las caminatas espaciales, y cuyo vuelo más largo fue de casi dos semanas, más que cualquier misión Apolo. En cuanto al tamaño, peso y costo, Gemini era más parecido a Mercurio que de Apolo, pero en capacidades era al contrario - ¡incluso había planes (que nunca se relizaron) para hacer vuelos circunlunares de Gemini!
Con suerte, la analogía es obvia: Gopher es similar a Mercurio, y la web es similar a Apolo. Gemini quiere posicionarse entre los dos, haciendo más con menos.
Gemini (intencionalmente) no recibió un nombre que tuviera *nada* que ver con las ardillas (gophers), u otros roedores, o incluso con otros animales. Durante las primeras discusiones basadas en phlog, que eventualmente se convirtieron en el Proyecto Gemini, la falta de una redacción cuidadosa suponía que a veces no estaba claro si las personas estaban hablando de reemplazar Gopher directamente o añadir actualizaciones no oficiales que rompieran la compatibilidad en los clientes y servidores Gopher existentes. Cuando la discusión vaga se convirtió en un proyecto real, nos pareció acertado dar un mensaje más claro.
La página principal del Proyecto Gemini es el servidor gemini.circumlunar.space. Contiene la última versión de este documento de preguntas frecuentes, así como la especificación del protocolo, las mejores prácticas recomendadas y otra documentación oficial a través de Gemini, Gopher y HTTPS, en IPv4 e IPv6.
El debate oficial sobre Gemini sucede en una lista de correo:
Recomendamos a cualquier persona que ejecute un servidor Gemini o implemente un software de servidor o cliente Gemini a que se suscriba a la lista.
El debate casual sobre Gemini también se da en el canal #gemini en el servidor de IRC tilde.chat:
Los siguientes criterios se implementaron informalmente al inicio del proyecto. Es debatible que tanto se han cumplido algunos de estos objetivos, pero en general Gemini aún está muy cerca de este objetivo.
Gemini se esfuerza particularmente por simplificar la implementación del cliente. Los navegadores modernos son tan complicados que solo pueden ser desarrollados por proyectos muy grandes y costosos. Esto conduce naturalmente a una cantidad muy pequeña de navegadores casi monopolísticos, lo que ahoga la innovación y la diversidad y permite a los desarrolladores de estos navegadores dictar la dirección en la que evoluciona la web.
Gemini apunta a ser simple, pero no *demasiado* simple. Gopher es más simple a nivel de protocolo, pero como consecuencia el cliente es inseguro: ¿en qué codificación de caracteres se encuentra este texto? ¿Este texto es el contenido destinado o es un mensaje de error del servidor? ¿Qué tipo de archivo son estos datos binarios? Por esto, un cliente Gopher robusto se hace *menos* simple al necesitar inferir o adivinar la información ausente.
El debate de Gemini incluyó tres objetivos claros con respecto a la simplicidad:
Debería de ser posible para alguien que no participó en el diseño del protocolo, mantener con precisión la especificación completa del protocolo en su cabeza, después de leer una descripción bien escrita una o dos veces.
Un cliente básico pero utilizable (no ultra-espartano) debe entrar fácilmente dentro de unas 50 o más líneas de código, en un lenguaje moderno de alto nivel. Ciertamente no más de 100.
Un cliente apto para el uso diario que implemente cada función del protocolo debería ser un proyecto de programación factible en un fin de semana para un solo desarrollador.
El punto al que se han cumplido estos objetivos es debatible. Los experimentos sugieren que un cliente interactivo muy básico toma más como un mínimo de 100 líneas de código, un ajuste cómodo y una completitud moderada de características necesitan más de 200 líneas. Pero Gemini todavía parece estar en el estadio de esos objetivos.
Gemini está diseñado con una conciencia aguda de que la web moderna es un desastre de privacidad y que el Internet no es un lugar seguro para el texto sin formato. Cosas como las huellas dactilares del navegador y las "supercookies" basadas en Etag son una advertencia importante: el seguimiento de los usuarios puede y se colará por la puerta trasera, utilizando funciones de protocolo que no fueron diseñadas para facilitarlo. Por eso, los diseñadores de protocolos no solo deben evitar diseñar funciones de seguimiento (lo cual es fácil), sino que también deben asumir una intención maliciosa activa y evitar diseñar cualquier cosa que pueda ser alterada para proporcionar un seguimiento efectivo. Esta inquietud se manifiesta como una no extensibilidad deliberada en muchas partes del protocolo Gemini.
La aplicación de "primera clase" de Gemini es el consumo humano de material predominantemente escrito, para facilitar algo como el gopherspace o un "espacio web razonable" (por ejemplo, algo que se pueda usar fácilmente en Lynx o Dillo). Pero, al igual que HTTP puede usarse, y se usa, para mucho más que para gestionar HTML, Gemini debería poder usarse para tantos otros propósitos como sea posible, sin comprometer los criterios de simplicidad y privacidad anteriores. Esto significa tener en cuenta las posibles aplicaciones creadas alrededor de los archivos que no son de texto y clientes no humanos.
Gemini permite:
El uso inequívoco de grupos de caracteres arbitrarios no ASCII.
Identificar el contenido binario usando tipos MIME, en lugar de un pequeño conjunto de tipos de elementos muy desactualizados.
Distinguir claramente las transacciones exitosas de las fallidas.
Vincularse a recursos servidos a través de otros protocolos a través de URL simples, sin trucos.
Redirigir para evitar vínculos rotos cuando el contenido se mueve o se reorganiza.
Alojamiento virtual basado en dominios.
El cliente ajusta el texto de los documentos Gemini para que entre en la ventana gráfica del dispositivo, en lugar de "ajustarlo" a ~80 caracteres con caracteres de línea nueva. Esto significa que el contenido se muestra igual de bien en teléfonos, tabletas, computadoras portátiles y de escritorio.
Gemini elimina la estricta dicotomía directorio/texto de Gopher y te permite colocar enlaces en prosa.
Gemini exige el uso de cifrado TLS.
Los hábitos de uso moderno en la flogosfera sugieren que muchos piensan que sí. Un número cada vez mayor de usuarios ofrecen contenido que es casi totalimente texto como el elemento de tipo 1, de manera que pueden introducir una cantidad relativamente pequeña de enlaces "en línea" a otro contenido de Gopher, proporcionando una apariencia de hipervínculo de HTML, algo totalmente razonable e inofensivo de hacer. Lo mejor que pueden hacer los autores de contenido de Gopher (sin adoptar este enfoque), es pegar una lista de URL en la parte inferior de su documento, para que sus lectores las copien y peguen manualmente en su cliente. Esta no es una experiencia de usuario agradable. Pero forzar hipervínculos en Gopher de esta manera, no es solo un abuso de la semántica del protocolo Gopher, también es un modo muy ineficiente de gestionar texto, porque cada línea debe tener un elemento de tipo 1 y un selector falso, nombre de host y puerto transmitido junto con este para hacer un menú Gopher válido. Todos y cada uno de los reclamos de simplicidad y belleza que Gopher podría tener, son destruidos por esto. Gemini adopta el enfoque simple de dejar que las personas introduzcan tantos o tan pocos enlaces como prefieran en el contenido del texto, con una sobrecarga muy baja, pero conservando la limitación de un enlace por línea de Gopher, que resulta en una organización de contenido limpia, similar a una lista. Es difícil ver esto como algo más que una mejora.
Claro, si realmente prefieres el método Gopher, nada en Gemini te impide duplicarlo. Puedes servir contenido de tipo 0 con un tipo MIME de texto/sin formato, y puedes escribir documentos de text/gemini, donde cada línea es una línea de enlace, replicando la apariencia de un menú Gopher que teme RFC1436 sin ese molesto tipo de artículo no estándar 1.
Gemini no contiene un equivalente de los títulos Agente de Usuario o Referente, y el formato de solicitud no es extensible, por lo que estos no se pueden encajar después. De hecho, las solicitudes de Gemini solo contienen la URL del recurso solicitado. Esto ayuda en gran parte a evitar el rastreo de usuarios.
El "tipo de contenido nativo" de Gemini (análogo a HTML para HTTP (S) o texto sin formato para Gopher) nunca requiere transacciones de red adicionales (no hay imágenes en línea, hojas de estilo externas, fuentes o guiones, ni iFrames, etc.) . Esto permite una navegación rápida, inclusive en conexiones lentas y un conocimiento completo y control sobre a qué hosts se realizan las conexiones.
El tipo de contenido nativo de Gemini es estrictamente un documento, sin habilidad de crear guiones, permitiendo una navegación sencilla incluso en computadoras antiguas con velocidad de procesador o memoria limitadas.
Muchos está confundidos sobre por qué vale la pena crear un nuevo protocolo para abordar los problemas percibidos con características opcionales y no esenciales de la web. El hecho de que los sitios web *puedan* rastrear a los usuarios y ejecutar Javsacript que acapara la CPU y obtener imágenes inútiles de título de varios megabytes o incluso videos de reproducción automática, no significa que *tengan* que hacerlo. ¿Por qué no simplemente crear sitios web no malignos usando la tecnología existente?
Claramente esto es posible. "La experiencia Gemini" es equivalente a HTTP donde el único título de solicitud es "Host" y el único título de respuesta es "Content-type" y HTML donde las únicas etiquetas son <p>, <pre>, <a>, <h1> a través de <h3>, <ul> y <li> y <blockquote> - y el sitio web https://gemini.circumlunar.space prácticamente ofrece esta experiencia. Sabemos que es factible.
El problema es que decidir sobre un subconjunto estrictamente limitado de HTTP y HTML, ponerle una etiqueta y terminarlo, casi no haría nada para crear un espacio claramente delimitado, donde las personas pueden ir a consumir *solo* ese tipo de contenido *únicamente* de esa forma. Es imposible saber de antemano si lo que está al otro lado de una URL https:// estará dentro del subconjunto o fuera de él. Es muy tedioso verificar si un sitio web que proclama usar únicamente el subconjunto realmente lo hace, ya que muchas de las funciones que queremos evitar son invisibles (¡pero no inofensivas!) para el usuario. Es difícil o incluso imposible desactivar el soporte de todas las funciones no deseadas en los navegadores corrientes, por lo que si alguien rompe las reglas, tú pagarás las consecuencias. Escribir un navegador web simplificado que ignore con gracia todas las funciones no deseadas es mucho más difícil que escribir un cliente Gemini desde el principio. Incluso si lo hicieras, te resultaría muy difícil descubrir la pequeña fracción de sitios web que podría interpretar.
Los protocolos alternativos de diseño simple como Gopher y Gemini crean espacios alternativos de diseño simple con límites obvios y restricciones estrictas. Sabes con certeza que cuando ingresas al Geminispace, y sabes de antemano cuando seguir un determinado enlace hará que lo abandones. Mientras estás allí, sabes que todos los demás manejan las mismas reglas. Puedes relajarte y continuar navegando, y seguir enlaces a sitios de los que nunca has escuchado, que surgieron ayer, y tener la confianza de que no intentarán rastrearte o tirarte basura, porque *no pueden*. Puedes hacer todo esto con un cliente que escribiste tú mismo, por lo que *sabes* que puedes confiar en él. Es una experiencia muy diferente, mucho más liberadora y mucho más empoderadora que tratar de crear un sub-sub-sub-sub-subespacio diminuto e invisible de la web.
¡Por supuesto!
Gemini no permite el almacenamiento en caché, la compresión o la reanudación de descargas interrumpidas. Por lo cual, no es muy adecuado para distribuir archivos grandes, que dependen de la velocidad y fiabilidad de tu conexión de internet.
Algunas personas están molestas porque el requisito de TLS significa que necesitan usar una biblioteca TLS para escribir código Gemini, mientras que Gopher les permite un control total escribiendo todo desde cero.
Claro, incluso un cliente Gopher "desde cero" en realidad depende crucialmente de miles de líneas de código complicado escrito por otras personas, para proporcionar un conjunto de IP, un sistema de resolución de DNS y un sistema de archivos que funcionen. Usar una biblioteca TLS para proporcionar una implementación confiable de la criptografía es algo distinto.
Gemini también convierte los certificados de cliente TLS (que rara vez se ven en la web) en uno de primera clase con señalización en banda de su requisito. Esto permite restringir el acceso a los recursos de Gemini a ciertas partes, o establecer voluntariamente "sesiones" con aplicaciones del lado del servidor, sin tener que aprobar cookies, contraseñas, tokens de autenticación o cualquier otra cosa a la que estés acostumbrado. Está mucho más cerca de la noción de "claves autorizadas" de SSH y es un enfoque mucho más simple para la autenticación de usuarios.
TLS no está exento de defectos, pero:
Hay enlaces a bibliotecas TLS disponibles para casi todos los lenguajes de programación existentes
Muchos desarrolladores ya están parcialmente familiarizados con TLS y no necesitan aprender nada nuevo para implementar Gemini.
La mayoría de los usuarios ya confían en TLS para proteger su navegación web y correo electrónico y no necesitan decidir si quieren confiar o no en alguna tecnología desconocida para empezar a usar Gemini.
TLS es un estándar industrial profundamente arraigado, cuya definición e implementaciones continuarán siendo analizadas y mejoradas por los expertos en seguridad en el futuro previsible, y ese trabajo se dará por razones totalmente ajenas a Gemini - tiene mucho sentido que un pequeño proyecto haga un "freeride" como este.
El marcado de text/gemini se basa en gran medida en Markdown, lo que podría hacer que algunas personas se pregunten "¿Por qué no usar Markdown como el tipo de medio predeterminado para Gemini? Claramente es complicado de implementar, pero como TLS, hay muchas bibliotecas disponibles en todos los idiomas principales". Las razones para no seguir esta ruta incluyen:
Existen muchas variantes ligeramente diferentes e incompatibles de Markdown, por lo que, a diferencia de TLS, no se garantiza que todas las bibliotecas se comporten de forma parecida.
La gran mayoría de las bibliotecas de Markdown en realidad no hacen nada más que convertir Markdown a HTML, que para un cliente Gemini es un formato intermedio innecesario y es más pesado que el original.
Muchas variantes de Markdown admiten funciones que no se desean en Gemini, como por ejemplo las imágenes en línea.
El deseo de preservar el requisito de Gopher de "un enlace por línea" con el argumento de que promueve diseños de sitios sumamente limpios.
Desde luego, es posible gestionar Markdown sobre Gemini. La inclusión de un tipo de medio de texto/Markdown en el título de respuesta permitirá que los clientes más avanzados lo admitan.
Debido a que text/gemini es un formato completamente nuevo definido desde cero para Gemini, los autores del cliente normalmente necesitarán escribir su propio código para analizar y renderizar el formato desde cero, sin poder fiarse de la implementación de biblioteca preexistente y aprobada. Por lo tanto, es importante que el formato sea muy fácil de manejar correctamente. El formato basado en líneas donde las líneas de texto y las líneas de enlace son conceptos separados logra esto. No hay necesidad de que los clientes escaneen cada línea carácter por carácter, examinando la presencia de alguna sintaxis de enlace especial. Incluso la sintaxis de enlace especial más simple introduce la posibilidad de una sintaxis mal formada, contra la cual los clientes tendrían que estar protegidos, y tiene casos extremos cuyo manejo debería abordarse explícitamente en la especificación del protocolo (lo que lleva a una especificación más larga y tediosa que es menos divertida de leer y más difícil de mantener en la mente), o se deja sin definir (lo que genera un comportamiento inconsistente en diferentes clientes). Aunque los enlaces en línea pueden ser un ajuste más natural para algunos tipos de contenido, no valen la complejidad y fragilidad que inevitablemente introducirían en el protocolo.
Es cierto que necesitas cambiar un poco tu forma de pensar para acostumbrarte al estilo de escritura de un enlace por línea, pero se vuelve más fácil con el tiempo. El estilo también tiene sus beneficios. Incentiva a incluir solo los enlaces más importantes o relevantes, organizar los enlaces en listas relacionadas y dar a cada enlace una etiqueta descriptiva máxima sin tener que preocuparte de si esa etiqueta encaja o no en el flujo del texto principal.
Algunas personas han expresado su deseo de algo similar a CSS en Gemini. Si bien es cierto que se podría diseñar fácilmente algo mucho más simple y liviano que CSS, Gemini sostiene la posición de que el estilo visual del contenido de Gemini debe estar bajo el control exclusivo y directo del lector, no del escritor. No todo el mundo tiene el mismo gusto en colores y fuentes, y ninguna forma única de diseñar una página será óptima para todos los lectores, dispositivos y condiciones de iluminación. Hay mucho más en juego aquí que la división de la preferencia por el texto oscuro sobre un fondo claro o viceversa. Por ejemplo, las personas con discapacidades de lectura como la dislexia, pueden beneficiarse enormemente del uso de fuentes de diseño especial. Un sistema de estilo de "talla única" en el que el contenido se ve igual en todas partes garantiza un rendimiento deficiente para muchas personas. Un sistema de estilo más complicado que puede especificar diferentes estilos para diferentes dispositivos y contextos, le da a cada autor individual la tarea de asegurarse de que su cápsula sea útil en todas partes. La experiencia de la web sugiere que los problemas de accesibilidad a menudo serán un suceso tardío en el mejor de los casos. Es mucho más simple, y de hecho mucho más liberador para los autores de contenido, dejar que el contenido sea eso únicamente y dejar el estilo al cliente. Algunos clientes de Gemini pueden parecer aburridos y corrientes, pero no hay razón para que esto sea así. Si hay demanda de clientes con una versión de fuentes de alta calidad y una tipografía hermosa, dichos clientes eventualmente se desarrollarán, y cuando lo sean, los usuarios que valoren eso pueden disfrutar de la experiencia de lectura en cualquier lugar del Geminispace, incluso cuando leen contenido escrito por autores a los que no les importa el estilo.
La no extensibilidad del protocolo fue un principio de diseño importante para Gemini. Cosas como cookies, Etags y otras herramientas de rastreo no estaban presentes en el diseño original de HTTP, pero podrían agregarse sin problemas más adelante porque el formato de respuesta HTTP es abierto y permite la integración fácil de nuevos títulos. Para minimizar el riesgo de que Gemini se transforme lentamente en algo más parecido a una web, se decidió incluir una pieza de información en el título de respuesta para solicitudes exitosas. Incluir dos piezas de información con un delimitador específico, proporcionaría una ruta muy obvia para agregar posteriormente una tercera pieza; simplemente usa el mismo delimitador nuevamente. Básicamente, no hay una posición estable entre una pieza de información y muchas piezas de información arbitrariamente, por lo que Gemini se apega con fuerza a la primera opción, incluso si eso significa tener que sacrificar alguna funcionalidad agradable y aparentemente inofensiva. Dada esta restricción, incluir solo un equivalente de Content-type parecía claramente más útil que incluir solo un equivalente de Content-length. Lo mismo ocurre con otros títulos HTTP inofensivos y útiles, como Last-Modified.
Gopher tampoco tiene equivalente al título de Content-length, y esto no ha demostrado ser un obstáculo práctico en Gopherspace.
Incluso sin este título, es posible (a diferencia de Gopher) que los clientes distingan entre una transacción de Gemini que se ha completado con éxito y una que se ha abandonado a mitad de la transferencia debido a una falla en la red o un ataque malintencionado a través de la presencia o ausencia de un mensaje de apagado de TLS.
Es cierto que la incapacidad de los clientes para decirles a los usuarios cuánto más de un archivo grande aún debe descargarse y estimar cuánto tiempo puede llevar, significa que Gemini no puede proporcionar una experiencia apta al usuario que realice descargas de archivos grandes. Sin embargo, este sería el caso incluso si se especificara la longitud del contenido, ya que dicha experiencia también requeriría que se agreguen otras complicaciones al protocolo, por ejemplo la capacidad de reanudar las descargas interrumpidas. Por supuesto, los documentos de Gemini pueden vincularse directamente a recursos alojados a través de HTTPS, BitTorrent, IPFS, DAT, etc. y esta puede ser la mejor opción para archivos muy grandes.
Esto solo sería útil si hubiera planes para actualizar a un "Gemini 2.0" en el futuro, ¡y no los hay! Gemini es una reacción de "menos es más" contra los navegadores web y los servidores que se vuelven demasiado complicados y demasiado poderosos. No tiene sentido planear agregar más funciones a Gemini más adelante. En cambio, el plan es "hacerlo bien la primera vez", tanto como sea posible, y luego congelar la especificación del protocolo para siempre, sin actualizaciones, mejoras o extensiones.
Esto puede parecer radical o imprudente, pero somos cautelosamente optimistas. La especificación de Gopher no se ha cambiado en unos 30 años, y solo una pequeña cantidad de cambios no oficiales bastante pequeños a esa especificación son de uso común en el Gopherspace actual, que en realidad está creciendo en popularidad. Gemini combina primicias de Internet maduras y ubicuas como URI, tipos de medios MIME y TLS de una manera muy sencilla, y busca fomentar una cultura de trabajo interno, e incluso abarcar, limitaciones cuidadosamente elegidas, en lugar de eliminar cada restricción ya esto hace todo posible. Hay muchas cosas para las que Gemini es útil y bueno en este momento, y no hay razón para pensar que no lo será en algunas décadas.
Gopher es tan simple que las computadoras de los años 80 o 90 pueden implementar fácilmente el protocolo, y para algunas personas esta es una de las grandes virtudes de Gopher. El requisito de TLS de Gemini lo limita a máquinas más modernas.
Las máquinas antiguas son increíbles, mantenerlas en funcionamiento y en línea durante el mayor tiempo posible es algo increíble. Pero tampoco tiene sentido que la gran mayoría de los usuarios de Internet sacrifiquen toda la protección de la privacidad para facilitar esto. Sin embargo, recuerda que Gemini no tiene como objetivo reemplazar a Gopher, por lo que el Internet retrocompatible no está en peligro. De hecho, se recomienda a las personas que brindan contenido a través de Gopher que comiencen a hacerlo simultáneamente a través de Gemini. Los fanáticos de la retrocomputación pueden continuar accediendo al contenido a través de Gopher, mientras que los usuarios de computadoras modernas, que lo deseen, pueden cambiar a Gemini y obtener algunos beneficios.
La forma de menor compromiso para explorar Geminispace es usar un proxy web o "portal", como los siguientes:
Esto te permitirá usar tu navegador web habitual para explorar Geminispace. Si te gusta lo que ves, tal vez quieras considerar instalar un cliente Gemini dedicado, que normalmente ofrecerá una experiencia de navegación mejor y más completa. Puedes encontrar una lista de clientes (y otro software) en el enlace a continuación. ¡Incluso hay clientes disponibles para plataformas móviles como Android e iOS!.
Si tienes instalado un cliente ssh, puedes probar algunos clientes de terminal sin instalarlos ejecutando:
> ssh kiosk@gemini.circumlunar.space
¡Este kiosco de Gemini se inspiró en el kiosco de Gopher en bitreich.org!
Por el momento, Geminispace todavía es lo suficientemente pequeño como para que sea factible usar directorios como una forma de descubrir lo que hay fuera. Algunos de estos se enumeran a continuación:
Si buscas algo en particular, Gemini tiene un motor de búsqueda:
Hay dos agregadores públicos que tratan de facilitar la búsqueda de material recientemente actualizado en Geminispace:
Una opción es configurar tu propio servidor Gemini en un VPS o una computadora en tu casa (los SBC pequeños como RaspberryPi son perfectamente capaces de actuar como servidores Gemini). Existe una amplia gama de softwares de servidor disponible:
Alternativamente, puedes encontrar otro sitio para hospedar tu contenido para ti. El hospedaje Gemini también está disponible a través de estos proveedores:
Varias comunidades "pubnix" o "tilde" (sistemas unix multiusuario en los que los usuarios interactúan entre sí mediante la conexión y el uso de aplicaciones locales de correo electrónico, chat y BBS) también ofrecen hospedaje Gemini (normalmente junto con hospedaje web y/o Gopher). Tal vez puedas obtener una cuenta de una de las comunidades que se enumeran a continuación. Ten en cuenta que la mayoría de estas comunidades son más antiguas que el propio Gemini y pueden enfocarse en otros servicios o pueden ser específicas de un tema o interés en particular. Explora tus opciones cuidadosamente y únete a algún lugar en el que creas que podrías encajar bien, en lugar de tratar estos pequeños mundos como espacio libre para tirar tus cosas.
Si perteneces a una comunidad de pubnix que no ofrece hospedaje Gemini, no está de más preguntarle a los administradores si están interesados en agregar este servicio.
Si estás cómodo con las tecnologías necesarias para hacer uso del hospedaje pubnix (ssh o sftp, editores de texto de terminal, permisos de archivos unix, etc.), puedes obtener cuentas gratuitas en los servicios a continuación (que te permitirán mantener una cápsula a través de un aplicación web):
Considera unirte a la lista de correo (mira la pregunta 1.3) para que puedas anunciar tu nuevo servidor a la comunidad y mantenerte al día, por ejemplo, actualizaciones al software de tu servidor o al propio protocolo Gemini.
Puedes enviar la URL de tu servidor al motor de búsqueda geminispace.info para que sea rastreada, a través de este enlace:
Gemini ya tiene una gran cantidad de implementaciones de clientes y servidores, lo que no quiere decir que otras no sean bienvenidas, pero la escasez real en este momento no es de software sino de contenido. Mientras más cosas interesantes y emocionantes encuentren las personas en Geminispace, es más probable que quieran agregar contenido propio. Por tanto, la mayor contribución que puedes hacer al proyecto es formar parte de este proceso. Consulta la pregunta 3.3 para obtener detalles sobre cómo incluir tu contenido en Geminispace.
Si tienes las habilidades técnicas necesarias, puedes hacer una contribución importante al crecimiento de Geminispace, proporcionando un servicio de hospedaje que las personas pueden usar para publicar contenido propio. Esto puede ser tan simple como configurar cuentas de usuario únicamente sftp en un VPS. Ofrecer hospedaje no tiene por qué ser un gran compromiso. Puedes usar los servicios VPS más baratos que se ofrecen para hospedar cómodamente a una docena de usuarios. Una gran cantidad de hosts, donde cada uno sirve el contenido de una cantidad relativamente pequeña de usuarios, es un ecosistema mucho más robusto y sostenible que una pequeña cantidad de servidores, donde cada uno alberga cientos o miles de usuarios.
Si realmente quieres escribir algún software, una herramienta poderosa para expandir Geminispace, podría ser una sola pieza de software que proporcione simultáneamente un servidor Gemini y un modo para que múltiples usuarios administren fácilmente el contenido provisto por dicho servidor, por ejemplo, a través de una interfaz web interactiva o enviando correos electrónicos llenos de contenido; Algo como los servicios Gemlog Blue y Flounder (mira la pregunta 3.3), pero empaquetados y documentados de manera que sea fácil para las personas desplegar y personalizar sus propios sitios multiusuario, como por ejemplo una instancia de Mastodon.
También puedes contribuir al proyecto con correcciones y adiciones o traducciones del sitio oficial y la documentación (mira las preguntas 4.2 y 4.3).
Toda la documentación alojada en gemini.circumlunar.space, incluidas las preguntas frecuentes que estás leyendo, se encuentra en un único repositorio de git, que tiene acceso de lectura exclusiva abierto al público. Puedes clonar el repositorio de esta forma:
> git clone git://gemini.circumlunar.space/gemini-site
Luego, haz los cambios sugeridos en los archivos relevantes (la estructura de las URL refleja exactamente la estructura del repositorio, por ejemplo, gemini://gemini.circumlunar.space/docs/faq.gmi se encuentra en docs/faq.gmi en el repositorio). Confirma los cambios con mensajes de confirmación (asegúrate de establecer tu nombre y dirección de correo electrónico para que la gente pueda ver quién hizo el trabajo), con una confirmación por cambio conceptual. Después tienes dos opciones para enviar tu trabajo.
Si tienes configurado el comando send-email de git (a continuación hay un enlace a un tutorial), puedes enviar por correo electrónico parches que contengan tus confirmaciones a <solderpunk _at_ posteo _dot_ net> con un solo comando. De lo contrario, puedes simplemente ejecutar:
> git format-patch origin
para crear un conjunto de archivos de parche, que puedas adjuntar manualmente a un correo electrónico usando el cliente de correo ordinario de tu elección.
¡Gracias por tu ayuda! Ser voluntario para traducir documentación es una forma maravillosa de ayudar al proyecto.
Para hacerlo, primero clona el repositorio de git como se describe en la pregunta 4.2. Cambia al directorio `doc` del repositorio y crea un nuevo subdirectorio con el código ISO 639-1 de dos letras de tu idioma, por ejemplo, las traducciones finlandesas deben estar en `doc/fi/`, las traducciones japonesas en `doc/ja/`, etc. Puedes encontrar la lista completa de códigos en Wikipedia a continuación. Si estás traduciendo a una variante de un idioma específica de la región, puedes usar códigos de estilo RFC4646 en su lugar, por ejemplo, pt-PT o pt-BR respectivamente, para el portugués que se habla en Portugal o Brasil.
Para cada archivo en inglés que se encuentre en `doc` que quieras traducir, crea un archivo correspondiente en el subdirectorio de tu idioma. Está bien cambiar el nombre del archivo como parte de la traducción, por ejemplo, la traducción alemana de `doc/specifics.gmi` podría llamarse` doc/spezifikation.gmi`. Puedes traducir tantos archivos en `doc` en tanto tengas tiempo y energía. ¡No dudes en enviar traducciones parciales! Una vez que alguien que hable el mismo idioma vea tu esfuerzo, podría proporcionar parte o todo lo que falta. Tener parte del contenido traducido es mejor que nada.
Una vez que hayas terminado, copia el archivo `doc/index.gmi` y modifícalo para que coincida con los nombres de archivo y títulos de documentos traducidos, y elimina los enlaces de los documentos originales que aún no hayas traducido.
Finalmente, actualiza `doc/translations.gmi` para incluir un enlace a tu nuevo subdirectorio.
Agrega tus traducciones al repositorio y envía a Solderpunk el parche como se describe en la pregunta 4.2.
-- Response ended
-- Page fetched on Mon May 20 00:03:55 2024