LINUX.ORG.RU

Gemini-клиент Lagrange 1.2

 , , lagrange, ,

Gemini-клиент Lagrange 1.2

11

5

Вышла новая версия красивого и полнофункционального Gemini-клиента — Lagrange, написанного на языке C с использованием библиотеки SDL.

Gemini — это новый протокол прикладного уровня, по своему предназначению являющийся простой альтернативой HTTP и усовершенствованной альтернативой Gopher, то есть проектом «посередине» между ними в плане сложности. Он появился как реакция на недостатки последних, в особенности HTTP. В основу его дизайна легли идеи уважения приватности пользователя и сознательного отказа от расширяемости в пользу консервативного сохранения спецификации в минимальном, но удовлетворяющем пользовательские потребности виде (сейчас она заморожена). Проект использует уже знакомые многим стандарты, вроде URI, MIME и TLS. Проект не использует HTML, CSS и JavaScript — для разметки файлов предлагается похожий на Markdown формат Gemtext, а запуск кода и применение стилей на стороне клиента не предусмотрены. Для интерактивного взаимодействия с сервером существует CGI и потоковая отправка сообщений клиенту с помощью долгоживущего TCP-соединения (вследствие чего, например, возможна реализация чата). Сайты принудительно используют шифрование с помощью TLS без CA — вместо него используется механизм TOFU, а для аутентификации пользователей используются пользовательские сертификаты.

Сообщество разрастается интересными для пользователей проектами, вроде поисковой системы GUS, агрегатора новостей CAPCOM, каталогом Gemini-капсул (так называются местные сайты) Medusae, техническими демо возможностей протокола, вроде анонимной текстовой доски, агрегатора ссылок и чата. Доступны прокси как для просмотра Geminispace с помощью HTTP [1] [2] [3], так и для просмотра HTTP с помощью Gemini, и то же самое для Gopher.

Протокол достаточно прост, чтобы любой желающий мог создать свой клиент и сервер — чего нельзя сказать о текущем состоянии современного WWW с тысячами страниц спецификаций. По этой причине уже существует разнообразие проектов энтузиастов и активная дискуссия в почтовой рассылке проекта.

Lagrange является одним из таких проектов — небольшим Gemini-клиентом с поддержкой аппаратного ускорения с помощью SDL и плавного листания страниц, отображения картинок на странице, вкладок, тем оформления, закладок, истории, пользовательских сертификатов, оглавлений, новостных лент.

В этом выпуске добавлена поддержка новостных Atom-лент, загрузки отдельных файлов со страницы без открытия новой вкладки, пиктограмм для закладок, поиска по капсулам с помощью выбранной системы в настройках, опция для автоматической перезагрузки страницы по интервалу и изменения в дизайне.

В разработке порт Lagrange на мобильные платформы! А до тех пор пользователи могут попробовать Ariane на Android, например.

>>> Подробности

★★★★★

Проверено: Shaman007 ()
Последнее исправление: commagray (всего исправлений: 6)

Ответ на: комментарий от monk

что этот GUI будет работать и на X и на Wayland и на Windows/MacOS

В общем, в современной верстке нет привязки к конкретным устройствам, привязка осуществляется к разрешению через медиа запросы, ну и конечно нужно думать, какие свойства цсс используешь, насколько полноценно они поддерживаются в различных браузерах и их версиях (не конкретных устройствах).

shiva
()
Ответ на: комментарий от shiva

В общем, в современной верстке нет привязки к конкретным устройствам

По намерениям есть. Не к устройствам, а к ОС. Нормальная или Andriod/iOS.

Интерфейс для ввода пальцем от ввода мышкой отличается достаточно существенно.

привязка осуществляется к разрешению через медиа запросы

Потому что всё остальное в CSS недоступно.

насколько полноценно они поддерживаются в различных браузерах и их версиях

Ага. И динамически подправлять через JS для совместимости.

monk ★★★★★
()
Ответ на: комментарий от monk

Интерфейс для ввода пальцем от ввода мышкой отличается достаточно существенно

Уже писали, что бы ты ознакомился с медиа, там и дпи есть @media (min-resolution XXX dpi) {/*рисуем кнопку маленькую, иначе по дефолту здоровую*/}

Потому что всё остальное в CSS недоступно

Оно недоступно потому, что ненужно. Если браузер независимо от устройства поддерживает стандарты скажем цсс3, то на нем гарантированно отобразится так же, как на любом другом устройстве с поправкой на разрешение, на которое подгоняют медиазапросом.

Ага. И динамически подправлять через JS для совместимости

