~nytpu

Colorado

https://git.nytpu.com/

i've migrated to my self-hosted code repo, see: https://git.nytpu.com/

~nytpu/public-inbox

Last active 6 months ago
View more

Recent activity

Re: [PATCH v2] Add the short story compilation The King in Yellow by Robert W. Chambers 3 days ago

From Alex // nytpu to ~mieum/booksin.space

On 2021-06-12 12:22AM, mieum wrote:
> Would you like me to wait on this until we decide about the gempub
> generation mechanism/syntax? 
Yeah, that'd be best IMO

~nytpu

-- 
Alex // nytpu
alex@nytpu.com
gpg --auto-key-locate=wkd --locate-key alex@nytpu.com
Key fingerprint: 43A5 890C EE85 EA1F 8C88 9492 ECCD C07B 337B 8F5B
https://useplaintext.email/

Re: Possibly including gempubs alongside regular gemtext 3 days ago

From Alex // nytpu to ~mieum/booksin.space

On 2021-06-11 09:41AM, mieum wrote:
> So, for instance, headings preceeded by a '%' could indicate a
> chapter?  The added bonus of doing something like this is being able
> to automatically generate a ToC or break up long texts by chapter for
> non-gempub versions.
I like this.  Simple, and it automatically includes chapter titles to
the index/ToC.  In that case then we'd either need to start numbering
headers in the gemtext itself or have the converter script auto-number
the chapters, because gemtext doesn't auto-number for us usually.

> Another option would be to have a ToC key in the YAML frontmatter that
> specifies the names of the chapters (with some default values for
> indicating that every heading is a chapter or that there are no
> chapters etc.). This would eliminate the need for extra markup, but I

Re: Possibly including gempubs alongside regular gemtext 4 days ago

From Alex // nytpu to ~mieum/booksin.space

Accidentally wrote directly to mieum instead of to the list.

On 2021-06-10 10:35AM, mieum wrote:
> Ah, I see. I guess having fewer quality gempubs is better than a ton
> of awkward ones that slaughter the content. In that case I will update
> the readme with a link to the gempub spec and some notes about
> contributing them.
So is that a nack on possibly adding YAML (or something) throughout the
document to indicate where to break apart a file into separate files?

