Working on Yoda - GTK browser for Gemini protocol
https://github.com/YGGverse/Yoda
Currently, trying to complete user certificate integration, it works for BBS as ?register query but on Station, URI have /join sub-path, so by protocol specification, can't give the authorization to the parent area (entire domain in this case), but how does it work in other browsers?
Maybe miss some line in specification or just must to ignore URI follow for 6* status codes
Thanks for any help!
https://geminiprotocol.net/docs/protocol-specification.gmi#client-certificates Certificates specification
1 month ago
https://github.com/YGGverse/Yoda
https://geminiprotocol.net/docs/protocol-specification.gmi#client-certificates
Once I hope to change backend with native rust libraries, drop SQLite also, as dependent of C bindings.
At this moment, Iced framework and redb looks well for these needs, but not ready for now, because already spent ~1400 hours for development.
At least I'm waiting for first stable Cosmic releases and maybe for Redox-OS updates. For now I'm already using Yoda as the main browser, plan to add Titan protocol soon. Of course, not everything implemented yet but comparing to other GTK clients this one allow to use TLS client certs and have classic Adwaita UI.
Thank you for feedback! 路 1 week ago
I've created official subspace on BBS where sometimes posting project news:
gemini://bbs.geminispace.org/s/Yoda 路 1 week ago
gemini://bbs.geminispace.org/s/Yoda
Once I hope to change backend with native rust libraries, drop SQLite also, as dependent of C bindings.
At this moment, Iced framework and redb looks well for these needs, but not ready for now, because already spent ~1400 hours for development.
At least I'm waiting for first stable Cosmic releases and maybe for Redox-OS updates. For now I'm already using Yoda as the main browser, plan to add Titan protocol soon. Of course, not everything implemented yet but comparing to other GTK clients this one allow to use TLS client certs and have classic Adwaita UI.
Thank you for feedback! 路 1 week ago
@yggverse I see! I stumbled upon it randomly and to my great surprise! I remembered this thread of yours and I did remember at least that Yoda was in Rust so I was like鈥hat?!!! PHP? 馃槻
I thought that maybe I should bring this to your attention 鈥斅爈ooks like there was no need to.
Good luck with your project! I tried building Yoda myself, but failed because one of the GTK libraries required for building one of the crates, "libspelling-1" IIRC, isn't available in Void 鈥斅爐he distro I use. And I'm too much of a lazy ass to build that myself so I've given up 馃槄 路 1 week ago
@m0xee already sent PR #227 that currently not merged. Yoda was re-written in Rust/GTK-4 and thoughts now to remake it using Iced framework, instead of GTK. CPP/PHP versions available as the separated branches anyway. 路 1 week ago
Did you originally plan to implement it in PHP?
In awesome-gemini it's currently listed as:
Yoda (PHP-GTK) - Experimental browser for Gemini Protocol based on PHP-GTK and gemini-php.
I think it's time to update that 馃槅 路 1 week ago
Cool, I heard about it! About Rust, I'm learning yet, also wrote few branches in CPP and PHP before. it's first experience, like GTK and desktops apps at all :) Some features should be refactored, no ideas when 1.0 release could be ready, as currently stuck with session resumption as Glib does not provide this API, so can't change certificate in runtime.. 路 1 month ago
My browser is also written in Rust, so we could benefit from reading each other's code :). I'm using Iced as the GUI toolkit and rustls instead of openssl, so it's all rust-native.
In my case, I've chosen to let users use full regular expressions to match client certificates to URLs. Want to match by querystring, path, domain? Sure, all valid. I'm still not entirely convinced though, it requires a lot of work for the user...
https://sr.ht/~lufte/vimini/ 路 1 month ago
Just personally, will prefer query than path for next server-side solutions, because path customization imho is just an extension, requires additional client-side feature support
The scope of a certificate generated in response to this status code should is limited to the host and port from which the status code was received and the path of the URL in the original request plus all paths below it.
What is your browser, is it GTK / Glib? 路 1 month ago
@lufte thanks for replies, got some feedback also in this thread:
gemini://bbs.geminispace.org/s/Yoda/22093
Don't know what to do, maybe just will append additional options into selection window, like it already implemented in Lagrange. Of course, client able to provide any options to user, but this confuses a bit. As found in replies, some services could be older than protocol specification updates :) 路 1 month ago
gemini://bbs.geminispace.org/s/Yoda/22093
In my browser, users have to manually generate certificates and authorize them to URL patterns. So even if I wasn't following these instructions at the time of writing my code, I still think it follows the new spec as the user is intentionally creating a certificate and assigning it to specific a context, and they are not generated in response to a code 60 (I think... depends on what that means). You may choose to do the same: as long as the user is accepting to use that certificate for the entire domain, you're free to do it. 路 1 month ago
Hmm, I hadn't yet taken a look at this section of the new spec. I think the key parts in there are that
1. It's talking about certificates generated in response to a code 60. I guess clients may still choose to not create any certificate in that circumstance. I actually find confusing what this means exactly: how do we determine a certificate was generated "in response" to it?
2. It says the client must not reuse certificates generated in response to a code 60 "unless directed to do so by the user". 路 1 month ago