Тебе так необходим линейный градиент? Или еще там штук 10 свойств, которые не всеми браузерами популярными поддерживаются, что ради этого ты готов налапшекодить жс?

shiva
()
Ответ на: комментарий от shiva

Edge все поддерживал и поддерживает.

anonymous
()
Ответ на: комментарий от shiva

ишак 9 не поддерживает Его никто в промышленной разработке не поддерживает. Последняя подерживаемая легаси-версия ие - 11. И то, это всегда тройной рейт, и там вопрос только в поддержке функциональности, ане внешнего вида.

anonymous
()
Ответ на: комментарий от shiva

Уже писали, что бы ты ознакомился с медиа, там и дпи есть @media (min-resolution XXX dpi) {/рисуем кнопку маленькую, иначе по дефолту здоровую/}

Третий раз пишу. Я в курсе. Меня просто напрягает писать пачки настроек типа:

/**********
iPad 3
**********/
@media only screen and (min-device-width : 768px) and (max-device-width : 1024px) and (orientation : landscape) and (-webkit-min-device-pixel-ratio : 2) {
/* Styles */
}

@media only screen and (min-device-width : 768px) and (max-device-width : 1024px) and (orientation : portrait) and (-webkit-min-device-pixel-ratio : 2) {
/* Styles */
}

/* iPhone 4 ----------- */
@media only screen and (min-device-width : 320px) and (max-device-width : 480px) and (orientation : landscape) and (-webkit-min-device-pixel-ratio : 2) {
/* Styles */
}

@media only screen and (min-device-width : 320px) and (max-device-width : 480px) and (orientation : portrait) and (-webkit-min-device-pixel-ratio : 2) {
/* Styles */
}

/* iPhone 5 ----------- */
@media only screen and (min-device-width: 320px) and (max-device-height: 568px) and (orientation : landscape) and (-webkit-device-pixel-ratio: 2){
/* Styles */
}

@media only screen and (min-device-width: 320px) and (max-device-height: 568px) and (orientation : portrait) and (-webkit-device-pixel-ratio: 2){
/* Styles */
}

/* iPhone 6 ----------- */
@media only screen and (min-device-width: 375px) and (max-device-height: 667px) and (orientation : landscape) and (-webkit-device-pixel-ratio: 2){
/* Styles */
}

@media only screen and (min-device-width: 375px) and (max-device-height: 667px) and (orientation : portrait) and (-webkit-device-pixel-ratio: 2){
/* Styles */
}

/* iPhone 6+ ----------- */
@media only screen and (min-device-width: 414px) and (max-device-height: 736px) and (orientation : landscape) and (-webkit-device-pixel-ratio: 2){
/* Styles */
}

внутри которых на 90% копипаста. Можно, конечно, забить и по пути ЛОРа считать, что если пользователь сузил окно браузера до трети экрана, то он хочет видеть мобильный интерфейс (для ЛОРа это почему-то обозначает более мелкие шрифты).

Если браузер независимо от устройства поддерживает стандарты скажем цсс3, то на нем гарантированно отобразится так же

Проблема не в отображении, а в наличии/отсутствии нормального устройства ввода. Планшет и ноутбук даже разрешение одинаковое могут иметь и диагональ экрана. А сайт для них надо как-то разный рисовать.

monk ★★★★★
()
Ответ на: комментарий от shiva

там и дпи есть @media (min-resolution XXX dpi) {/рисуем кнопку маленькую, иначе по дефолту здоровую/}

И на MacOS retina получим огромные кнопки для мобильных инвалидов вместо нормальных.

monk ★★★★★
()
Ответ на: комментарий от monk

Писец, какой ты трудный. Ну освой препроцессор, чтобы меньше стилей писать.

Реально из пальца высосано. Вон сабж тебе никто не будет к устройству адаптировать вообще.

wandrien ★★
()
Ответ на: комментарий от monk

внутри которых на 90% копипаста

Ждем выхода следующей серии, в которой Монк знакомится с препроцессорами.

anonymous
()
Ответ на: комментарий от monk

И на MacOS retina получим огромные кнопки для мобильных инвалидов вместо нормальных.

Ты же вот вообще не занимаешься современной веб разработкой и не шаришь, но продолжаешь нести дичь и ересь. Зачем ты это делаешь?

anonymous
()
Ответ на: комментарий от shiva

Или еще там штук 10 свойств, которые не всеми браузерами популярными поддерживаются

Можно и штук 10: scroll-behavior, cross-fade, unset, revert, zoom, mask-repeat, mask-position, mask-clip, mask-size, mask-composite, cursor, subgrid, …

