~seirdy

California, US

https://seirdy.one

My handle is “Seirdy” on most of the platforms I use.

Website, contact: https://seirdy.one

Gemini: gemini://seirdy.one

My preferred forge for personal projects is Sourcehut, but my repositories have remotes for GitHub and GitLab too.

~seirdy/moac

Last active 2 months ago

~seirdy/seirdy.one-comments

Last active 7 months ago

~seirdy/public-inbox

Last active 1 year, 7 months ago
View more

Recent activity

bitlang: document dependency on btprnt 5 days ago

From Rohan Kumar to ~pbatch/public-inbox

Bitlang depends on your "btprnt" library, which can be hard to discover 
with a package manager or web search. This should be documented in the 
bitlang README.

-- 
/Seirdy

Request for feedback from server/client implementers using\n non-OpenSSL TLS stacks 2 months ago

From Rohan Kumar to ~adnano/gemini

On Mon, Nov 08, 2021 at 01:57:53AM +0000, tidux at sdf.org wrote:
>It looks like BearSSL is just waiting for the TLS 1.3 RFC to be
>finalized, which is a totally reasonable thing to do.  I would encourage
>a similar level of patience for Gemini mandating TLS 1.3.

TLS 1.3 was finalized in 2018:
https://datatracker.ietf.org/doc/html/rfc8446

This is acknowledged in the first sentence of BearSSL's TLS 1.3 status 
page:
https://bearssl.org/tls13.html

> Long draft periods cause early adopters to have all kinds of wonderful
> broken implementations that must then be worked around until the next

Request for feedback from server/client implementers using\n non-OpenSSL TLS stacks 2 months ago

From Rohan Kumar to ~adnano/gemini

TLDR: skip to the last paragraph ("In conclusion: ...").

On Sun, Nov 07, 2021 at 08:00:29PM +0100, Drew DeVault wrote:
>Hi! We use BearSSL for gmni/gmnlm/libgmni, and intend to move to BearSSL
>for gmnisrv at some point in the future. It does not presently support
>TLS 1.3 and it's unclear when it will ship.
>
>https://git.sr.ht/~sircmpwn/gmni
>https://git.sr.ht/~sircmpwn/gmnisrv

I find the idea of using BearSSL for gmnisrv a bit concerning. As a 
popular Gemini server, switching to a TLS lib that doesn't support TLS 
1.3 could make a lot of capsules TLS 1.2-only.

Re: [PATCH] Fix some spelling mistakes 2 months ago

From Rohan Kumar to ~seirdy/moac

Thanks, applied.

-- 
/Seirdy

Re: [PATCH] CLI: warn if grapheme clusters are detected 2 months ago

From Rohan Kumar to ~seirdy/moac

Thanks; I'll apply this and also add it to go.mod/go.sum.

-- 
/Seirdy

A proposal to freeze the Gemini specification 2 months ago

From Rohan Kumar to ~adnano/gemini

On Tue, Oct 26, 2021 at 06:44:23AM +0000, Robert "khuxkm" Miles wrote:
>I'm of the opinion that TOFU is perfectly fine in this scenario. The 
>only thing I think would be good as an addition to Gemini is a way to 
>deprecate a certificate. As it stands, if your capsule gets compromised 
>there is no way to stop clients from recognizing the compromised 
>certificate as valid. That being said, as you mentioned, that's more of 
>a thing that can be decided out-of-band and doesn't really require the 
>Gemini spec to change.

The initial request can also be MITM'd, which can be mitigated by 
verifying the key "out-of-band". This "out-of-band" thing shouldn't be 
Gemini itself but ideally something completely different and possibly 
generalizable to non-Gemini scenarios.

A proposal to freeze the Gemini specification 2 months ago

From Rohan Kumar to ~adnano/gemini

A TLDR: the ecosystem can evolve without changing/breaking the existing 
spec. Let's freeze the spec soon!

On Mon, Oct 25, 2021 at 11:21:04PM +0000, mntn wrote:
>I think you may be asking for a heavier process than is warranted. It 
>is my personal hope that there will be no further versions of the spec 
>once finalized,

Agreed that the Gemini spec seems feature-complete for now. There was a 
time when I would've liked to see features like compression and tables, 
but the spec doesn't prevent anyone from serving up an alternate 
mimetype like text/gemini+gzip or csv. Clients like Lagrange can load a 
CSV document from a link as an inline table just like they load inline 
images (following a user gesture, ofc). This is a good example of adding

A proposal to freeze the Gemini specification 2 months ago

From Rohan Kumar to ~adnano/gemini

On Mon, Oct 25, 2021 at 11:21:04PM +0000, mntn wrote:
>I think you may be asking for a heavier process than is warranted. It 
>is my personal hope that there will be no further versions of the spec 
>once finalized,

A TLDR: the ecosystem can evolve without changing/breaking the existing 
spec. Let's freeze the spec soon!

Agreed that the Gemini spec seems feature-complete for now. There was a 
time when I would've liked to see features like compression and tables, 
but the spec doesn't prevent anyone from serving up an alternate 
mimetype like text/gemini+gzip or csv. Clients like Lagrange can load a 
CSV document from a link as an inline table just like they load inline 
images (following a user gesture, ofc). This is a good example of adding

WolfSSL 2 months ago

From Rohan Kumar to ~adnano/gemini

On Sat, Oct 23, 2021 at 02:32:59PM -0700, Rohan Kumar wrote:
>I think WolfSSL and BearSSL are interesting projects as far as minimal 
>TLS implementations go, but I'd personally like to see more love for 
>stuff like libtls (simple spinoff of libressl with a much simpler API), 
>or Boringssl (extremely well-made TLS lib that also provides the crypto 
>primitives for libs like Rust's ring and RusTLS). Libtls would be an 
>especially good fit for Gemini software.

A good primer on libtls from 2017 is over at 
https://ftp.openbsd.org/papers/linuxconfau2017-libtls/. Many 
OpenSSL-based distros also ship the "libretls" package, which is a 
confusingly-named port of libtls from libressl to OpenSSL; this should 
make it easy to strike a balance between reducing boilerplate and 
improving packageability/portability.

WolfSSL 2 months ago

From Rohan Kumar to ~adnano/gemini

On Sat, Oct 23, 2021 at 06:33:02PM +0000, Jonathan McHugh wrote:
>I noticed WolfSSL has TLS 1.3, its other features seem decent too (1/20 
>size OpenSSL, ANSI C).
>
>However, I couldnt find any links on Gemini or HTTP concerning any 
>implementations or tools using it.
>
>Any ideas regarding it?
>
>Would it be worth me developing clients and servers in it? I get the 
>idea that some of the other TLS approaches have a lot of cruft given 
>their scale and predisposition to non-Germini protocols and it would 
>interest me to embed from a bespoke Gemini only compilation.
>