Thank you for adding the feature so fast, @prologic@twtxt.net! Look at how beautiful this one renders now. Oh my!

@lyse@lyse.isobeef.org Just as an aside, shouldn’t you assume utf-8 anyway these days if not specified? 🤔 I mean basically everything almost always uses utf-8 encoding right? 😅

@quark@ferengi.one Okay fair 👌

@movq@www.uninformativ.de So basically on-call, but you don’t get paid for it? 🤔

@prologic@twtxt.net sorry but nope. Neither jenny, nor yarnd supports it at all. This was treated as a thread because I picked one of @falsifian@www.falsifian.org’s twtxts (with the “old subject”), and replied to it (hence starting the thread).

@quark@ferengi.one aye aye captain 🤣

@quark@ferengi.one It’s a good thin yarnd makes this user configurable via a preference 🤣 And displays both 😅

@quark@ferengi.one LOL 😂 Thanks!

@quark@ferengi.one You are right, whilst it technically works, its not well supported. Too much of the code would have to change to support that, and it’s not worth the value.

Oh, and you can’t imagine the level of control I am commandeering by restraining me from editing that previous “missing-one-backtick” twtxt. LOL!

So yeah no, whilst it technically works, neither jenny nor yarnd support it very well. Only at a very basic level.

It actually has treated this as a thread, but it gets a bit weird, because we thread based on the content address of a root twt.

@aelaraji@aelaraji.com this is the little script I am using on my publish_command:

#!/usr/bin/env bash

twtxt2html -t "Quark's twtxt feed" /var/www/sites/ferengi.one/twtxt.txt > /var/www/sites/ferengi.one/index.html

I named it twtxtit. :-)

@prologic@twtxt.net based on @falsifian@www.falsifian.org’s findings, I don’t believe this is quite accurate.

“yarnd(_at least_) doesn't support creating such a custom TwtSubject, but it will reply and respect and thread one if one was constructed."

@falsifian@www.falsifian.org yes, that happened around 2 years ago, on commit 5923078ea5.

Make that three issues. Mostly because the other two were feeling kind of lonely. So, yeah. Ha!

@quark@ferengi.one It looks like the part about traditional topics has been removed from that page. Here is an old version that mentions it: https://web.archive.org/web/20221211165458/https://dev.twtxt.net/doc/twtsubjectextension.html . Still, I don’t see any description of what is actually allowed between the parentheses. May be worth noting that twtxt.net is displaying the twts with the subject stripped, so some piece of code is recognizing it as a subject (or, at least, something to be removed).

Opened a couple of issues on twtxt2html. Maybe @prologic@twtxt.net will get to them after he has completed his luxurious recharging cycle. LOL.

@lyse@lyse.isobeef.org fully agree. I have never been a fan of relative times to begin with, so that one will go away, foh sho! :-D

@falsifian@www.falsifian.org based on Twt Subject Extension, your subject is invalid. You can have custom subjects, that is, not a valid hash, but you simply can’t put anything, and expect it to be treated as a TwtSubject, me thinks.

Hmm, but yarnd also isn’t showing these twts as being part of a thread. @prologic@twtxt.net you said yarnd respects customs subjects. Shouldn’t these twts count as having a custom subject, and get threaded together?

yarnd just doesn’t render the subject. Fair enough. It’s (replyto http://darch.dk/twtxt.txt 2024-09-15T12:50:17Z), and if you don’t want to go on a hunt, the twt hash is weadxga: https://twtxt.net/twt/weadxga

@sorenpeter@darch.dk I like this idea. Just for fun, I’m using a variant in this twt. (Also because I’m curious how it non-hash subjects appear in jenny and yarn.)

URLs can contain commas so I suggest a different character to separate the url from the date. Is this twt I’ve used space (also after “replyto”, for symmetry).

I think this solves:

• Changing feed identities: although @mckinley@twtxt.net points out URLs can change, I think this syntax should be okay as long as the feed at that URL can be fetched, and as long as the current canonical URL for the feed lists this one as an alternate.
  
• editing, if you don’t care about message integrity
  
• finding the root of a thread, if you’re not following the author
  

An optional hash could be added if message integrity is desired. (E.g. if you don’t trust the feed author not to make a misleading edit.) Other recent suggestions about how to deal with edits and hashes might be applicable then.

People publishing multiple twts per second should include sub-second precision in their timestamps. As you suggested, the timestamp could just be copied verbatim.

@falsifian@www.falsifian.org I can confirm, it’s fixed. Thank you! Indeed, this is some wild quoting.

I still do not understand why the encoding suddenly broke, though. :-? Anyway. I concentrate on my rewrite and do things the right™ way. ;-) Still long ways to go.

@aelaraji@aelaraji.com yes, it is ignoring the template right now. I also test it. So, something’s broken, @prologic@twtxt.net.

@bender@twtxt.net I know, I know… A relative time in a static HTML document is questionable at best. ;-)

@prologic@twtxt.net I have some ideas:

• Add smartypants rendering, just like Yarn has.
  
• Add the ability to create individual twtxts, each named after their hash.
  
• Fix the formatting of the help. :-P

Woot, yes! It works perfectly. By the time you see my twtxt, it is already at the main Ferengi.one website.

OK, OK, the third time is the charm. Maybe?

Hmm, this didn’t work, because I made a mistake. Now I have corrected it, let’s see how it goes now.

Trying to figure out how to use the publish_command to vomit the HTML into a file, using twtxt2html.