monk ★★★★★
()
Ответ на: комментарий от anonymous

Ты же вот вообще не занимаешься современной веб разработкой и не шаришь, но продолжаешь нести дичь и ересь. Зачем ты это делаешь?

Я и gemini не пользуюсь. Но это не повод не пообщаться о нём.

monk ★★★★★
()
Последнее исправление: monk (всего исправлений: 2)
Ответ на: комментарий от anonymous

Если считаешь, что это дичь и ересь, скажи сколько туда поставить, если для MacBook Pro Retina срабатывает min-resolution: 192dpi или min-resolution: 2dppx и они же срабатывают на iPad Mini 2?

На макбуке, очевидно, нужны нормальные кнопки, а на айпаде гигантские.

monk ★★★★★
()
Ответ на: комментарий от anonymous

Ты делаешь ЛЖИВЫЕ утверждаения о том, в чем не разбираешься.

Где? Пока лживые утверждения делаешь ты. Я уже пару раз цитировал. Или не ты, а другой анонимус, зарегистрируйся, что ли.

monk ★★★★★
()
Ответ на: комментарий от wandrien

Писец, какой ты трудный. Ну освой препроцессор, чтобы меньше стилей писать.

Вот я и освоил генератор сайтов, чтобы вообще стили не писать. В конце концов, сайт не самоцель.

monk ★★★★★
()
Ответ на: комментарий от wandrien

А в чем проблема прикрутить кэширование к клиенту в дальнейшем?

anonymous
()
Ответ на: комментарий от wandrien

Стоп. Но ведь на ЛОРе оно именно что рисует форму ответа в отдельной странице.

В отличие от любой другой борды.

anonymous
()
Ответ на: комментарий от monk

внутри которых на 90% копипаста

Тебе про @include рассказать? Или про возможность наследования?

anonymous
()
Ответ на: комментарий от monk

И вот ещё: https://thebestmotherfucking.website/

JS там только ради трекинга (ужас-ужас), а сам сайт очень няшный и там есть котик. Короче, правь свои кривые руки и не болтай о том, чего не знаешь.

anonymous
()
Ответ на: комментарий от anonymous

Этого, кстати, нельзя сказать о твоем сургут-софте. Ты вообще на него с мобилы заходил?

Конечно. Всё нормально: меню скрывается, разделы выстраиваются вертикально, кнопки крупные.

monk ★★★★★
()
Ответ на: комментарий от anonymous

Стоп. Но ведь на ЛОРе оно именно что рисует форму ответа в отдельной странице.

У регистрантов немного иначе выглядит. В теле страницы, с кнопкой предварительного просмотра на аяксе.

wandrien ★★
()
Ответ на: комментарий от monk

Конечно. Всё нормально: меню скрывается, разделы выстраиваются вертикально, кнопки крупные.

Допустим, для тебя это вырвиглазие — нормально. Теперь скажи, что из перечисленного нельзя сделать на CSS?

wandrien ★★
()

сохранения спецификации в минимальном, но удовлетворяющем пользовательские потребности виде

ii уже есть. @buratino, мало сепаров, тут ещё и конкуренты!

В разработке порт Lagrange на мобильные платформы!

J2ME когда будет?

mertvoprog
()
Ответ на: комментарий от fernandos

Вот есть библиотека для декларативного аякса: https://intercoolerjs.org/

Я не работал с ней. Не знаю, насколько она пригодна к внедрению «как есть». Возможно, требует доработок. Но мысль из примеров на сайте, думаю, понятна.

Если декларативный язык запросов из этой библиотеки реализовать в браузере, то можно делать приложения, как мы выше обсуждали: без JS, но с динамическим DOM.

Или другой вариант: js-код этой библиотеки добавить в список разрешений в блокировщике, а всё остальное запретить (включая код, внедрённый на страницу). Тогда не будет возможности исполнить произвольный JS на клиенте, а возможности останутся.

Второй путь, кстати, теоретически очень перспективен. Если:

  • Делать вот такие библиотеки, которые не требуют исполнения произвольного кода обвязки, а применяются к декларативному описанию в теле документа. То есть работают как самодостаточные приложения, для которых документ страницы — в прямом смысле документ (а не код).
  • Давать пользователю в настройках браузера явным образом разрешить или запретить отдельные такие приложения.

Например, тот же самый MathJax, в котором нет НИЧЕГО плохого, он по существу никак не ожирняет сайт, и за который меня тут почему-то пытались в чем-то уличить.

