@aelaraji@aelaraji.com make sense, probably. The twtxt was already on my Maildir, that’s why I can fetch it. I fetch every 3 minutes (sssh, don’t tell anyone!). LOL!

More:

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
        somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
        what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
        `(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
        twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?

Notice the difference? Soren edited, and broke everything.

@sorenpeter@darch.dk

Also what are the change that the same human will make two different posts within the same second?!

Just out of curiosity, What would happen someday if I (maybe trolling) edit my twtxt.txt-file manually and switch/switch a couple of twt timestamps, or add in 3 different twts manually with the same time stamp?

@mckinley@twtxt.net Thanks for the feedback.

1. Yeah I agrees that nick sound not be part of syntax. Any valid URL to a twtxt.txt-file should be enough and is more clear, so it is not confused with a email (one of the the issues with webfinger and fedivese handles)
   
2. I think any valid URL would work, since we are not bound to look for exact matches. Accepting both http and https as well as a gemni and gophe could all work as long as the path to the twtxt.txt is the same.
   
3. My idea is that you quote the timestamp as it is in the original twtxt.txt that you are referring to, so you can do it by simply copy/pasting. Also what are the change that the same human will make two different posts within the same second?!
   

Regarding the whole cryptographic keys for identity, to me it seems like an unnecessary layer of complexity. If you move to a new house or city you tell people that you moved - you can do the same in a twtxt.txt. Just post something like “I move to this new URL, please follow me there!” I did that with my feeds at least twice, and you guys still seem to read my posts:)

The tag URI scheme looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be somewhat trivial to parse. But there are still the issue with what the name/id should be… Maybe it doesn’t have to bee that stick?

Instead of using tag: as the prefix/protocol, it would more it clear what we are talking about by using in-reply-to: (https://indieweb.org/in-reply-to) or replyto: similar to mailto:

1. (reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)
   
2. (in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   
3. (replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)
   

I know it’s longer that 7-11 characters, but it’s self-explaining when looking at the twtxt.txt in the raw, and the cases above can all be caught with this regex: \([\w-]*reply[\w-]*\:

Is this something that would work?

I was not suggesting to that everyone need to setup a working webfinger endpoint, but that we take the format of nick+(sub)domain as base for generating the hashed together with the message date and content.

If we omit the protocol prefix from the way we do things now will that not solve most of the problems? In the case of gemini://gemini.ctrl-c.club/~nristen/twtxt.txt they also have a working twtxt.txt at https://ctrl-c.club/~nristen/twtxt.txt … damn I just notice the gemini. subdomain.

Okay what about defining a prefers protocol as part of the hash schema? so 1: https , 2: http 3: gemini 4: gopher ?

Interesting.. QUIC isn’t very quick over fast internet.

QUIC is expected to be a game-changer in improving web application performance. In this paper, we conduct a systematic examination of QUIC’s performance over high-speed networks. We find that over fast Internet, the UDP+QUIC+HTTP/3 stack suffers a data rate reduction of up to 45.2% compared to the TCP+TLS+HTTP/2 counterpart. Moreover, the performance gap between QUIC and HTTP/2 grows as the underlying bandwidth increases. We observe this issue on lightweight data transfer clients and major web browsers (Chrome, Edge, Firefox, Opera), on different hosts (desktop, mobile), and over diverse networks (wired broadband, cellular). It affects not only file transfers, but also various applications such as video streaming (up to 9.8% video bitrate reduction) and web browsing. Through rigorous packet trace analysis and kernel- and user-space profiling, we identify the root cause to be high receiver-side processing overhead, in particular, excessive data packets and QUIC’s user-space ACKs. We make concrete recommendations for mitigating the observed performance issues.

https://dl.acm.org/doi/10.1145/3589334.3645323

@falsifian@www.falsifian.org In my opinion it was a mistake that we defined the first url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:

# url = https://example.com/alias/txtxt.txt
# url = https://example.com/initial/twtxt.txt
<message 1 uses the initial URL>
<message 2 uses the initial URL, too>
# url = https://example.com/new/twtxt.txt
<message 3 uses the new URL>
# url = https://example.com/brand-new/twtxt.txt
<message 4 uses the brand new URL>

In theory, the same could be done for prepend-style feeds. They do exist, I’ve come around them. The parser would just have to calculate the hashes afterwards and not immediately.

On the Subject of Feed Identities; I propose the following:

1. Generate a Private/Public ED25519 key pair
   
2. Use this key pair to sign your Twtxt feed
   
3. Use it as your feed’s identity in place of # url = as # key = ...
   

For example:

$ ssh-keygen -f prologic@twtxt.net
$ ssh-keygen -Y sign -n prologic@twtxt.net -f prologic@twtxt.net twtxt.txt

And your feed would looke like:

# nick        = prologic
# key         = SHA256:23OiSfuPC4zT0lVh1Y+XKh+KjP59brhZfxFHIYZkbZs
# sig         = twtxt.txt.sig
# prev        = j6bmlgq twtxt.txt/1
# avatar      = https://twtxt.net/user/prologic/avatar#gdoicerjkh3nynyxnxawwwkearr4qllkoevtwb3req4hojx5z43q
# description = "Problems are Solved by Method" 🇦🇺👨‍💻👨‍🦯🏹♔ 🏓⚯ 👨‍👩‍👧‍👧🛥 -- James Mills (operator of twtxt.net / creator of Yarn.social 🧶)

2024-06-14T18:22:17Z	(#nef6byq) @<bender https://twtxt.net/user/bender/twtxt.txt>  Hehe thanks! 😅 Still gotta sort out some other bugs, but that's tomorrows job 🤞
...

Twt Hash extension would change of course to use a feed’s ED25519 public key fingerprint.

Pinellas County Running: 3.02 miles, 00:08:52 average pace, 00:26:46 duration
just needed to get out. first run since the PTC and felt great.
#running

Base: 3.00 miles, 00:10:35 average pace, 00:31:45 duration
test full gear, cool down with ice, and 3’/1’ pacing strategies.
#running #treadmill

Base: 3.00 miles, 00:10:01 average pace, 00:30:03 duration
testing cool down strategy with ice on the neck.
#running #treadmill

@prologic@twtxt.net This does not seem to fix the problem for me, or I’ve done something wrong. I did the following:

1. Pull the latest version from git (I have commit 7ad848, same as on twtxt.net I believe).
   
2. make build and make install
   
3. Restart yarnd
   
4. Refresh cache in Poderator Settings
   

Yet I still see these bogus /external things on my pod when I hit URLs like the one I sent you recently. When I hit such a URL with curl I think it’s giving an error? But in a web browser, the (buggy) response is the same as it was before I updated.

So, this problem is not fixed for me.

@lyse@lyse.isobeef.org I have no Idea, I still haven’t found a repair shop I can trust with my monitor. As for the blackouts, they don’t have consistent frequency. Sometimes it’s once every 3 months… other times it’s 3 times a day 😂

Pinellas County Running: 3.03 miles, 00:10:00 average pace, 00:30:18 duration
little sprinkle so tried to get out and enjoy it, but only caught a few minutes. just took it easy.
#running

You might have seen me popping up on IRC. This is how it looks:

https://movq.de/v/3a4f9833f3/

That’s EZirc from the 1990ies. (It says it needs Warp 4, but runs fine on Warp 3.)

Lots of this old stuff still works (technically), but as @lyse@lyse.isobeef.org said: A lot of it really is dead. There’s not much going on anymore in Usenet.

HTTP/2 differs from 1.x by becoming a binary protocol, it also multiplexes multiple channels over the same connection and has the ability to prefetch related content to the browser to lower the perceived latency.

HTTP/3 moves the binary protocol from HTTP/2 over to QUIC which is based on UDP instead of TCP. This makes it better suited to mobile or unstable networks where handling of transmission errors can be handled at a higher level.

Does anyone know what the differences between HTTP/1.1 HTTP/2 and HTTP/3 are? 🤔

Pinellas County - Recovery: 3.25 miles, 00:10:04 average pace, 00:32:44 duration
relaxed running to flush the legs out a bit before bowling with some friends. both of my shoes came undone which has not happened in years to that was a bit odd.
#running

@stigatle@yarn.stigatle.no @prologic@twtxt.net testing 1 2 3 can either of you see this?

I deleted them all right before I sent my previous message, and already, a few minutes later, there are two more:

abucci@buc:~$ du -sh /tmp/yarnd-avatar-3*
1.8G    /tmp/yarnd-avatar-3122347915
2.4G    /tmp/yarnd-avatar-3533381443

What is this?

Je suis tellement fatigué de la bêtise humaine. 1/3, je croise forcément ces gens… Je ne peux m’empêcher de penser à mes élèves, mes MEILLEURS élèves, + assidûs et intelligents que les autres, qui ont laissé un proche au fond de la méditerranée… ne me parlez pas ce soir :/

Pinellas County - Cool down: 2.35 miles, 00:09:59 average pace, 00:23:27 duration
walked about ¾ mile and then started c/d run. felt strong so endurance is in a great spot!
#running

Asked ChatGPT 3 yesterday to tone down an angry message I had to send, as in make it still polite, but make sure to get the message across, and it succeeded pretty well.

Pinellas County - Fun run: 3.14 miles, 00:08:29 average pace, 00:26:39 duration
just a fun run in the rain
#running

Hmm…

Jun 19 23:31:38 yarn_init.sh[61567]: [yarnd] 2024/06/19 23:31:38 (127.0.0.1:40254) “POST /post HTTP/
1.0” 200 0 3.402208ms
[…]

Jun 19 23:31:39 yarn_init.sh[61567]: [yarnd] 2024/06/19 23:31:39 (127.0.0.1:40262) “GET /post HTTP/1.0” 404 729 123.474001ms

Pinellas County - Fun run: 3.02 miles, 00:08:39 average pace, 00:26:09 duration
blow off stress between meeting followed by an excuse to go outside with no comms.
#running

Base: 3.19 miles, 00:09:50 average pace, 00:31:21 duration
finishing it up
#running #treadmill

@prologic@twtxt.net 1. allow only members of your pod to submit feeds

1. some kind of captcha (eew)
   
2. probationary status after submittal which requires review of some sort
   
3. rate limiting to slow down submissions from the same source

Recovery: 3.11 miles, 00:10:55 average pace, 00:33:54 duration

#running #treadmill

Pinellas County - Long run 3’(mod) [1’ rec]: 7.47 miles, 00:09:46 average pace, 01:13:02 duration
again practicing the 3’ on and 1’ off strategy. thinking i will have to just be flexible and adapt it as the day goes on for PTC. bit of a hot one out there today.
#running

Base: 3.11 miles, 00:09:48 average pace, 00:30:26 duration
quick 5km on the tread. pre-cinco de mayo meal.
#running #treadmill

Recovery: 3.11 miles, 00:10:41 average pace, 00:33:10 duration

#running #treadmill

Started writing something from scratch yesterday using thread(3) and wow do I miss writing in Limbo instead. :-/ #plan9

Whoo! 🥳 I won 2 of my 3 singles tonight! 🏓

If you’re using jenny on Python 3.12, it will spit out a deprecation warning regarding datetime.utcnow(). This will be fixed in the next release.

Pinellas County - Long Run: 10.19 miles, 00:09:43 average pace, 01:39:03 duration
practicing 3 minutes running and one minute walking. not only for the knee but also for the PTC (~46.6 miles) coming in about 17 weeks. the knee actually hurt a little the first 5 miles but afterwards nothing. not sure if i finally found my stride but it felt great once the dull pain was gone.
#running

Pinellas County - Base: 3.19 miles, 00:10:30 average pace, 00:33:28 duration
had to stop due to pain in the left knee. run was light. pain at the beginning.
#running

Pinellas County - Recovery: 3.03 miles, 00:09:07 average pace, 00:27:36 duration
this felt really easy today which was surprising since yesterdays run hurt (knee). curious if the S&C beforehand helped things out a bit. it was hot and humid, but there was a nice breeze for some of it so i didn’t feel the heat until the last mile.
#running

Pinellas County - Long Run: 8.07 miles, 00:10:41 average pace, 01:26:18 duration
at about mile 3 i switched to 4’ on 1’ off. this was because my left knee started to act up. kept this up pretty well until a weird sharp pain at about 7.5 miles. walked it off a bit and tried again but called it when things did not feel right.
#running

Voidlinux : mes retours sont très positifs. 3 points : 1 - les paquets sont rapidement publiés, la vuln du paquet xz a donc été rapidement installée. 2 - Suite install de openssl en v3-3, authent 802.1x HS avec wpa_suppliant. J’ai dû rollback. 3 - Sur laptop HS mon écran scintille parfois quand la souris passe vers le bas de l’écran, étrange.

3,5%, c’est tout, juste 3,5%… https://escapethecity.life/en-manifestation-troquer-les-armes-contre-des-roses

Apparemment, #pluxml n’aime pas php 8.3 :/

Pinellas County - Recovery: 3.13 miles, 00:10:05 average pace, 00:31:35 duration
easy run to blow off steam and test out the leg and hip. after the squats and lunges today my body was happy with a 10:00 pace. had some discomfort in the left hip at around 2.60 miles but it quickly went away. overall it was a pleasant run in the evening.
#running

UDF is where its at. Not some silly red or blue book that cant even have more than 8+3 filenames!

Pinellas County Running: 3.16 miles, 00:08:30 average pace, 00:26:52 duration
aiming for whatever felt easy. the humidity really was heavy with a light fog. woke up with no real pain and it was not until the end of the run where i felt a slightly sharp pain around my left glute and a bit in the left hip as well. thinking i need to reduce mileage a bit and try to train around it until i feel good enough to get back in to a routine again.
#running

Moderate: 3.02 miles, 00:09:02 average pace, 00:27:18 duration
testing out the left knee again, but in the real world. it was fine. took it easy but not super easy so it was a good test.
#running

Easy: 3.00 miles, 00:10:01 average pace, 00:30:02 duration
just an easy run after a few days resting the knee. had a few pings the first half mile and then it went away until about 2.75 miles in. called it soon after.
#running #treadmill

Sad to see moc removed from the official arch linux repos, but also cool to learn the debian project has been quietly patching it and keeping it up to date in recent years. Long live the music on console player. (And debian!) :-)