@quark@ferengi.one @aelaraji, because a screenshot speaks better than a thousand words:

Original:

Modified:

I mean, this: https://darch.dk/timeline/replies?url=http://darch.dk/twtxt.txt

@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!

@aelaraji@aelaraji.com check “Replies”. :-D

@bender@twtxt.net I can’t see ANY of those LOL not even a broken thread. The whole Thread went Poof!! as if it has never happened …

Bonus: On his Pod/Profile it shows as if his last twt is from 4 Months ago.

@aelaraji@aelaraji.com fetch from the highlighted twtxt:

Spoiler: Didn’t work. LOL

@quark@ferengi.one No can do! I can’t see any of the replies to that thread, not even mine LOL. let me se if I can fetch @sorenpeter@darch.dk ’s feed with the https link.

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.

Two different “from” too:

"sorenpeter (soren)" <sorenpeter>
sorenpeter <sorenpeter>

See:

Message-Id: <hns535a@twtxt>
X-twtxt-feed-url: https://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>

And

Message-Id: <weadxga@twtxt>
X-twtxt-feed-url: http://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>

Two feed URLs, one HTTPS, the other HTTP.

@aelaraji@aelaraji.com no, it is not just you. Do fetch the parent with jenny, and you will see there are two messages with different hash. Soren did something funky, for sure.

@quark@ferengi.one here is an example: This Thread is not showing up in Mutt 🤔 Something is off!

I’ll set up jenny and mutt on another computer and see how it goes from there.

@aelaraji@aelaraji.com hmm, I see all of your twtxts just fine. Now, that’s a puzzle!

Something odd just happened to my twtxt timeline… A bunch of twts dissapered, others were marked to be deleted in mutt. so I nuked my whole twtxt Maildir and deleted my ~/.cache/jenny in order to start with a fresh Pull. I pulled feed as usual. Now like HALF the twts aren’t there 😂 even my my last replay. WTF IS GOING ON? 🤣🤣🤣

@mckinley@twtxt.net based on @falsifian@www.falsifian.org’s findings (something we have talked about before on IRC as well), because collisions can occur now, maybe what you describe might not happen. It will be sort of… chaotic, for sure.

@sorenpeter@darch.dk All valid points. Maybe the correct way to do it should be to start a new feed at the new URL rather than move the feed and break all the hashes.

@aelaraji@aelaraji.com

switch a couple of twt timestamps

The hashes would change and your posts would become detached from their replies. Clients might still have the old one cached, so you might just create a duplicate without replies depending on an observer’s client.

add in 3 different twts manually with the same time stamp

The existing hash system should be able to keep them separate as long as the content is different. I’m not sure if there are additional implementation-related caveats there.

@prologic@twtxt.net @bender@twtxt.net As someone who likes cryptocurrencies for their utility as money instead of an investment, I’m glad to see the hype train start to move on to the next thing.

@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?

@bender@twtxt.net Hahahahaha 🤣 Me neither 🤮

@prologic@twtxt.net It’s all I’m using … I have barely touched any other social media since I’ve discovered Twtxt back in April 😂 maybe a little bit of Mastodon and IRC, bluesky even less, but nothing else worth mentioning.

@prologic@twtxt.net oh, I am sure crypto is innate… for some people. Not me! :-D

@bender@twtxt.net you’re probably right, but by that argument, cryptocurrency should be innate too right? as we no longer hear about that gold awful hype, right? 🤔

@movq@www.uninformativ.de Thanks mate! 🤗

@prologic@twtxt.net when it becomes innate. There was a time, I am sure (but don’t know for sure, LOL), that all “we” heard about was electricity. No much these days, right?

@movq@www.uninformativ.de Haha same and I’m sick of it! It’s ruining innovation in anything else 🤦‍♂️

@movq@www.uninformativ.de Nice one 👌

@aelaraji@aelaraji.com it’s definitely your social bubble. 🤣 you need to use twtxt more as your daily driver 🤣

@aelaraji@aelaraji.com Must be your bubble. All I hear is “AI this”, “AI that”. 😂😭

@movq@www.uninformativ.de looks like a good compromise! Updating as soon as I reach home. Thank you!

@prologic@twtxt.net didn’t it already? or is it just me and my social bubble? 🤔

Keys for identity are too much for me. This steps up the complexity by a lot. Simplicity is what made me join twtxt with its extensions. A feed URL is all I need.

Eventually, twt hashes have to change (lengthen at least), no doubt about that. But I’d like to keep it equally simple.

Alright, I saw enough broken threads lately to be motivated enough to extend the --fetch-context thingy: It can now ask Yarn pods for twt hashes.

https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html

This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.

@prologic@twtxt.net Congratz 🥳

@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:)

@falsifian@www.falsifian.org @prologic@twtxt.net @sorenpeter@darch.dk @lyse@lyse.isobeef.org I think, maybe, the way forward here is to combine an unchanging feed identifier (e.g. a public key fingerprint) with a longer hash to create a “twt hash v2” spec. v1 hashes can continue to be used for old conversations depending on client support.

@sorenpeter@darch.dk That could work. There are a few things that jump out at me.

1. Nicknames on twtxt have historically been set on the client end. The nick metadata field is an optional add-on to the spec. I’m not sure it should be in the reply tag because it could differ between clients.
   
2. URLs are safer to use, and we use them in the hash currently, but they can still change and we’re back to square 1. Feeds ought to have some kind of persistent identifier for this reason, which is why we’ve been discussing cryptographic keys and tag URIs in the first place.
   
3. The current twt hash spec mandates collapsing the timestamp to seconds precision. If those rules are kept, two posts made within the same second will not be separate when someone replies.

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?

@prologic@twtxt.net When the next hype train departs. :-)

Thank you @aelaraji@aelaraji.com, I’m glad you like it. I use PHP because it’s everywhere on cheap hosting and no need for the user to log into a terminal to setup it up. Timeline is not mean to be use locally. For that I think something like twtxt2html is a better fit. (and happy to see you using simple.css on you new log page;)

Crap, I can’t find how and why rdomain is not set using /etc/hostname.if #openbsd

That’s an interesting side effect to the new Discover feature that I added sometime ago that only displays one post per feed. That is when you’re not logged in and viewing my pod’s front page. You can pretty easily and roughly see what the monthly active view account is just by looking at the pager size. 🤔

Amazingly though it seems to be slightly better to VPN in. 🤔

But you know speedtest.net I believe is a bit of a liar and I’m quite sure they do something to make sure the speed test come up good even remote areas the real speed test my actual surfer infrastructure is quite piss poor 🤣

Even though we’re quite a ways from any suburban areas, even with the Internet access via cell towers this poor, using my pod is still very snappy. 👌

When will the AI hype die down?

@lyse@lyse.isobeef.org Thanks!

@stigatle@yarn.stigatle.no Yeah, the sudden drop makes it feel worse than it is. It made me wear a beanie and gloves on my bike ride on Friday evening. In a few weeks I consider the same temperatures not an issue anymore, maybe even nicely warm. ;-) The body is fairly quick to adopt, but not that fast.

I just saw that we’re supposed to hit 19°C mid next week again. Let’s see.