Актуально на 28 февраля 2021 года.
Gemini - это новый, реализуемый на уровне приложений интернет-протокол для распространения произвольных файлов с некоторым предпочтением к передаче лёгкого гипертекстового формата, позволяющего файлам простым образом ссылаться друг на друга. Вы можете думать о Gemini как о "вебе, возвращённом к своей первоначальной сути" или как об "усовершенствованном и модернизированном Gopher" в зависимости от вашей перспективы (второй взгляд, впрочем, более точен). Gemini может быть интересен тем, кто:
Gemini задуман быть простым, но не обязательно "простым любой ценой". В основе лежит стремление к максимизации "отношения мощности к массе" при условии, что масса находится в допустимых пределах. Gemini также задуман уважать конфиденциальность, создавать препятствия попыткам расширить его (чтобы он *оставался* простым и уважительным к конфиденциальности) и быть совместимым по духу с принципом "сделай сам". По этой причине Gemini в техническом плане очень хорошо знаком и консервативен: этот протокол придерживается традиционных парадигм "клиент-сервер" и "запрос-ответ" и построен на стандартизированных, прочно вошедших в нашу жизнь технологиях, таких как URI, MIME-типы и TLS.
Работа над проектом Gemini началась в июне 2019 года. В то время как сам протокол по большей части завершён, доступное программное обеспечение, ресурсы и сообщество всё ещё находятся в относительно ранней (однако бурной!) стадии развития.
Проект Gemini изначально возник благодаря Solderpunk <solderpunk _at_ posteo _dot_ net>, который остаётся "добродушным диктатором" проекта, однако протокол был разработан в сотрудничестве с неформальным и слабо связанным между собой сообществом из множества заинтересованных людей через электронные письма, посты в "флогосфере" Gopher и микроблоги Fediverse. Множество людей определили вид значимых частей протокола, так что, несмотря на наличие лидера, неправильно думать о Gemini как о работе одного человека.
В феврале 2021 года давний участник проекта Sean Conner получил некоторые полномочия в плане принятия решений, чтобы помочь завершить работу над спецификацией Gemini, пока Solderpunk не может посвящать проекту необходимые для этого время и силы.
Сложно узнать наверняка. Если считать уникальные имена узлов Gemini-серверов, то легко преувеличить размер пространства, так как кое-какие многопользовательские сайты дают всем пользователям по собственному поддомену. Если считать уникальные IP-адреса, то легко преуменьшить размер, потому что Gemini позволяет обслуживать несколько разных доменов с одного IP. В любом случае, на начало 2021 года было около 200 000 известных URL-адресов Gemini, распределённых по около 750 "капсулам" (термин, которым в сообществе Gemini принято называть сайты), 500 доменам и 600 IP-адресам. Тем не менее, пространство быстро растёт. Вы можете найти свежайшую статистику по ссылке ниже.
Статистика Geminispace, предоставленная сканером "Lupa" за авторством Stéphane Bortzmeyer
Текущая (неформальная) спецификация протокола по большей части "заморожена", за исключением мелких правок для устранения двусмысленности и рассмотрения особых случаев. Предложения добавить новые функции будут отклоняться, так как протокол уже сочтён полноценным. В перспективе, проект фокусируется главным образом на растущее сообщество вокруг протокола, а также на работу над переводом имеющейся спецификации на более точный и формальный язык, чтобы можно было предложить её органам по стандартизации интернета, таким как IETF и IANA.
Совсем нет! Аналогично, никто из вовлечённых в Gemini людей не собирается уничтожать Gopherspace. Gemini предназначен не заменить Gopher или веб, а мирно сосуществовать вместе с ними как ещё один вариант, чтобы можно было свободно выбирать среди них подходящий себе. Так же, как сейчас многие имеют серверы, передающие одинаковый контент по Gopher и WWW, вы вольны дублировать контент на любых протоколах, которые лучше всего подходят под технические, философские и эстетические требования вас и вашей аудитории.
Это отсылка к дошаттловой эре пилотируемых космических полётов США, которую составляли три проекта. Сначала была программа "Меркурий", довольно минималистичная "проверка концепции" и часть гонки по скорейшей отправке человека в космос (которую выиграл Советский Союз с программой "Восток"). Корабль "Меркурий" был одноместной капсулой без возможности изменить орбиту после запуска, и только один полёт по программе "Меркурий" длился больше одного дня. Последней была программа "Аполлон": корабли были большими, тяжёлыми, сложными и дорогими, но могли, знаете ли, отправить трёх человек на луну и обратно.
Гораздо менее известная широкой публике, программа "Джемини" была чем-то средним: корабль представлял собой капсулу для двух человек, которая могла состыковаться с другими орбитальными модулями, разгерметизироваться и герметизироваться на орбите (чтобы можно было выйти в открытый космос), а самый длинный полёт в рамках программы составил почти две недели - дольше, чем любая миссия "Аполлона"! С точки зрения размера, массы и стоимости корабли "Джемини" были гораздо ближе к "Меркуриям", чем к "Аполлонам", но в плане возможностей всё было наоборот: в том числе были планы (несостоявшиеся) проводить окололунные полёты "Джемини"!
Кажется, аналогия очевидна: Gopher сродни "Меркуриям", а WWW аналогичен "Аполлонам". Gemini пытается вписаться между ними, делая больше при меньших затратах.
Название Gemini преднамеренно не отсылает к *чему-либо* связанному с сусликами (gophers), или другими грызунами, или даже другими животными. В процессе самых ранних обсуждений в флогах, которые однажды переросли в проект Gemini, возникло недопонимание, о чём шла речь: о том, чтобы полностью заменить Gopher, или о том, чтобы добавить неофициальные и обратно несовместимые усовершенствования в существующие клиенты и серверы Gopher. Когда не подкреплённые действиями обсуждения превратились в реальный проект, было сочтено разумным чётко дать это понять.
Официальная страница проекта Gemini находится на сервере gemini.circumlunar.space. В ней находится последняя редакция этого FAQ, а также спецификация протокола, рекомендации по лучшим практикам и прочая официальная документация Gemini, которая доступна по протоколам Gemini, Gopher и HTTPS, по IPv4 и IPv6.
Официальные обсуждения касательно Gemini проходят в списке рассылки:
Подписаться и просмотреть архивы через веб-интерфейс
Всем, кто имеет свой Gemini-сервер или разрабатывает клиентское либо серверное ПО, настоятельно рекомендуется подписаться.
Неформальные беседы касательно Gemini также проходят в канале #gemini IRC-сервера tilde.chat:
Просмотреть историю IRC-чата по Gemini
Следующие критерии были неформально разработаны в самом начале проекта. Не до конца ясно, насколько полно эти задачи были выполнены, но в общем и целом Gemini приблизился к их удовлетворению.
В частности, Gemini стремится к простоте реализации клиента. Современные веб-браузеры настолько сложные, что их возможно разрабатывать только в рамках огромных и дорогих проектов. Это естественным образом приводит к очень маленькому количеству браузеров-монополистов, из-за чего инновации и разнообразие подавляются, а разработчики браузеров начинают диктовать направление, в котором развивается WWW.
Gemini нацелен быть простым, но не *слишком* простым. Gopher проще на уровне протокола, но вследствие этого клиент никогда не узнает множества важных сведений, например: какая кодировка у этого текста? Является ли этот текст сообщением об ошибке от сервера? Какой тип файла имеют эти бинарные данные? По этой причине надёжный клиент Gopher получается *менее* простым, так как требует выводить аналитически или угадывать отсутствующую информацию.
В ходе ранних дискуссий вокруг Gemini было выделено три ясные цели касательно простоты:
Не очень понятно, в какой степени эти цели были достигнуты. Эксперименты показывают, что простейший интерактивный клиент занимает больше минимума в 100 строк кода, а комфортный для использования и реализующий большинство функций клиент требует более 200 строк. Тем не менее, Gemini в общем и целом удовлетворяет поставленным целям.
Разработка Gemini велась с чётким пониманием того, что современный веб - катастрофа в плане конфиденциальности, а интернет - не безопасное пространство для обычного текста. Такие вещи, как фингерпринтинг и основанные на Etag "суперкуки" - важная поучительная история о том, что отслеживание пользователей может и обязательно проберётся через лазейку в использовании тех функций протокола, которые не были изначально предназначены для этого. Таким образом, те, кто разрабатывают протокол, должны не только избегать создания в нём средств для отслеживания (что довольно просто), но также иметь в виду злой умысел и избегать добавления всего того, что может быть использовано в целях эффективного отслеживания. Озабоченность этим выражается в преднамеренной нерасширяемости во многих частях протокола Gemini.
Главное применение Gemini - чтение письменного материала и, в меньшей степени, потребление другого контента, аналогично тому, как это происходит в gopherspace или "адекватном вебе" (то есть всём том, чем можно комфортно пользоваться в браузерах Lynx и Dillo). Но так же как HTTP может и используется для гораздо, гораздо большего, чем передача HTML, Gemini должен быть пригоден к использованию для множества других целей, при условии, что это не противоречит перечисленным выше критериям простоты и конфиденциальности. Это означает необходимость принимать во внимание возможные области применения, построенные вокруг бинарных файлов и роботов.
Gemini позволяет:
Текст в документах Gemini переносится клиентом, чтобы вписаться в экран устройства, а не требует "жёстких" переносов строки на ~80 символах. Это значит, что содержимое отображается одинаково хорошо на телефонах, планшетах, ноутбуках и стационарных компьютерах.
Gemini отвергает имеющуюся в Gopher строгую дихотомию "директория - текст" и позволяет вставлять ссылки в документах.
Gemini обязывает использовать шифрование TLS.
Современная флогосфера подсказывает, что многие действительно так думают. Всё больше пользователей передают контент, почти полностью состоящий из текста, с типом содержимого 1, ведь это позволяет вставить немного ссылок рядом с другим gopher-контентом, создавая некое подобие гиперссылок HTML - совершенно разумное и безобидное желание. Без следования этому подходу авторам и авторкам контента Gopher не остаётся ничего лучше, чем вставить список URL в низ документа, чтобы читатели вручную их копировали и вставляли в свой клиент. Это не самый приятный пользовательский опыт. Но добавление гиперссылок в Gopher - не просто злоупотребление семантикой протокола Gopher, но и поразительно неэффективный способ передавать текст, ведь каждая строка должна иметь тип содержимого i, а также ненастоящие путь, имя узла и порт, которые необходимо передать, чтобы получилось правильное меню Gopher. Любые заявления о простоте и красоте, которыми когда-то обладал Gopher, разбиваются об этот факт. Gemini применяет простой подход: позволяет вставлять сколько угодно ссылок в текстовый кон��ент, что почти не влияет на размер передаваемой информации и сохраняет ограничение Gopher "одна строка - одна ссылка", что в результате даёт красивый и организованный контент. Сложно видеть это иначе как достоинство.
Конечно, если вам действительно нравится Gopher, ничто в Gemini не останавливает от его повторения. Вы можете передавать тип содержимого 0 с MIME-типом text/plain и писать документы text/gemini, где каждая строка - это ссылка, повторяя внешний вид соответствующего RFC1436 меню Gopher без этого досадного нестандартного типа содержимого i.
Gemini не имеет эквивалентов заголовков User-Agent и Referer, а формат запроса не расширяем, поэтому в него в будущем ничего больше не впихнут. В действительности, запросы Gemini не содержат ничего, кроме URL запрашиваемого ресурса. Это весьма надёжно предотвращает отслеживание пользователей.
"Родной тип содержимого" для Gemini (аналогично HTML для HTTP(S) или простому тексту для Gopher) никогда не требует дополнительных сетевых транзакций (в нём нет встроенных в документ изображений, внешних таблиц стилей, шрифтов и скриптов, отсутствуют iframe и так далее). Это позволяет быстро обозревать Geminispace даже при медленном интернет-соединении, а также даёт полное понимание и контроль того, к каким серверам идут запросы.
Родной для Gemini тип содержимого - обычный документ, без возможности скриптования, что позволяет легко обозревать Geminispace даже на старых компьютерах с небольшой производительностью процессора и маленьким объёмом памяти.
Многие задаются вопросом: "Зачем создавать новый протокол, чтобы решить предполагаемые проблемы с опциональными, второстепенными возможностями WWW? Просто потому что вебсайты *могут* отслеживать пользователей, и выполнять истощающий ресурсы компьютера Javascript, и загружать бесполезные и весящие несколько мегабайт обложки сайтов или ещё более тяжёлые автовоспроизводящиеся видео, не значит, что они *обязаны* это делать. Почему бы просто не писать хорошие вебсайты, используя имеющиеся технологии?"
Конечно же, это возможно. "Пользовательский опыт Gemini" в грубом приближении эквивалентен HTTP, где единственный заголовок запроса - это "Host", а единственный заголовок ответа - "Content-type", и HTML, где единственные теги - это <p>, <pre>, <a>, <h1>-<h3>, <ul> и <li>, а также <blockquote>. Вебсайт https://gemini.circumlunar.space предлагает именно такой опыт. Мы знаем, что этого реально достичь.
Проблема в том, что если определить строго ограниченное подмножество HTTP и HTML, назвать его как-нибудь и на этом остановиться, то это не сделает ровным счётом ничего для создания чётко разграниченного пространства, которое можно будет посещать, чтобы потреблять *только* такой тип контента *только* таким способом. Невозможно заранее определить, будет ли https:// адрес вести на страницу в рамках подмножества или за его пределами. Очень утомительно проверять, соответствует ли на самом деле подмножеству вебсайт, который об этом заявляет, ведь многие функции, которых мы хотим избежать, невидимы (но не безобидны!) для пользоваться. Трудно или даже невозможно выключить поддержку всех нежеланных функций в мейнстримных браузерах, так что если кто-то нарушает правила, вы расплачиваетесь за последствия. Написать примитивный веб-браузер, который игнорирует все нежеланные функции, гораздо сложнее, чем написать клиент Gemini "с нуля". Даже если это получится, вам придётся постараться, чтобы найти малую толику вебсайтов, которые он бы смог отобразить.
В то же время, намеренно простые протоколы вроде Gopher и Gemini создают альтернативные, намеренно простые пространства с очевидными границами и строгими ограничениями. Когда вы открываете Geminispace, вы можете точно определить заранее, какие ссылки введут за его пределы. Пока вы находитесь в нём, вы точно знаете и будете всегда уверены в том, что все остальные играют по тем же правилам. Вы можете расслабиться и приступить к просмотру страниц, переходить по ссылкам на сайты, о которых раньше никогда не слышали и которые появились только вчера, и при этом сохранять уверенность в том, что они не будут пытаться отследить вас или передать мусорный контент, потому что они *не могут*. Вы можете делать всё это, пользуясь клиентом, который написали сами, так что вы будете *знать*, что можно ему доверять. Это качественно отличный, в гораздо большей степени освобождающий и расширяющий возможности опыт, чем пытаться выкроить мелкое, невидимое под-под-под-подпространство WWW.
Естественно!
Gemini не поддерживает кэширование, сжатие и возобновление прерванных загрузок. В связи с этим, он не очень подходит для распространения больших файлов, где конкретное значение слова "больших" зависит от скорости и надёжности интернет-соединения.
Некоторые расстроены тем, что из-за требования TLS для написания Gemini-кода им приходится использовать TLS-библиотеку, тогда как, например, Gopher позволяет им обрести полный контроль, в��дь они могут написать всё сами "с нуля".
Конечно, даже клиент Gopher "с нуля" на самом деле критически зависит от тысяч строк запутанного кода, написанного другими людьми с целью предоставить функционирующий IP-стек, разрешение имён DNS и файловую систему. Использование TLS-библиотеки, чтобы предоставить надёжную реализацию криптографии, по сути ничего не меняет.
Gemini также превращает клиентские TLS-сертификаты, очень редко используемые в WWW, в граждан первого класса со специальными кодами ответа для их запроса. Это позволяет ограничивать доступ к Gemini-ресурсам и добровольно устанавливать "сессии" в серверных приложениях без необходимости передавать куки, пароли, токены аутентификации или что-либо ещё, к чему вы могли уже привыкнуть. Такой подход гораздо ближе к понятию SSH об "авторизованных ключах" и, фактически, гораздо более простой подход к аутентификации пользователей.
TLS, конечно, не лишён недостатков, но:
Язык разметки text/gemini многое позаимствовал от Markdown, из-за чего у некоторых может возникнуть вопрос: "Почему бы просто не использовать Markdown как тип контента по умолчанию в Gemini? Конечно, его поддержку затруднительно реализовать, но, как и в случае TLS, для всех основных языков программирования доступно множество библиотек". Причины не идти этим путём заключаются в том, что:
Конечно же, возможно и передавать Markdown по Gemini. Включение MIME-типа text/markdown в заголовок ответа позволит продвинутым клиентам поддерживать его.
Так как text/gemini - это полностью новый формат, разработанный с нуля для Gemini, авторам и авторкам клиентов в типичном случае придётся писать собственный код для парсинга и отрисовки этого формата "с нуля", без возможности положиться на уже существующую и проверенную библиотеку. Следовательно, для формата важно быть крайне простым в обработке. Это достигается с использованием построчного формата, в котором строки текста и строки ссылок являются отдельными концептами. Клиентам не нужно сканировать каждую строку посимвольно, проверяя наличие некоего специального синтаксиса ссылок. Даже простейший синтаксис ссылок вводит возможность "сломать" синтаксис (и клиентам пришлось бы быть устойчивыми к этому), а также имеет крайние случаи, обработку которых пришлось бы либо расписывать в спецификации протокола (что привело бы к более длинной, более нудной спецификации, которую совсем не весело читать и тяжело удержать в голове), либо оставить неопределённой (что привело бы к отличающемуся поведению у разных клиентов). Даже если ссылки внутри строки естественно сочетаются с некоторыми типами контента, они не стоят повышенных сложности и ошибкоопасности, которые они бы неизбежно ввели в протокол.
Для того, чтобы привыкнуть к стилю написания "одна строка - одна ссылка", нужно мыслить немного по-иному, но со временем станет проще. К тому же, этот стиль имеет кое-какие преимущества. Он поощряет включать только самые важные и релевантные ссылки, организовывать ссылки в списки и давать каждой ссылке максимально полное описание без нужды переживать о том, вписывается ли оно в поток основного текста.
Некоторые выразили желание видеть что-нибудь вроде CSS в Gemini. Пусть и верно то, что нечто гораздо проще и легче CSS могло бы быть с лёгкостью разработано, Gemini вместо этого придерживается следующей позиции: визуальная стилизация контента Gemini должна быть под исключительным и прямым контролем читателей, а не авторов. Не все имеют одинаковые предпочтения в цветах и шрифтах, и ни один стиль страницы не будет оптимальным для всех читающих её людей, всех устройств и всех условий освещения. На кону стоит намного большее, чем старое разделение между предпочтением тёмного текста на светлом фоне и наоборот. Люди с ограниченными возможностями в чтении, например при дислексии, могут существенно улучшить свой опыт при использовании специальных шрифтов. Простая система стилей "один размер подходит всем", где контент везде выглядит одинаково, гарантированно будет плох для многих людей. Более сложная система стилей, которая способна определять разный внешний вид для разных устройств и контекстов обременяет каждого автора задачей убедиться в том, что их капсула юзабельна везде. Опыт WWW подсказывает, что проблемы доступности будут решаться в последнюю очередь, и то если повезёт. Гораздо проще, и на деле гораздо менее утомительно для авторов, дать контенту быть просто контентом, а стилизацию оставить клиенту. Некоторые клиенты Gemini могут выглядеть уныло и скучно, но нет никаких причин делать все клиенты таковыми. Если есть спрос на клиенты с высококачественной отрисовкой шрифтов и красивой типографией, такие клиенты будут написаны - и когда они появятся, ценящие всё это пользователи будут наслаждаться таким опытом чтения повсюду в Geminispace, даже при чтении контента, написанного теми, кого стилизация совсем не заботит.
Нерасширяемость протокола стала одним из важнейших принципов, учитываемых при разработке Gemini. Такие вещи как куки, Etags и другие инструменты отслеживания не были представлены в оригинальной спецификации HTTP, но могли быть легко добавлены позже, потому что формат ответа HTTP открытый и позволяет запросто добавлять новые заголовки. Чтобы минимизировать риск медленного скатывания Gemini в подобие WWW, было решено включать в заголовок ответа для успешных запросов одно и только одно поле для информации. Если бы полей для информации было два, с указанным между ними разделителем, это бы открыто путь для дальнейшего добавления третьего поля - просто надо использовать этот же разделитель опять. По существу, нет никакого островка стабильности между одним и сколькими угодно многими полями для информации, так что Gemini придерживается первого варианта, даже если это значит пожертвовать некоторой хорошей и, по-видимому, безвредной функциональностью. Имея это ограничение, указание исключительно эквивалента Content-type оказалось очевидно более полезным, чем указание исключительно эквивалента Content-length. То же самое верно и для других безвредных и полезных HTTP-заголовков, таких как Last-Modified.
В Gopher также отсутствует эквивалент заголовка Content-length, и это не создало на практике никаких препятствий для Gopherspace.
Даже без этого заголовка клиенты могут (в отличие от Gopher) отличить транзакцию Gemini, которая успешно завершилась, от передачи, прерванной посреди передачи данных из-за ошибки сети или вредоносной атаки через присутствие или отсутствие сообщения TLS Shutdown.
Действительно верно то, что неспособность клиента сообщить пользователям, какого размера часть большого файла ещё предстоит скачать, и на основе этого рассчитать, сколько времени займёт загрузка, означает то, что Gemini не способен предоставить комфортный опыт при загрузке больших файлов, однако дело обстояло бы точно так же и без Content-length, ведь такой опыт требовал бы усложнить протокол, например, возможностью возобновить прерванные загрузки. Документы Gemini могут, конечно же, ссылаться непосредственно на ресурсы по протоколам HTTPS, BitTorrent, IPFS, DAR и так далее, и это, наверное, наилучший вариант для загрузки больших файлов.
Это имело бы смысл только при наличии планов обновления до "Gemini 2.0" в будущем - а их нет! Gemini - это реакция в духе "лучше меньше, да лучше" на становящиеся всё более сложными и мощными веб-браузеры и серверы. Нет никакого смысла в планах добавить в Gemini больше функционала в будущем. Вместо этого план заключается в том, чтобы "не накосячить с первой попытки", насколько это возможно, а потом "заморозить" спецификацию навсегда: без обновлений, улучшений и расширений.
Это может казаться радикальным или неразумным, но мы выражаем осторожный оптимизм. Спецификация Gopher не менялась почти 30 лет, и только небольшое количество несущественных неофициальных изменений в этой спецификации часто используются в сегодняшнем Gopherspace, популярность которого в действительности растёт. Gemini сочетает в себе устоявшиеся, повсеместно используемые базисные элементы, такие как URI, медиа-типы MIME и TLS в очень прямолинейной манере и стремится содействовать культуре работы внутри тщательно обдуманных ограничений вместо устранения каждого ограничения на пути того, чтобы сделать абсолютно всё возможным. Gemini полезен и хорош для многих вещей прямо сейчас, и нет никакой причины думать, что он перестанет быть полезным и хорошим для тех же самых вещей десятилетия спустя.
Gopher настолько прост, что компьютеры из 80х и 90х могут легко реализовать протокол, и для некоторых это одно из величайших достоинств Gopher. Обязательный для Gemini TLS ограничивает его применение более современными машинами.
Старые устройства потрясающи, а сохранение их работающими, подключёнными к интернету и полезными - потрясающее занятие. Но для подавляющего большинства пользователей интернета не имеет смысла жертвовать какой-либо или всей вообще защитой конфиденциальности, чтобы делать это возможным. Помните: Gemini не нацелен заменить Gopher, так что он не угрожает прямым образом ретро-совместимому интернету. Кстати, тем, у кого прямо сейчас есть Gopher-сервер, настоятельно рекомендуется передавать этот же контент одновременно через Gemini-сервер. Любители ретрокомпьютеров смогут продолжать просматривать контент по Gopher, в то время как пользователи современных компьютеров смогут переключиться на Gemini и извлечь из этого определённую выгоду.
Самый простой способ начать исследовать Geminispace - использовать веб-прокси (или "портал"), например, один из этих:
Веб-прокси позволят вам использовать веб-браузер для исследования Geminispace. Если вам в нём понравится, вы можете задуматься о том, чтобы установить отдельный Gemini-клиент, который также предложит лучший и более полный опыт. Вы можете найти список клиентов (и другого ПО) по ссылке ниже. Доступны даже клиенты для мобильных платформ, таких как Android и iOS!
Список программного обеспечения Gemini
Если у вас установлен ssh-клиент, вы можете попробовать некоторые консольные клиенты, не устанавливая их:
ssh kiosk@gemini.circumlunar.space
Этот Gemini-киоск был вдохновлён Gopher-киоском от bitreich.org!
На данный момент Geminispace ещё достаточно маленький для того, чтобы использовать каталоги как реальный способ находить в нём что-то новое. Некоторые из них перечислены ниже:
Каталог medusae.space представляет собой список капсул, распределённых по тематическим категориям
Список известных поисковой системе geminispace.info Gemini-серверов
Исторический список первых 50 Gemini-серверов
Если вы ищете что-то конкретное, воспользуйтесь поиском:
geminispace.info, поиск по Gemini
Также существуют два публичных агрегатора, которые упрощают поиск свежих материалов в Geminispace:
CAPCOM, агрегатор Atom-лент Gemini-контента
Spacewalk отслеживает изменения страниц, чтобы находить новый контент
Один из вариантов - настроить собственный Gemini-сервер на VPS или домашнем компьютере (маленькие одноплатники вроде RaspberryPi способны послужить идеальными Gemini-серверами). У вас есть широкий выбор серверного программного обеспечения:
Список программного обеспечения Gemini
Или же вы можете найти где-нибудь хостинг для своего контента. Его предоставляют следующие провайдеры:
SourceHut (имеется поддержка собственных доменных имён!)
Некоторые сообщества "tilde" и "pubnix" (это многопользовательские unix-системы, где пользователи взаимодействуют друг с другом после входа в них по SSH с помощью локальной почты, чатов и BBS-приложений) также предлагают хостинг Gemini (обычно наряду с веб- и/или Gopher-хостингом). Вам может удаться получить аккаунт в одном из перечисленных ниже сообществ. Пожалуйста, учтите, что многие из этих сообществ старше, чем сам Gemini, и могут быть сфокусированы на других сервисах или посвящены определённой тематике или интересам. Исследуйте варианты и присоединитесь к такому серверу, куда вы сможете хорошо вписаться, а не обращайтесь с этими прекрасными маленькими мирами как со свободным местом, чтобы вываливать туда свой контент.
Tanelorn City, нацеленный на писателей и писательниц сервер
Breadpunk.club, сервер на тему выпечки
Если вы принадлежите к pubnix-сообществу, которое не предлагает Gemini-хостинг, спросите администрацию, заинтересованы ли они в добавлении этого сервиса. Она не кусается!
Если вы не чувствуете себя комфортно с технологиями, нужными для pubnix-хостинга (ssh и sftp, консольные текстовые редакторы, права доступа unix и так далее), вы можете бесплатно зарегистрироваться в перечисленных ниже сервисах, которые позволят вам создавать свою капсулу через веб-приложение:
Gemlog Blue имеет ультралёгкий интерфейс без куки и Javascript
В Flounder ваш контент будет доступен одновременно по Gemini и HTTPS
Пожалуйста, задумайтесь над тем, чтобы присоединиться к списку рассылки (смотрите вопрос 1.3), чтобы вы могли рассказать о своём сервере сообществу и чтобы быть в курсе, например, обновлений серверного ПО или протокола Gemini.
Вы можете отправить URL вашего сервера на geminispace.info, чтобы страницы с вашей капсулы отображались в результатах поиска. Это можно сделать по ссылке ниже:
Отправить URL на geminispace.info
Gemini уже имеет удивительно много реализаций клиентов и серверов. Это не значит, что больше писать не надо, но сейчас реальная нехватка не в области программного обеспечения, а в области контента. Чем больше интересных и восхитительных вещей люди находят в Geminispace, тем вероятнее они захотят добавить свой собственный контент. Поэтому не придумать лучше способа помочь проекту, чем стать частью этого процесса. Смотрите вопрос 3.3 выше для того, чтобы узнать подробнее про размещения контента в Geminispace.
Если вы имеете необходимые технические навыки, вы можете сильно помочь росту Geminispace, предоставляя хостинг для тех, кто хочет публиковать контент. Это может быть чем-нибудь простым, вроде предоставления пользовательских аккаунтов на VPS с доступом исключительно по sftp. Предоставление хостинга не обязательно должно быть большим обязательством. Вы можете использовать самые дешёвые VPS-сервисы и без проблем обслуживать около десятка пользователей. Большое количество серверов, каждый из которых передаёт контент сравнительно небольшого числа пользователей - гораздо более надёжная и устойчивая экосистема, чем несколько серверов, каждый из которых обслуживает сотни или тысячи пользователей!
Если вы правда хотите написать какой-то код, мощным инструментом для расширения Geminispace могла бы стать программа, которая бы одновременно служила Gemini-сервером и способом для множества пользователей простым путём управлять контентом, предоставляемым этим сервером, к примеру с помощью интерактивного веб-интерфейса или электронной почты. То есть что-нибудь наподобие сервисов Gemlog Blue или Flounder (снова смотрите вопрос 3.3), но распространяемое и документированное так, чтобы другим людям было легко поднять и настроить их собственные многопользовательские сайты, аналогично тому, как это происходит с Mastodon.
Вы также можете помочь проекту исправлениями, добавленной информацией и переводами к официальному сайту и документации (смотрите вопросы 4.2 и 4.3 ниже).
Вся документация, размещённая на gemini.circumlunar.space (включая FAQ, которое вы сейчас читаете), находится в одном git-репозитории. Вы можете клонировать его следующим образом:
git clone git://gemini.circumlunar.space/gemini-site
Внесите изменения в соответствующие файлы (структура URL в точности повторяет структуру репозитория, к примеру, gemini://gemini.circumlunar.space/docs/faq.gmi находится в файле docs/faq.gmi репозитория). Сделайте коммит своих изменений с осмысленным сообщением (не забудьте добавить своё имя и адрес электронной почты в конфигурацию git, чтобы было видно, кто сделал работу!) по принципу "одно абстрактное изменение - один коммит". Далее у вас будет два варианта отправить свою работу.
Если вы настроили команду git send-email (смотрите руководство по ссылке ниже), вы сможете отправить патчи со своими коммитами на адрес <solderpunk _собака_ posteo _точка_ net> с помощью одной команды. В противном случае вы можете просто ввести:
git format-patch origin
чтобы создать набор патч-файлов, которые можно вручную прикрепить к электронному письму, используя обычный почтовый клиент.
Доступное и понятное руководство по настройке git send-email
Спасибо! Перевод документации - замечательный способ помочь проекту.
Чтобы заняться им, сначала клонируйте git-репозиторий, как описано в вопросе 4.2 выше. Войдите в папку `doc` репозитория и создайте новую подпапку с двухбуквенным кодом вашего языка в системе ISO 639-1, к примеру, переводы на финский должны лежать в `doc/fi/`, переводы на японский - в `doc/ja/` и так далее. Полный список кодов находится в Википедии по ссылке ниже. Если вы переводите на специфичный для региона вариант языка, используйте коды в стиле RFC4646, например, pt-PT и pt-BR для португальского и бразильского варианта португальского языка соответственно.
Список кодов для обозначения языков на Википедии
Затем для каждого файла на английском в папке `doc`, который вы хотите перевести, создайте соответствующий файл в подпапке вашего языка. Можно менять имя файла как часть перевода, например, немецкий перевод `doc/specification.gmi` может называться `doc/spezifikation.gmi`. Вы можете перевести столько файлов в папке `doc`, на сколько у вас хватит времени и сил. Не стесняйтесь предлагать частичные переводы! Как только те, кто говорят на этом языке, увидят ваши старания, они могут доделать полностью или частично оставшуюся работу. Иметь немного переведённого контента лучше, чем нисколько.
Когда вы закончите, скопируйте файл `doc/index.gmi` и измените его в соответствии с переведёнными именами файлов и заголовками документов, а также удалите ссылки на те оригинальные документы, которые вы ещё не перевели.
Наконец, обновите `doc/translations.gmi`, чтобы включить туда ссылку на ваш новый подкаталог.
Сделайте коммит своих переводов в репозиторий и отправьте Solderpunk патч, как описано в вопросе 4.2 выше.