Включаешь MathJax в настройках, и у тебя на сайтах отображаются формулы. При этом никакого кода сайта не выполняется. А MathJax лежит у тебя на локалхосте, и ты можешь сам её проверить и провести аудит при желании.

Круто же, нет?

Я думаю, нужна какая-то общественная инициатива в этом направлении. Писать экстеншон для браузера и пиарить идею в тематических сообществах.

Идея еще и FSF-угодная, так как даёт весь код под контроль пользователя и делает его открытым. Проприетарный код с сайта не исполняем.

И доверенный сайт-каталог (под управлением той же FSF), в котором хранятся такие приложения.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 3)

Осилил тред. Очень понравилось как Monk сперва топит за аскетизм, а когда ему показывают его же сайт, переобувается в прыжке и доказывает, что фреймворки на js это здорово и необходимо. А окружающие при этом топят за html+css :)

lv ★★
()
Ответ на: комментарий от wandrien

Давать пользователю в настройках браузера явным образом разрешить или запретить отдельные такие приложения.

Предположу, что могут возникнуть проблемы с версиями. Одно дело, когда сервер отдаёт на исполнение свой код, точно зная что там, и другое - когда версии у библиотек у него и на стороне клиента должны совпадать для такой уверенности.

Может лучше стандартизованный API для каких-то нужных действий. А клиент уже на своей стороне может поддерживать это апи каким угодно кодом.

Хотя это, наверно, то, что и так уже есть. Но вот тип как запросить user-id. И клиент может с этим запросом делать что угодно.

lv ★★
()
Последнее исправление: lv (всего исправлений: 2)
Ответ на: комментарий от lv

Предположу, что могут возникнуть проблемы с версиями. Одно дело, когда сервер отдаёт на исполнение свой код, точно зная что там, и другое - когда версии у библиотек у него и на стороне клиента должны совпадать для такой уверенности.

Ничего страшного, если будет много версий. Если все они относятся к одному опенсорсному продукту и не содержат известных уязвимостей, позволяющих выполнить произвольный код в eval(), то для пользователя не важно, какую версию исполняет сайт. Сайт может исполнять ту, которую ему и требуется.

Можно хранить на локалхосте только хэш-суммы известных приложений, а код скачивать как обычно тэгом script. Для ресурсов уже предсмотрена проверка целостности через хэш-суммы, так что в самих тэгах ничего не изменится:

<script src="https://cdnjs.cloudflare.com/ajax/libs/intercooler-js/1.2.3/intercooler.min.js" integrity="sha512-cGFWDjclOPdq15RV16krqIZNRnaXehJpgwtcX+VrIO+UgOsdg3mURsdN27Z9PWnov+f8mZSPZfx14R7w+rSYOw==" crossorigin="anonymous"></script>

Зная хэш-сумму, браузер не обязательно даже будет скачивать код с указанного CDN. Он может обратиться к какому-нибудь собственному CDN, которым управляет некоммерческий фонд.

Далее нужно будет предусмотреть возможность инициализировать приложение с параметрами, нужными для сайта. Варианты:

  1. Позволить исполнять на странице небольшие фрагменты кода, выполняющие инициализацию этих приложений. Например, FSFшный плагин LibreJS позволяет исполнять код, который он автоматически определяет как «тривиальный». Что-то такое придумать. Так себе вариант, но можно попробовать реализовать, чтобы понять реальные drawbacks.
  2. Специфицировать декларативный протокол в виде json, позволяющий передать в приложение аргументы инициализации. Тут потребуются небольшие обертки под каждое приложение. Сначала, придётся их писать разработчикам этой идеи. А потом может подтянутся и авторы библиотек и сразу будут поставлять библиотеки с совместимыми API.

Может лучше стандартизованный API для каких-то нужных действий. А клиент уже на своей стороне может поддерживать это апи каким угодно кодом.

«Нужных действий» на все случаи жизни не напасёшься. Пусть браузер занимается непосредственно работой песочницы и API на уровне связи песочницы и внешнего мира. У них и так работы очень много в этой области. А на уровне логики внутри песочницы — можно управлять ею через вот такой контроль «приложений», или «протоколов», или «API». Тут суть не в названии, а в том, чтобы компонент, который обеспечивает управление такими прикладными API, был разработан и стандартизирован отдельно от движка браузера. Это позволит любой браузер с поддержкой экстеншенов превратить в совместимый с идеей.

И еще суть в том, что если вы используете обычный браузер, то в нём просто всёработает как обычно. Он исполняет код JS.

А используете браузер с такой защитой, то он… тоже просто исполняет код JS. Но весь код проверен, и есть гарантия, что это опенсорсный код без трекинга и закладок. А который не проверен, запрещен.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 2)
Ответ на: комментарий от lv