@bender@twtxt.net that’s not your change, silly robot, it is mine! LOL. I am finding @prologic@twtxt.net’s tool handy to refer to previous posts (as reference, for example).

@aelaraji@aelaraji.com this is my change on main.go (but it can be done on a template now, so no reason to touch the code):

                                 <time class="dt-published" datetime="{{ $twt.Created | date "2006-01-02T15:04:05Z07:00" }}">
                                        {{ $twt.Created | date "2006-01-02 15:04:05 MST" }}
                                  </time>

See https://ferengi.one. I am going to further customise things, but that’s a start.

@bender@twtxt.net LOL normally things (in the vanilla template) render like <time class="dt-published" datetime="2024-09-17T15:05:19+01:00"> 2024-09-17 14:05:19 +0000 UTC+0000 </time> the datetime=... atribute is in my local time UTC+1 then the text within the tag is in UTC+0

The thing is, I’ve been poking at the template as well, but nothing changes. I literally whole portionsm added in lorem text just to see if it would do anything, then twtxt2html -T ./layout.html <link to twtxt file> | less shows same thing as before! nothing changes. LOL I’m not sure I’m going at it the right way.

Never mind this one, figured it out. I am so silly! :-D

What’s wrong with the timestamps, @prologic@twtxt.net? See https://aelaraji.com/log.html, all are +0000 UTC+0000. Same on a local test I am running.

I tried changing {{ $twt.Created | date "2006-01-02T15:04:05Z07:00" }} to {{ $twt.Created | date "2006-01-02T15:04:05" }}, but no dice. I don’t really care about the timezone. LOL.

It should be fixed now. Just needed some unusual quoting in my httpd.conf: https://mail-archive.com/misc@openbsd.org/msg169795.html

@lyse@lyse.isobeef.org Sorry, I don’t think I ever had charset=utf8. I just noticed that a few days ago. OpenBSD’s httpd might not support including a parameter with the mime type, unfortunately. I’m going to look into it.

@lyse@lyse.isobeef.org Ouch. 🥴 Well, jenny always decodes as UTF-8 (because the spec says so) and this hasn’t caused any issues – yet.

@prologic@twtxt.net It’s not “true” oncall duty (I don’t do that anymore, it fucks up your life and health), but more of an unwritten rule that sysadmins should have a smartphone. If there is an emergency and I happen to have time to help, I will. But nobody can force me to. So far, it works for us.

And, well, I also need that thing for 2FA. 😅

Now WTF!? Suddenly, @falsifian@www.falsifian.org’s feed renders broken in my tt Python implementation. Exactly what I had with my Go rewrite. I haven’t touched the Python stuff in ages, though. Also, tt and tt2 do not share any data at all.

By any chance, did you remove the ; charset=utf-8 from your Content-Type: text/plain header, falsifian?

interpreted in some crappy windows charset

How difficult will it be for you to modify this, so that can also spit out individual HTML files named after the twtxt hash, using a similar template?

@prologic@twtxt.net ah! Something like this:

<!DOCTYPE html>
<html lang="en">
  <head>
    <link rel="stylesheet" href="https://cdn.simplecss.org/simple.min.css">
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0">
    <title>{{ .Title }}</title>
  </head>
	<body class="preload">
	  <main class="container">
		{{ range $_, $twt := $.Twts }}
		  <article id="{{ $twt.Hash }}" class="h-entry">
			<div class="u-author h-card">
			  <div class="dt-publish">
				<a class="u-url" href="#{{ $twt.Hash }}">
				  <time class="dt-published" datetime="{{ $twt.Created | date "2006-01-02T15:04:05Z07:00" }}">
					{{ $twt.Created }}
				  </time>
				</a>
				<span>&nbsp;{{ $twt.Created | time }}</span>
				<a class="u-search" href="https://search.twtxt.net/twt/{{ $twt.Hash }}">(search)</a>
			  </div>
			</div>
			<div class="e-content">
			  {{ formatTwt $twt }}
			</div>
		  </article>
		{{ end }}
	  </main>
	</body>
</html>

@movq@www.uninformativ.de Non-ASCII characters were broken. Like U+2028, degrees (°), etc.

Turns out I used a silly library to detect the encoding and transform to UTF-8 if needed. When there is no Content-Type header, like for local files, it looks at the first 1024 bytes. Since it only saw ASCII in that region, the damn thing assumed the data to be in Windows-1252 (which for web pages kinda makes sense):

// TODO: change default depending on user's locale?
return charmap.Windows1252, "windows-1252", false

https://cs.opensource.google/go/x/net/+/master:html/charset/charset.go;l=102

This default is hardcoded and cannot be changed.

Trying to be smart and adding automatic support for other encodings turned out to be a bad move on my end. At least I can reduce my dependency list again. :-)

I now just reject everything that explicitly specifies something different than text/plain and an optional charset other than utf-8 (ignoring casing). Otherwise I assume it’s in UTF-8 (just like the twtxt file format specification mandates) and hope for the best.

@movq@www.uninformativ.de for oncall?

@movq@www.uninformativ.de Haha 🤣

@prologic@twtxt.net I’m pretty much required to have one. 🫤

@prologic@twtxt.net No, wait, I removed something else. But I think it was never supported in the first place. 😅 Probably because nobody used it (which is probably because you didn’t implement a UI for them 😅).

@movq@www.uninformativ.de this is why I don’t have a work phone 🤣

@bender@twtxt.net I should put the template that is used by default as a file in the repo. Look at the source for now and you’ll see 😅