Thinking about it more it wouldn't add that much more for contributors
(just add markup every chapter break while you're converting to gemtext)
and it'd be pretty easy to convert from the one-page format to gempub if
you have actual markers on where to split it up (and also some

[PATCH v2] Add the short story compilation The King in Yellow by Robert W. Chambers 4 days ago

From nytpu to ~mieum/booksin.space

---
Added title and byline to body text itself.
 cataloging/chambers_the-king-in-yellow.gmi | 4087 ++++++++++++++++++++
 1 file changed, 4087 insertions(+)
 create mode 100644 cataloging/chambers_the-king-in-yellow.gmi

diff --git a/cataloging/chambers_the-king-in-yellow.gmi b/cataloging/chambers_the-king-in-yellow.gmi
new file mode 100644
index 0000000..00d04d8
--- /dev/null
+++ b/cataloging/chambers_the-king-in-yellow.gmi
@@ -0,0 +1,4087 @@
---

[message trimmed]

Re: [PATCH] Add the short story compilation The King in Yellow by Robert W. Chambers 5 days ago

From Alex // nytpu to ~mieum/booksin.space

On 2021-06-09 01:43PM, mieum wrote:
> Should this file have a title heading + byline? Is it preferrable to
> programatically insert those using the metadata, or to have
> contributors format submissions with a title and byline themselves?
I think it should.  In my opinion (I don't know what you envisioned),
you should be able to strip out all YAML and other such elements and get
a standalone gemtext document without having to make any modifications,
which means it should include all title, byline, and possibly copyright
info at the bottom.

Depending on how you decide formatting should possibly be changed, I'll
probably make a revision once some more stuff is finalized.

Thanks!

Re: Possibly including gempubs alongside regular gemtext 5 days ago

From Alex // nytpu to ~mieum/booksin.space

On 2021-06-09 11:44PM, mieum wrote:
> I think gempubs are a great idea! Is there a particular reason you
> suggest them to be optional?
It is a minor to major amount of extra work when making them by hand,
and I didn't want to burden extra contributors too much.

> It seems that gempub archives could be generated for each item easily
> enough at the time of cataloging.
I'd say that properly splitting up an arbitrary book into a gempub
programatically (without manual intervention and reediting at least)
would be very difficult.  However, generating the format used by
booksin.space from a gempub is very easy.  In fact, to create my The
King in Yellow submission I just took my gempub version and did
`cat [0-9]-*.gmi >> book.gmi`

[PATCH] Add the short story compilation The King in Yellow by Robert W. Chambers 5 days ago

From nytpu to ~mieum/booksin.space

To note: Like how the author metadata field is lastname, firstname for
sorting purposes, I made the title field have a suffix "the" to
facilitate sorting.

Also, if my proposal about including gempubs is accepted, there is a
gempub for The King in Yellow available here:
gemini://nytpu.com/gpubs/the-king-in-yellow.gpub
(I can send another patch adding it if necessary)
---
 cataloging/chambers_the-king-in-yellow.gmi | 4084 ++++++++++++++++++++
 1 file changed, 4084 insertions(+)
 create mode 100644 cataloging/chambers_the-king-in-yellow.gmi

diff --git a/cataloging/chambers_the-king-in-yellow.gmi b/cataloging/chambers_the-king-in-yellow.gmi
[message trimmed]

Possibly including gempubs alongside regular gemtext 5 days ago

From Alex // nytpu to ~mieum/booksin.space

As a possible suggestion, could we (optionally) include gempubs[a]
alongside the regular gemtext versions of a book?  We could be like
Project Gutenberg where you can read in your Gemini browser, or you
could download the ebook version and read in your preferred ereader
software.

If the book's already in gemtext format, then to convert to gempub all
you do is split up the chapters into different files, add an index page,
add some metadata stuff (basically the same as booksin.space's metadata
anyways) and zip it up.

And I suggest that making gempubs is optional.  As in, booksin.space is
primarily a regular Gemini library, that sometimes has gempubs as a
bonus.

[PATCH kineto] Add -e flag to place a stylesheet externally rather than loading it inline 14 days ago

From nytpu to ~sircmpwn/gmni-devel

By default, kineto loads a stylesheet given to -s from disk and places
it inline with the HTML in a <style>...</style> block.  This patch adds
a -e flag to load a stylesheet externally.  When the -e flag is passed
with a URI (relative or absolute), the given link is placed in the href
of a <link rel="stylesheet"...> tag.  This helps facilitate caching
which can *significantly* reduce request overhead, particularly when the
stylesheet is large (>= the size of the page content).

The given URI is not validated, and if it is invalid the browser will
404 when requesting it and the page will have no style.
---
 README.md | 14 +++++++---
 main.go   | 77 +++++++++++++++++++++++++++++++++----------------------
 2 files changed, 58 insertions(+), 33 deletions(-)
[message trimmed]

Re: Upcoming changes to TLS support in gmni & gmnisrv 3 months ago

From Alex // nytpu to ~sircmpwn/gmni-discuss

As a genuine question, may I ask why you chose BearSSL to switch to?  I
understand why OpenSSL is...not a wonderful library to put it kindly,
but BearSSL has the worst TLS 1.3 support out of any of the major
libraries, and TLS 1.3 is more important for Gemini than most other
applications of TLS considering how insecure client certificates are in
TLS 1.2[0], plus the fact that TLS 1.2 is only "reluctantly" allowed in
Gemini and "TLS 1.3 or higher may be specced [once TLS libraries get
better 1.3 support]," which most libraries other than BearSSL have.

I just have concerns about future compatibility.  BearSSL hasn't had a
new release since 2018[1] and that it's averaged well under 0.3 commits
per month for the past three years[2], which isn't giving me hope that
the six print pages of to-do for TLS 1.3 support[3] will ever be
completed.