💾 Archived View for geminiprotocol.net › docs › pt-PT › faq.gmi captured on 2023-11-14 at 07:52:46. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
Última atualização: 21/02/2021
O Gemini é um novo protocolo de Internet de nível aplicacional, para distribuição de ficheiros arbitrários, que tem em conta requisitos especiais com o objetivo de servir um formato de hipertexto leve e que facilite a vinculação entre ficheiros. Dependendo da perspetiva, o protocolo Gemini pode ser entendido como "a web despojada e de volta à sua essência" ou como o "Gopher aprimorado e um pouco mais modernizado" (talvez a última analogia seja mais precisa). O protocolo Gemini pode ser apelativo para pessoas que:
O protocolo Gemini foi pensado com base na simplicidade, mas não necessariamente para ser o mais simples possível. Assim, o seu desenho foi concebido para maximizar a relação "tamanho-potencialidades", mantendo o seu tamanho dentro de limites aceitáveis. O protocolo Gemini foi também desenhado com outras preocupações, como por exemplo a privacidade, a dificuldade de expansibilidade futura (de forma a que *permaneça* simples e consciente da necessidade de privacidade) e a compatibilidade com um ethos de computação faça-você-mesmo. Por esta última razão, o Gemini é tecnicamente muito familiar e conservador: é um protocolo com base no paradigma tradicional de cliente-servidor-pedido-resposta e é construído com uma tecnologia madura e padronizada, de que é exemplo a utilização de URIs, tipos de media MIME e TLS.
O Projeto Gemini começou em junho de 2019 e, embora o protocolo em si esteja quase completo, o software disponível, os recursos e a comunidade ainda estão num estado de desenvolvimento relativamente inicial (embora próspero!).
O Projeto Gemini foi originalmente iniciado por Solderpunk <solderpunk _at_ posteo _dot_ net>, que continua a ser o seu Ditador Benevolente. No entanto, o protocolo foi desenvolvido em colaboração com uma comunidade livre e informal de vários interessados, que se articulou por meio de e-mails, mensagens no Gopher (a chamada "phlogosfera") e toots no Fediverse. Partes significativas do protocolo foram trabalhadas por várias pessoas, motivo pelo qual o Gemini não deve ser considerado o trabalho de uma só pessoa.
É difícil saber qual a sua exata dimensão. Contabilizar o número de diferentes nomes de servidores Gemini pode ter como consequência uma sobrevalorização do seu tamanho, já que alguns sites multiutilizador atribuem a cada utilizador o seu próprio subdomínio. Por outro lado, contar os endereços IP únicos pode funcionar ao contrário, subestimando o seu tamanho, uma vez que o Gemini permite que vários domínios diferentes sejam servidos a partir do mesmo IP. Em qualquer dos casos, no início de 2021 eram conhecidos cerca de 200 mil URLs Gemini, espalhados por cerca de 750 "cápsulas" (o termo da comunidade Gemini para "sites"), 500 domínios e 600 endereços IP. No entanto, a utilização do Gemini está a registar um rápido crescimento. As estatísticas mais recentes podem ser consultadas no link abaixo.
Estatísticas do Geminispace fornecidas pelo rastreador "Lupa" de Stéphane Bortzmeyer
A especificação atual (informal) do protocolo está em grande parte congelada, se não considerarmos as pequenas mudanças para remover ambiguidade e lidar com casos limite. Não serão consideradas sugestões de novos recursos, pois considera-se que o protocolo, tal como existe, é um recurso completo. A partir de agora, o foco principal do projeto é fazer com que a comunidade em torno do protocolo cresça, e ao mesmo tempo trabalhar para que a especificação existente se traduza numa versão mais precisa e formal, que possa ser considerada como pronta para ser enviada a organismos de padrões da Internet, como a IETF ou a IANA.
Não, de todo! Nenhum dos envolvidos no Gemini tem intenções de substituir a web, nem tampouco de destruir o Gopherspace. O Gemini não pretende substituir o Gopher ou a web, mas coexistir pacificamente ao lado destes como mais uma opção que as pessoas podem escolher e usar livremente, se lhes for conveniente. Assim como há pessoas que atualmente oferecem o mesmo conteúdo no gopher e na web, qualquer um de nós tem a possibilidade de fazer "bihost" ou "trihost" de conteúdo, utilizando a combinação de protocolos que melhor se ajuste aos seus requisitos técnicos, filosóficos e estéticos, bem como àqueles do público-alvo.
O nome Gemini é uma referência ao período anterior à era dos Shuttle, veículos utilizados nos voos espaciais tripulados dos Estados Unidos, e que foi marcado por três projetos. O primeiro, o Projeto Mercury, foi uma "prova de conceito" bastante minimalista e parte da estratégia na corrida para colocar, o mais rapidamente possível, um humano no espaço (corrida ganha pela União Soviética, com o seu projeto Vostok). A Mercury foi uma cápsula construída para apenas um tripulante, sem capacidade de se ajustar à sua própria órbita após o lançamento. Apenas um voo Mercury durou mais do que um dia. O último foi o Projeto Apollo, que era grande, pesado, complicado e caro, mas podia levar três homens à lua e voltar.
Menos conhecido do público moderno, o Projeto Gemini era o "filho do meio": uma cápsula de duas pessoas que, em órbita, podia acoplar com outra nave e ser despressurizada e repressurizada, de forma a facilitar passeios espaciais. Podia também voar durante quase duas semanas - mais do que qualquer missão Apollo! Em termos de tamanho, peso e custo, a Gemini tinha mais afinidade com a Mercury do que com a Apollo, embora em termos de capacidades fosse o oposto - havia até planos (que nunca aconteceram) para fazer voos circum-lunares Gemini!
Queremos acreditar que a analogia é óbvia: o Gopher é semelhante à Mercury, e a web é semelhante à Apollo. O Gemini espera poder posicionar-se entre os dois, fazendo mais com menos.
O Gemini, deliberadamente, não recebeu um nome que tivesse *qualquer coisa* a ver com esquilos, ou outros roedores, ou mesmo outros animais. Durante as primeiras discussões ocorridas no universo phlog, que eventualmente evoluíram para o Projeto Gemini, a falta de uma redação cuidadosa significava que, por vezes, não era claro se as pessoas se queriam referir à substituição do Gopher por completo ou apenas à adição de atualizações não oficiais que quebrassem a compatibilidade nos clientes e servidores Gopher já existentes. Quando a discussão latente se transformou num projeto real, revelou-se sensato enviar uma mensagem mais clara.
A casa oficial do Projeto Gemini pode ser visitada no servidor gemini.circumlunar.space. É nesse endereço que está a versão mais recente deste documento de FAQ, bem como a especificação do protocolo, as práticas recomendadas e outras documentações oficiais, que podem ser consultadas via Gemini, Gopher e HTTPS, em IPv4 e IPv6.
A discussão oficial acerca do Gemini processa-se através de uma mailing list:
Inscreva-se na mailing list e aceda ao arquivo de mensagens através da web
Ver arquivo das mensagens através do Gemini
Encorajamos fortemente qualquer pessoa que tenha instalado um servidor Gemini, ou implementado um software cliente ou servidor para Gemini, a se inscrever na lista de discussão.
Discussões pontuais sobre Gemini também têm lugar no canal #gemini do servidor de IRC tilde.chat:
Enunciamos, seguidamente, os critérios que foram colocados em prática, de modo informal, no início do projeto. É discutível dizer-se que todos os objetivos foram cumpridos mas, de um modo geral, podemos dizer que o Gemini estará muito perto do modelo que foi definido inicialmente.
De um modo particular, o Gemini procura proporcionar a simplicidade de implementação do cliente. Os navegadores (browsers) modernos são tão complicados que só podem ser desenvolvidos por projetos caros e de grande dimensão. Esse facto leva, inevitavelmente, a que exista um número pequeno de navegadores, quase monopolistas, o que sufoca a inovação e a diversidade e torna os desenvolvedores desses navegadores nas pessoas que ditam a direção em que a web evolui.
O Gemini pretende ser simples, mas não *muito* simples. O Gopher é mais simples ao nível do protocolo, mas, como consequência, o cliente tem dúvidas para resolver: qual a codificação de carateres usada por este texto? Será este texto o conteúdo pretendido ou será uma mensagem de erro do servidor? Que tipo de ficheiro se adequa a estes dados binários? É por estes motivos que um cliente Gopher robusto se torna *menos* simples, pois ele precisa de inferir ou de adivinhar as informações em falta.
A discussão inicial sobre o Gemini incluía três objetivos claros em relação à sua simplicidade:
Podemos discutir até que ponto estes objetivos foram alcançados. A experiência diz que um cliente interativo muito básico tem mais de 100 linhas de código, e que o tamanho confortável para que seja alcançada uma utilização moderada dos recursos totaliza mais de 200 linhas. Ainda assim, o Gemini parece não andar muito longe dos objetivos iniciais.
O Gemini foi projetado com base numa vincada consciência de que a web moderna é um desastre de privacidade e que a internet não é um lugar seguro para a utilização de texto simples. Realidades como são os casos da impressão digital do navegador e dos "supercookies" baseados na etiqueta de identidade Etag devem servir-nos de advertência: o rastreamento do utilizador pode ser, e certamente será, efetuado através de uma backdoor, usando recursos de protocolo que não foram projetados para esse fim. Assim, quem define um protocolo não deve apenas evitar o acesso a recursos de rastreamento (extremamente acessíveis). Deve também partir do princípio que essa utilização maliciosa é uma realidade e fazer tudo para evitar conceber algo que possa ser subvertido de forma a ser utilizado para um rastreamento efetivo e eficaz. A preocupação com essas práticas reflete-se no facto de, em grande parte do protocolo Gemini, não ser possível a sua exploração maliciosa.
O objetivo primordial do Gemini é possibilitar aos seus utilizadores o consumo de material predominantemente escrito - simplificando, trata-se de proporcionar algo como o gopherspace ou o espaço da web vulgarmente designado por "razoável" (por exemplo, algo que pode ser usado confortavelmente no Lynx ou Dillo). Mas, do mesmo modo que o HTTP pode ser, e é, usado para muito mais do que servir HTML, o Gemini deve poder ser usado, tanto quanto possível, para muitos outros fins, sem comprometer a simplicidade e os critérios de privacidade que estão na sua génese. Isso significa ter em consideração as possíveis aplicações criadas com base em ficheiros não-texto e clientes não humanos.
O Gemini permite:
O texto contido nos documentos do Gemini é processado pelo cliente de forma a poder ajustar-se ao tamanho da janela de visualização do dispositivo, em vez de ser "agrupado" em cerca de 80 carateres, com recurso à introdução de carateres de nova linha. Isso significa que o conteúdo será corretamente exibido em telefones, tablets, laptops e desktops.
O Gemini acaba com a dicotomia estrita de diretório/texto do Gopher e permite inserir links no texto.
O Gemini exige a utilização de criptografia TLS.
Atualmente, os hábitos de utilização na phlogosfera parecem sugerir que muitas pessoas consideram essa dicotomia um defeito. Um número crescente de utilizadores está a servir conteúdo, quase inteiramente constituído por texto, como item do tipo 1, de forma a inserir um número relativamente pequeno de links "em linha" para outro conteúdo gopher, fornecendo alguma aparência de hiperlink de HTML - algo perfeitamente razoável e inofensivo de se querer fazer. Sem recorrer a esta abordagem, o melhor que os autores de conteúdo do Gopher podem fazer é colar uma lista de URLs na parte inferior dos seus documentos, de forma a que os seus leitores possam copiar e colar manualmente nos seus clientes. Esta não é exatamente uma experiência agradável para o utilizador. Mas forçar hiperlinks no Gopher desta forma não é apenas um abuso da semântica do protocolo Gopher, é também uma maneira surpreendentemente ineficiente de servir texto, pois cada linha tem que ter um tipo de item i e um seletor não-padrão, o nome do host e a porta transmitida para que possa ser um menu Gopher válido. Todas e quaisquer reivindicações de simplicidade e beleza que o Gopher possa ter são destruídas por este facto. O Gemini adota a abordagem simples de permitir que as pessoas insiram quantos links quiserem no seu conteúdo de texto, com uma sobrecarga extremamente baixa, mas mantém a limitação de um link por linha, como no Gopher, o que resulta numa organização limpa e semelhante a uma lista de conteúdo. É difícil não ver esta realidade como algo que não seja uma melhoria.
Se você gostar mesmo do funcionamento do Gopher, não há nada no Gemini que impeça a sua replicação. Você pode servir o conteúdo do tipo 0 com um tipo MIME de text/simples, e pode escrever documentos de text/gemini, onde cada linha é uma linha de link, replicando a aparência de um menu Gopher RFC1436 sem o incómodo do tipo não-standard de item padrão i.
O Gemini não contém nenhuma equivalência para os cabeçalhos User-Agent ou Referer. Como o formato do pedido não é expansível, estes não podem ser inseridos posteriormente. Na verdade, os pedidos do Gemini contêm apenas o URL do recurso solicitado, facto que contribui para impedir o rastreamento do utilizador.
O "tipo de conteúdo nativo" do Gemini (análogo ao HTML para HTTP (S) ou ao texto simples para Gopher) nunca requer transações de rede adicionais (não há imagens in-line, folhas de estilo externas, fontes ou scripts, iframes etc.). Esse facto permite uma navegação rápida, mesmo com conexões lentas, e total reconhecimento e controle em relação aos hospedeiros para os quais as conexões são feitas.
O tipo de conteúdo nativo do Gemini é estritamente um documento, sem nenhum recurso de script, permitindo uma navegação fácil, mesmo em computadores antigos com velocidades lentas de processamento ou memória limitada.
Muitas pessoas ficam confusas e questionam a pertinência da criação de um novo protocolo que se propõe resolver problemas conhecidos através de recursos opcionais e não essenciais da web. O facto dos sites *poderem* rastrear utilizadores, executar Javsacript que consome CPU e obter imagens de cabeçalho de vários megabytes inúteis ou até mesmo vídeos de reprodução automática maiores, não significa que eles *tenham* que o fazer. Então por que é que não se constroem sites que não sejam malignos, usando a tecnologia existente?
É evidente que isso é possível. "A experiência Gemini" é, grosso modo, equivalente ao HTTP, sendo que o único cabeçalho de pedido é "Host" e o único cabeçalho de resposta é "Content-type", e ao HTML, sendo que as únicas tags são <p>, <pre>, <a>, < h1> a <h3>, <ul> e <li> e <blockquote> - e o site https://gemini.circumlunar.space oferece praticamente essa experiência. Sim, nós sabemos que isso pode ser feito.
O problema é que decidir sobre um subconjunto estritamente limitado de HTTP e HTML, colocando-lhe um rótulo e dando o assunto por encerrado, não contribuiria em nada para a criação de um espaço claramente diferenciador, que as pessoas podem frequentar para consumir *apenas* esse tipo de conteúdo e *somente* desse modo. É impossível saber a priori se o que está do outro lado de um URL https:// estará dentro ou fora do subconjunto. É muito entediante ter que verificar se o que um site alega utilizar como subconjunto é realmente verdade, já que muitos dos recursos que queremos evitar são invisíveis (mas não inofensivos!) para o utilizador. É difícil, ou mesmo impossível, desativar o suporte para todos os recursos indesejados nos navegadores convencionais. Assim, se alguém quebrar as regras, é você quem pagará as consequências. Desenvolver um navegador da web simplificado, que ignore, de forma graciosa, todos os recursos indesejados é muito mais difícil do que desenvolver um cliente Gemini de raiz. Ainda que você se meta nessa aventura, a dificuldade em selecionar a fração minúscula de sites que o navegador poderá apresentar, sem erros, tornará a sua tarefa muito complicada.
Protocolos alternativos, como o Gopher ou o Gemini, criam espaços alternativos de conceção-simples, com limites óbvios e restrições rígidas. Você aperceber-se-á, sem dúvida, quando estiver a navegar no Geminispace e saberá, com certeza e previamente, quando determinado link o fizer sair dele. Enquanto você lá está, tem a certeza que todos os outros se regem pelas mesmas regras. Pode relaxar e continuar a navegação, seguir links de sites dos quais nunca ouviu falar, que surgiram ontem, e ter a certeza que eles não tentarão rastreá-lo ou enviar-lhe lixo, simplesmente porque *não podem*. Poderá fazer tudo isso com um cliente que você mesmo desenvolveu, motivo pelo qual você *sabe* que pode confiar nele. É uma experiência muito diferente, muito mais libertadora e muito mais poderosa do que tentar esculpir um sub-sub-sub-sub-sub-espaço minúsculo e invisível da web.
Naturalmente!
O Gemini não tem suporte para armazenamento em cache, compactação ou retoma de downloads interrompidos. Como tal, não é muito adequado para distribuir ficheiros de grande dimensão, sendo que "grande" é aqui algo que se relaciona com a velocidade e confiabilidade da sua ligação à rede.
Há pessoas incomodadas com o facto do requisito de TLS as obrigar a usar uma biblioteca TLS para escrever o código Gemini, enquanto que, no caso do Gopher, a inexistência dessa condicionante permite, de raiz, o seu total controle.
Ainda assim, um cliente Gopher "de raiz" depende, de forma crucial, de milhares de linhas de código complicado e escrito por terceiros, para que uma pilha IP funcional, um tradutor de DNS e um sistema de ficheiros sejam fornecidos. Usar uma biblioteca TLS para uma implementação confiável de criptografia é um pouco diferente.
O Gemini também transforma cada um dos certificados de cliente TLS - raramente vistos na web - num cidadão de primeira classe com anúncio em banda dos seus requisitos. Isso permite a restrição, a terceiros, do acesso aos recursos do Gemini, ou ou estabelecimento voluntário de "sessões" com aplicações de servidor, sem ter que passar cookies, senhas, tokens de autenticação ou qualquer outro método habitualmente utilizado. Está muito mais próximo da noção SSH de "chaves autorizadas" e é, na verdade, uma abordagem muito mais simples para autenticação do utilizador.
Certamente que o TLS tem os seus defeitos, contudo:
A sinalização feita através de text/gemini baseia-se muito no Markdown, o que pode levar algumas pessoas a colocarem a seguinte questão: "Por que não usar o Markdown como o tipo de media padrão para o Gemini? Claro que é complicado de implementar, mas, a exemplo do que acontece com o TLS, há muitas bibliotecas disponíveis nas principais linguagens de programação". As razões para não seguir esse caminho são as seguintes:
Claro que é possível servir Markdown em vez de Gemini. A inclusão de um tipo de media text/markdown no cabeçalho da resposta permitirá que clientes mais avançados o suportem.
Como o text/gemini é um formato totalmente novo, definido de raiz para o Gemini, os autores de clientes precisarão de escrever o seu próprio código para analisar e renderizar o formato a partir do zero, sem poder contar com uma implementação de biblioteca pré-existente e bem testada. Assim, é importante que o formato seja extremamente simples de manusear corretamente. O formato baseado numa filosofia de linha, em que as linhas de texto e as linhas de link são conceitos separados, permite essa simplicidade. Os clientes não necessitam de "varrer" cada uma das linhas, caratere por caratere, para testar a presença de alguma sintaxe de link especial. Mesmo a sintaxe de link especial mais simples introduz a possibilidade de sintaxe malformada, contra a qual seria necessária a robustez dos clientes. Casos extremos há cujo tratamento precisaria de ser explicitamente abordado na especificação do protocolo (levando a uma especificação mais longa e fastidiosa, menos divertida de ler e mais difícil de memorizar) ou ficar por definir (levando a um comportamento inconsistente em clientes diferentes). Embora os links in-line possam ser adequados para alguns tipos de conteúdo, eles simplesmente não compensam o aumento da complexidade e da fragilidade que seria introduzido no protocolo.
É verdade que é necessário mudar um pouco a forma de pensar para que nos acostumemos com o estilo de escrita de um link por linha, mas, com o tempo, isso traduzir-se-á num processo mais facilitado. O estilo também traz benefícios, pois incentiva a inclusão apenas dos links mais importantes ou relevantes, organizando links em listas relacionadas e dando a cada link uma descrição própria e autonomizada, sem que exista a preocupação dessa descrição se encaixar no fluxo do texto principal.
Algumas pessoas manifestaram o desejo de ter algo parecido com o CSS no Gemini. Embora algo muito mais simples e leve do que o CSS pudesse ser facilmente previsto, o Gemini advoga que o estilo visual do conteúdo deve ser controlado diretamente pelo leitor e não por quem produz o conteúdo. Nem todos têm o mesmo gosto quando se trata de cores e fontes, e não existe uma fórmula única de estilizar uma página de forma a torná-la ideal para todos os leitores, todos os dispositivos e todas as condições de iluminação. Há muito mais em jogo aqui do que a já clássica preferência entre texto escuro em fundo claro ou vice-versa. Pessoas com dificuldades de leitura, como a dislexia, podem beneficiar enormemente com o uso de, por exemplo, fontes especialmente desenhadas para um determinado fim. Um sistema de estilo simples, de "tamanho único", em que o conteúdo tem a mesma aparência em qualquer dispositivo, é garantidamente insatisfatório para muitas pessoas. Um sistema de estilização mais complicado, que pode prever diferentes estilos visuais para diferentes dispositivos e contextos, sobrecarregará os autores com a árdua tarefa de garantir que a sua cápsula (o nome que se dá aos sites em Gemini) possa ser visualizada em qualquer dispositivo. A experiência da web sugere que os problemas de acessibilidade serão, na melhor das hipóteses, uma reflexão a posteriori. É muito mais simples, e na verdade muito mais libertador para os autores de conteúdo, deixar o conteúdo ser apenas conteúdo e deixar o estilo para o cliente. Alguns clientes de Gemini podem parecer monótonos e aborrecidos, mas não há razão para que assim seja. Se houver procura por clientes com renderização de fontes de alta qualidade e bela tipografia, esses clientes, eventualmente, serão desenvolvidos - e quando assim acontecer, os utilizadores que valorizam esses aspetos poderão desfrutar dessa experiência de leitura em qualquer lugar no Geminispace, mesmo ao ler conteúdo escrito por autores que não tiveram preocupações com o estilo.
A não-expansibilidade do protocolo é uma das premissas do desenho conceptual do Gemini. Embora funcionalidades como cookies, Etags e outras ferramentas de rastreamento não estivessem presentes no design original do HTTP, elas acabaram por ser facilmente adicionadas mais tarde, uma vez que o formato de resposta HTTP é aberto e permite a fácil inclusão de novos cabeçalhos. Para minimizar o risco do Gemini sofrer uma lenta mutação para algo mais parecido com a web, foi decidido incluir uma e apenas uma informação no cabeçalho de resposta para pedidos bem-sucedidos. Incluir duas informações com um delimitador especificado forneceria um caminho muito óbvio para que, posteriormente, uma terceira parte pudesse ser adicionada - bastaria usar o mesmo delimitador novamente. Basicamente, não há uma posição estável entre um pedaço de informação e, de forma arbitrária, muitos pedaços de informação. Por esse motivo, o Gemini adere firmemente à primeira opção, mesmo que isso signifique sacrificar alguma funcionalidade agradável e aparentemente inofensiva. Dada essa restrição, incluir apenas uma equivalência de Content-type seria claramente mais útil do que incluir apenas uma equivalência de Content-length. O mesmo é verdadeiro para outros cabeçalhos HTTP inofensivos e úteis, como Last-Modified.
O Gopher também não tem uma equivalência para o cabeçalho Content-length, e isso não se provou ser um obstáculo prático no Gopherspace.
Mesmo sem este cabeçalho, é possível para os clientes (ao contrário do Gopher) distinguir entre uma transação Gemini que foi concluída com sucesso e uma que não se concluiu devido a uma falha de rede ou ataque malicioso. Isso é conseguido através da presença ou ausência de uma mensagem de shutdown TLS.
A incapacidade dos clientes para informarem os utilizadores acerca da quantidade de bytes que falta para descarregar um ficheiro, e de estimar o tempo que isso pode levar, faz com que o Gemini não constitua uma experiência muito amigável para quem pretende fazer downloads de ficheiros grandes. No entanto, o mesmo aconteceria se o Content-length fosse especificado, já que tal experiência também exigiria que maior complexidade fosse adicionada ao protocolo. A possibilidade de retomar downloads interrompidos é um exemplo dessa complexidade. Os documentos do Gemini podem ser vinculados diretamente a recursos hospedados via HTTPS, BitTorrent, IPFS, DAT, etc., e esta pode ser a melhor opção para mitigar os problemas associados ao manuseamento de ficheiros muito grandes.
Isso só seria útil se houvesse planos para o desenvolvimento de uma futura versão "Gemini 2.0" - e não há! A filosofia do Gemini é do tipo "menos é mais", contrariando a lógica de navegadores e servidores que se tornam muito complicados e poderosos. Não faz sentido adicionar mais funcionalidades ao Gemini do que as que atualmente existem. Em vez disso, o plano é "fazer tudo à primeira", tanto quanto possível, e, dessa forma, manter a especificação do protocolo congelada para sempre, sem atualizações, aprimoramentos ou extensões.
Esta é uma decisão que pode parecer radical ou imprudente, mas estamos cautelosamente otimistas. A especificação Gopher não sofre alterações há cerca de 30 anos, e em uso no Gopherspace, atualmente, existe apenas um número muito pequeno de pequenas alterações não oficiais a essa especificação. E não é por isso que o Gopher não está a crescer em popularidade. O Gemini combina, de uma forma muito direta, ideias primitivas da internet que estão no seu estado maduro e que são omnipresentes, como URIs, tipos de media MIME e TLS, ao mesmo tempo que procura promover uma cultura de trabalho que se concentre nas limitações que foram cuidadosamente escolhidas, abraçando-as, em vez de querer remover cada restrição que se coloque, como forma de tornar tudo possível. O Gemini é útil e adequado para muitas finalidades, não havendo razão para pensar que não será útil e bom nessas mesmas coisas daqui a décadas.
O Gopher é tão simples, que computadores dos anos 80 ou 90 podem facilmente implementar o protocolo. Para algumas pessoas esta é uma das suas grandes virtudes. O facto do Gemini ter requisitos de TLS, faz com que fique limitado a máquinas mais modernas.
As máquinas antigas são fantásticas. Mantê-las úteis e a funcionar, online, durante o maior tempo possível, é algo incrível de se fazer. Mas também não faz sentido para a grande maioria dos utilizadores da Internet sacrificar toda e qualquer proteção de privacidade para que isso seja possível. Lembre-se, porém, de que o Gemini não tem como objetivo substituir o Gopher. Logo, a internet retrocompatível não é por ele diretamente ameaçada. Na verdade, as pessoas que distribuem conteúdo via Gopher são agora fortemente encorajadas a, em simultâneo, começar a distribuir esse mesmo conteúdo via Gemini. Os fãs da retrocomputação podem continuar a aceder ao conteúdo via Gopher, enquanto que os utilizadores de computadores mais modernos podem começar a utilizar o Gemini e a colher desse facto alguns benefícios.
A forma menos comprometida de explorar o Geminispace é usar um proxy da web ou um "portal", como um dos que se apresentam seguidamente:
Estes portais permitir-lhe-ão usar o seu navegador normal para explorar o Geminispace. Se gosta do que vê, poderá equacionar a instalação de um cliente Gemini dedicado, que normalmente oferece uma experiência de navegação melhor e mais completa. Pode encontrar uma lista de clientes (e outro software) no link abaixo. Existem também clientes disponíveis para plataformas móveis, como Android e iOS!
Se tiver um cliente ssh instalado, pode experimentar alguns clientes de terminal sem ter que os instalar, executando:
ssh kiosk@gemini.circumlunar.space
Este quiosque Gemini foi inspirado no quiosque Gopher disponível em bitreich.org!
Por enquanto, o Geminispace ainda é suficientemente pequeno para que seja viável usar diretórios como forma de descobrir o que está disponível. Alguns deles estão listados abaixo:
O diretório medusae.space Gemini tem uma lista de cápsulas divididas por categorias temáticas
Lista de servidores Gemini identificados pelo motor de pesquisa GUS
Lista histórica dos primeiros 50 servidores Gemini
Se estiver à procura de algo em particular, o Gemini tem dois motores de pesquisa:
GUS, o primeiro motor de pesquisa Gemini
Houston, o segundo motor de pesquisa do Gemini
Existem dois agregadores públicos cujo objetivo é tornar mais fácil a pesquisa do material atualizado recentemente no Geminispace:
CAPCOM, que agrega feeds Atom de conteúdo Gemini
Spacewalk, que usa deteção de alterações para encontrar novo conteúdo
Uma das opções é configurar o seu próprio servidor Gemini num VPS ou num computador de casa (pequenos SBC - Single Board Computers, como o RaspberryPi, são perfeitamente capazes de serem configurados como servidores Gemini). Existe uma grande variedade de software de servidor para escolha:
Como alternativa, poderá encontrar outras opções para hospedar o seu conteúdo. A hospedagem Gemini também está disponível nos seguintes provedores:
SourceHut (inclui suporte para domínios personalizados!)
Há uma série de comunidades "pubnix" ou "tilde" (sistemas unix multiutilizador em que os utilizadores interagem uns com os outros por meio de ssh, de e-mail local, chat e aplicações BBS) que também oferecem hospedagem Gemini (normalmente em conjunto com hospedagem na web e/ou Gopher). Pode conseguir uma conta numa das comunidades abaixo listadas. Observará que a maioria dessas comunidades é mais antiga do que o próprio Gemini, podendo dar-se o caso de estarem mais voltadas para outros serviços ou para temas mais específicos ou de interesse particular. Pesquise todas as possibilidades cuidadosamente e junte-se ao servidor que achar ser o mais adequado para os seus interesses, em vez de pensar nesses pequenos mundos incríveis como espaços que utilizará com o único objetivo de despejar o seu conteúdo.
Tanelorn City, um servidor focado na escrita
Raw Text Club, também conhecido como RTC
Breadpunk.club, um servidor dedicado ao fabrico de pão
Se pertence a uma comunidade pubnix que não oferece hospedagem Gemini, não custa nada perguntar ao(s) administrador(es) se eles estão interessados em adicionar esse serviço!
Se você não se sentir confortável com as tecnologias necessárias para fazer uso da hospedagem pubnix (ssh ou sftp, editores de texto de terminal, permissões de ficheiros unix, etc.), poderá obter contas gratuitas nos serviços abaixo indicados, que lhe permitirão manter uma cápsula através de um aplicação web:
Gemlog Blue, apresenta uma interface ultraleve, sem cookies ou Javascript
Flounder, onde o seu conteúdo estará disponível simultaneamente no Gemini e na web
Considere juntar-se à nossa mailing list (consulte o ponto 1.3) para que possa anunciar o seu novo servidor à comunidade e manter-se atualizado com, por exemplo, informações sobre as atualizações do seu software de servidor ou do próprio protocolo Gemini.
Poderá enviar o URL do seu servidor para o motor de pesquisa GUS, para que ele seja rastreado, através do seguinte link:
O Gemini já possui um número surpreendente de implementações de cliente e servidor - o que não quer dizer que não sejam bem-vindas, motivo pelo qual, neste momento, a verdadeira escassez não é de software, mas de conteúdo. Quanto mais coisas interessantes e empolgantes as pessoas encontrarem no Geminispace, maior será a probabilidade de quererem adicionar conteúdo próprio. Assim, a maior contribuição que pode dar ao projeto é fazer parte desse processo. Consulte o ponto 3.3 deste documento para obter detalhes sobre como colocar o seu conteúdo no Geminispace.
Se tiver os conhecimentos técnicos necessários, poderá dar uma grande contribuição para o crescimento do Geminispace, fornecendo um serviço de hospedagem a quem quiser publicar o seu conteúdo. Isso pode ser uma operação tão simples como configurar contas de utilizador sftp num VPS. A oferta de hospedagem não significa necessariamente um grande compromisso. Há disponível uma oferta de VPS de baixo custo, que servem para hospedar confortavelmente uma dúzia de utilizadores. Um grande número de hospedeiros, servindo o conteúdo de um número relativamente pequeno de utilizadores, é um ecossistema muito mais robusto e sustentável do que um pequeno número de servidores com centenas ou milhares de utilizadores!
Se você tem mesmo vontade de desenvolver software, uma ferramenta poderosa para expandir o Geminispace poderá ser uma ferramenta que forneça simultaneamente um servidor Gemini e uma interface que possa ser usada por vários utilizadores para, de forma fácil, gerir o conteúdo fornecido por esse servidor. Isso pode ser conseguido, por exemplo, através de uma interface web interativa ou através do envio e-mails repletos de conteúdo; Algo parecido com os serviços Gemlog Blue e Flounder (consulte novamente o ponto 3.3), mas empacotados e documentados de forma a que seja fácil para as pessoas implementarem e personalizarem os seus próprios sites multiutilizador, como são disso exemplo as instâncias de Mastodon.
Também poderá ajudar o projeto, contribuindo com correções, acréscimos ou traduções do site oficial e da documentação (consulte os pontos 4.2 e 4.3, disponíveis abaixo).
Toda a documentação hospedada em gemini.circumlunar.space, incluindo este documento que está a ler, está alojada num único repositório git, aberto ao público apenas com acesso de leitura. Poderá clonar o repo com o seguinte comando:
git clone git://gemini.circumlunar.space/gemini-site
De seguida, efetue as alterações que entender sugerir nos ficheiros relevantes (a estrutura dos URLs espelha exatamente a estrutura do repositório, ou seja, gemini://gemini.circumlunar.space/docs/faq.gmi está em docs/faq.gmi no repo). Faça o commit das suas alterações, utilizando mensagens de commit significativas (não se esqueça de definir o seu nome e endereço de e-mail para que as pessoas possam ver quem efetuou as alterações!). Faça um commit por cada mudança conceptual. Após as alterações e os commit correspondentes, terá duas opções para enviar as suas propostas de alteração.
Se tiver o comando send-email do git configurado (veja abaixo um link para um tutorial), poderá enviar com um único comando os patches com os seus commits para <solderpunk _at_ posteo _dot_ net>. Caso contrário, poderá simplesmente executar:
git format-patch origin
para criar um conjunto de ficheiros de patch, que poderá anexar manualmente a um e-mail, usando qualquer cliente de e-mail à sua escolha.
Um tutorial amigável sobre como configurar o git send-email
Obrigado! O voluntariado para traduzir a documentação é uma ótima maneira de ajudar o projeto.
Para fazer isso, clone o repositório git conforme descrito no ponto 4.3, acima descrito. Mude para a pasta `doc` do repositório e crie uma nova subpasta com o código ISO 639-1 de duas letras do seu idioma. Por exemplo, as traduções em finlandês devem ficar em `doc/fi/`, as traduções em japonês em `doc/jp/`, etc. Pode encontrar uma lista completa de códigos na Wikipedia, no link abaixo. Se estiver a traduzir para uma variante regional de um idioma, poderá usar códigos no estilo RFC4646, como, por exemplo, pt-PT ou pt-BR para o português falado em Portugal ou no Brasil, respetivamente.
Lista de códigos de idioma na Wikipedia
Para cada ficheiro em inglês que resida em `doc` que deseje traduzir, crie um ficheiro correspondente na subpasta do seu idioma. Não há problema se alterar o nome do ficheiro como parte da tradução. Por exemplo, o ficheiro de tradução alemã de `doc/ specification.gmi` pode chamar-se `doc/spezifikation.gmi`. Pode traduzir apenas um ou vários ficheiros de `doc`, de acordo com o tempo e a energia que tiver disponível. Não tenha vergonha de enviar traduções parciais! Provavelmente, pessoas haverá que, falando a sua língua e vendo seu trabalho e esforço, poderão estar também disponíveis para colaborar com uma parte do trabalho restante ou até mesmo todo o trabalho restante. Ter algum conteúdo traduzido é melhor do que nada.
Assim que terminar, copie o ficheiro `doc/index.gmi` para a pasta da sua língua e modifique-o de forma a que haja correspondência com os ficheiros traduzidos e com os títulos atribuídos aos documentos. Remova os links para todos os documentos originais que ainda não traduziu.
Finalmente, atualize o `doc/translations.gmi` original e acrescente um link para a sua nova pasta, onde estão os documentos por si traduzidos.
Submeta as suas traduções ao repositório e envie ao Solderpunk o patch, seguindo as instruções descritas no ponto 4.2.