Еще одно преимущество забыл.

Это позволит пользователю вручную переопределять реализацию приложения.

Если оказалось, что версия с заданной хэш-суммой содержит баг, то можно пойти в настройки и указать, что нужно подменять её на версию с другой хэш-суммой, без бага. Для всех сайтов скопом или для выбранного.

То же самое можно делать в целях отладки, подменяя минифицированную версию обычной.

Или если в версии уязвимость, позволяющая исполнение недоверенного кода, можно оперативно через браузер уведомить всех пользователей и затем предложить заблокировать или подменить на известную исправленную версию.

wandrien ★★
()
Ответ на: комментарий от lv

А клиент уже на своей стороне может поддерживать это апи каким угодно кодом.

Это тоже можно. Если конкретное API реализовано нативно, браузер просто не грузит соответствующий скрипт. Скрипт в этом случае не более чем полифилл. При хорошей поддержке может получиться, что страница вообще ни строки кода JS не исполняет.

wandrien ★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от alt-tab-let

sdl2, новый cmake. нет, не судьба это собрать на шестом альте, а жаль :(

alt-tab-let ★★
()
Ответ на: комментарий от wandrien

Вроде прикольно! Но мне не по профилю.

lv ★★
()
Ответ на: комментарий от wandrien

Теперь скажи, что из перечисленного нельзя сделать на CSS?

При желании почти всё можно. Форму всплывающего чата на CSS не сделать.

monk ★★★★★
()
Ответ на: комментарий от wandrien

Если декларативный язык запросов из этой библиотеки реализовать в браузере, то можно делать приложения, как мы выше обсуждали: без JS, но с динамическим DOM.

Вот это реально было бы идеальное решение. Разрешить сразу открывать документы, а приложения на HTML/JS по дополнительному явному разрешению от пользователя.

monk ★★★★★
()
Ответ на: комментарий от monk

Вроде можно обойтись плагиноми к браузерам и серваком с доверенными хешсуммами. Но, ХЗ - позволяет ли тот же хром делать всё вышеописанное через плагин.

lv ★★
()
Ответ на: комментарий от monk
  1. Писать экстеншон для ff и хромого, реализующий такой контроль. Технически это что-то среднее между uBlock, Decentaleyes и LibreJS.
  2. Сделать сайт для проекта, где на ясном английском языке максимально детально разжевать суть инициативы.
  3. Сделать репозиторий с примерами открытого ПО на JS, подходящего по критериям. Допилить обертки при необходимости. Контактировать с апстримами на предмет, включат ли они обертки к себе.
  4. Сделать сайты-примеры.
  5. Контактировать с энтузиастами похожих взглядов, чтобы они на своих сайтах обеспечили совместимость с идеей.
  6. Контактировать с FSF, чтобы они поддержали и пропиарили.

петицию в FSF писать?

Вам всё лишь бы петиции писать…

wandrien ★★
()
Ответ на: комментарий от lv

Но, ХЗ - позволяет ли тот же хром делать всё вышеописанное через плагин.

Сначала сделать для ff.

Хром — не знаю, есть ли отличия. Нужен контроль содержимого страницы до запуска исполнения кода на ней.

wandrien ★★
()
Ответ на: комментарий от wandrien

Хром — не знаю, есть ли отличия. Нужен контроль содержимого страницы до запуска исполнения кода на ней.

decentraleyes в хроме есть. Правда к нему исходников нет. Те, что на gitlab - для ff.

monk ★★★★★
()

Правильно ли я понимаю, что аналога POST-запросов в gemini нет, а есть только GET с ограничением на длину в 1024?

Если так, то форум на этом чуде без костылей не сделать.

anonymous
()
Ответ на: комментарий от wandrien

Если декларативный язык запросов из этой библиотеки реализовать в браузере, то можно делать приложения, как мы выше обсуждали: без JS, но с динамическим DOM.

Да, но когда это будет сделано?

Или другой вариант: js-код этой библиотеки добавить в список разрешений в блокировщике, а всё остальное запретить (включая код, внедрённый на страницу). Тогда не будет возможности исполнить произвольный JS на клиенте, а возможности останутся.

Тогда надо будет всех переубедить использовать эту библиотеку.

Круто же, нет?

Так-то неплохо выходит.

Я думаю, нужна какая-то общественная инициатива в этом направлении. Писать экстеншон для браузера и пиарить идею в тематических сообществах.

Идея определённо интересна, да, думаю, судя по htmx, она даже используется где-то.

fernandos ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.