(#tr42vzq) @bender@twtxt.net Yeah, it was nice. 23°C and a bit of wind. Quite acceptable in my opinion. :-)

(#luu7z7q) @prologic@twtxt.net @movq@www.uninformativ.de In all reality, even seconds precision would be enough for this new feed announcement bot. It just has to delay or predate its messages. It hopefully does not find new feeds all the time. :-)

(#5sdepuq) @prologic@twtxt.net What should happen if the archive chain is detected to be broken? I don’t think that including the hash in the prev field does really help us in reality. What if messages in the archive feed themselves got lost? You can’t detect this unless you’ve already known about them. I reckon we can simply use the relative path and call it good. I know, I know, we have this format already today. But in my opinion, the hash does not add value.

(#5sdepuq) @prologic@twtxt.net The Content-Type should probably even include the charset=utf-8 as we learned recently. :-) Iff you want to keep the UTF-8 encoding mandatory. It doesn’t say anything about it in that document.

(#5sdepuq) @prologic@twtxt.net The reply-to can come anywhere in the message text? Most examples even put it at the very end. Why relax that? It currently has to be at the beginning, which I think makes parsing easier. I have to admit, at the end makes reading the raw feed nicer. But multi-line messages with U+2028 ruin the raw feed reading experience very quickly.

(#5sdepuq) @prologic@twtxt.net For hash calculation we could maybe rethink the newlines and use tabs instead. This is more in line with the twtxt file format itself. With tabs it also is much closer to the registry format (minus the nick).

What about the timestamp format? Just verbatim as it appears in the feed (what I would recommend) or any other shenanigans with normalization, like +00:00 → Z?

An append style is not required, btw. If one uses prepend style feeds, the new URL simply comes at the beginning of the file, where the old URL is further down.

Clients must use the full-length hash in their storages, but only use the first eleven digits when referencing? This differentiation is a bit odd.

(#5sdepuq) @prologic@twtxt.net The multline example is broken. I don’t see any “pipes”.

(#5sdepuq) @prologic@twtxt.net I notice that in your document it says reply-to, where in the ReplyTo Extension it’s without the hyphen. (But they also use different values after the colon. :-))

(#crmwgxq) Thanks again for typing it up, @movq@www.uninformativ.de! I left a few comments there. Currently, I’m in favor of the location-based adressing, that’s heaps simpler.

(#vp2b7ha) @sorenpeter@darch.dk Excellent point! I agree.

(#senmxza) @bender@twtxt.net @prologic@twtxt.net @aelaraji@aelaraji.com Everything entering over Pod Gossiping is only cached temporarily, but never archived. So, it eventually fell off the cache. If my fake feeds were still up, yarnd would have pulled it from me again. I ran into the situation locally as well and then got it back, though.

(#s2dhlvq) @movq@www.uninformativ.de I cases of these kind of “abuse” of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.

(#crmwgxq) Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?

(#crmwgxq) @movq@www.uninformativ.de Awesome, thank you very much! I’ll have a look at it tomorrow.

It was beautiful in nature: https://lyse.isobeef.org/waldspaziergang-2024-09-21/

(#rqkdcfa) @prologic@twtxt.net Let me try:

Invent anything you want, say feed A writes message text B at timestamp C. You simply create the hash D for it and reply to precisely that D as subject in your own feed E with your message text F at timestamp G. This gets hashed to H.

Now then, some a client J fetches your feed E. It sees your response from time G with text F where in the subject you reference hash D. Since client J does not know about hash D, it simply asks some peers about it. If it happens to query your yarnd for it, you could happily serve it your invention: “You wanna know about hash D? Oh, that’s easy, feed A wrote B at time C.”

The client J then verifies it and since everthing lines up, it looks legitimate and puts this record in its cache or displays it to the user or whatever. It does not even matter, if the client J follows feed A or not. The message text B at C with hash D could have just deleted or edited in the meantime.

Congrats, you successfully spread rumors. :-D

(#y6idegq) @prologic@twtxt.net This does not hold if the edit happened before I even got the original.

(#4so6mga) @falsifian@www.falsifian.org Something similar exists over at https://search.twtxt.net/. But a usable search engine would be actually nice (to be fair, yarns improved a bit). :-) I don’t care about feed changes over time. In fact, it would even feel creepy to me. Of course, anyone could still surveil, but I’m not looking forward to these stats.

(#s4s2r2a) @movq@www.uninformativ.de We could still let the client display a warning if it cannot verify it. But yeah.

(#2p5ulxq) @movq@www.uninformativ.de Reminds me of this beautiful face recognition failure: https://qz.com/823820/carnegie-mellon-made-a-special-pair-of-glasses-that-lets-you-steal-a-digital-identity :-D

(#zogbtrq) @prologic@twtxt.net What exactly?

(#rqkdcfa) @prologic@twtxt.net Just what @bender@twtxt.net did. :-D If he’d additionally serve the fake message from his yarnd twt endpoint, everybody querying that hash from him (or any other yarnd that synced it in the meantime) would believe, that I didn’t like Australians.

In fact, I really don’t. I love’em! 8-)

We would need to sign each message in a feed, so others could verify that this was actually part of that feed and not made up. But then we end up in the crypto debate for identities again, which I’m not a big fan of. :-)

I just want to highlight, one might get a false sense of message authenticity, if one just briefly looks at the hashes.

(#i6qqvqq) @movq@www.uninformativ.de Ah, cool. :-)

(#fj7dppq) It just occurs to me we’re now building some kind of control structures or commands with (edit:…) and (delete:…) into feeds. It’s not just a simple “add this to your cache” or “replace the cache with this set of messages” anymore. Hmm. We might need to think about the consequences of that, can this be exploited somehow, etc.

(#s4s2r2a) @movq@www.uninformativ.de Not sure if I like the idea of keeping the original message around. It goes against the spirit of an edit in my mind.

If that’s what we want to enforce, forget about my other message above in the thread.

(#y6idegq) @prologic@twtxt.net @movq@www.uninformativ.de I still don’t understand it. If the original message has been replaced with the edited one, I cannot verify that the original was in the same feed. I don’t know the original text.

(#zoktkgq) @prologic@twtxt.net what time in UTC?

(#kdtce4q) @falsifian@www.falsifian.org hiya from the Sunshine State (also known as a never-ending hell, LOL)!

(#xwvocwa) @falsifian@www.falsifian.org this one hits hard, as jenny was just updated today. :‘-(

(#7qe266a) Hahahahahaahaaaahaaaaaa, brilliant! I love it, @bender@twtxt.net! :‘-D

(#fj7dppq) @movq@www.uninformativ.de Thanks for the summary!

So, what would happen if there is no original message anymore in the feed and you encounter an “edit” subject? Since you cannot verify that the feed contained it in the first place, would you obey it?

Some feed could just make a client update something from a different feed. In the cache, the client would need to store in a flag that this message was updated, so that when it later encounters the message from the real feed, it has a chance of reverting that bogus edit. Hmm. The devil is in the detail.

It’s much easier with a delete subject. When it finds the message in its cache and the feeds match, remove it. Otherwise, just ignore it.

(#i6qqvqq) @movq@www.uninformativ.de Right. That’s why, I’d bite the bullet and go for huge URLs. :-)

I havent’t looked at the code and I’m too lazy right now, does jenny also verify the fetched result against the hash?

(#ucgvfmq) @movq@www.uninformativ.de Yeah, but hashing also uses the main feed URL or whatever is written in the feed’s first url metadata field. So, it’s not a new problem, it’s exactly the same.

(#l5452vq) @lyse@lyse.isobeef.org indeed! There is no “central authority” acting as witness, and notary. The more I think of it… LOL.

(#2p5ulxq) @movq@www.uninformativ.de @david@collantes.us Yeah, he got a bit older but I could still easily recognize him.

(#l5452vq) Another thing: At the moment, anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves. Nobody can ever verify that this was never the case in the first place and completely made up. So, our twt hashes have to be taken with a grain of salt.

(#i6qqvqq) @david@collantes.us Cool idea actually! The hash would also be shorter than the raw URL and timestamp.

(#l5452vq) @prologic@twtxt.net I get where you’re coming from. But is it really that bad in practice? If you follow any link somewhere in the web, you also don’t know if its contents has been changed in the meantime. Is that a problem? Almost never in my experience.

Granted, it’s a nice property when one can tell that it was not messed with since the author referenced it.

(#ucgvfmq) @movq@www.uninformativ.de The more I think about it, the more do I like the location-based addressing. That feels fairly in line with the spirit of twtxt, just like you stated somewhere else.

The big downside for me is that the subjects then become super long.

And if the feed relocates, we end up with broken conversation trees again. Just like nowadays. At least it’s not getting worse. :-)

Using the feed URL in there might become a little challenging for new folks, when the twt rotates away into archive feeds. But I reckon, we already have a similar situation with the hashes. So, probably not too bad.

(#uvc5xea) @quark@ferengi.one Yeah, let’s see what they reveal!

(#2p5ulxq) @movq@www.uninformativ.de I recognise him, but yes, he has aged quite a bit. I mean, I look at myself in the mirror and can’t, often, recognise myself. Ageing is a bitch! 😅

(#sjak2ta) Nice, @david@collantes.us! The winter palms look nice. And the sky is full of snow.

Yesterday, both temperature and wind picked up. There was even wind in the night, which is rare over here. Today, we also got a lot of sunshine, around 22°C and heaps of wind. The leaves and twigs were blown at the house door, it reminded me of a snow drift, basically a leave bank. I should have taken a photo before I swept it, it looked quite bizarre.

But I photographed something else instead:

My mate and I went out in the woods earlier and we came across 08 which broke off in roughly 6, 7 meters from 09. When it hit the ground, it made a 30 cm deep hole. Quite impressive. https://lyse.isobeef.org/waldspaziergang-2024-09-19/

(#pgi2jkq) I mean, really, it couldn’t get any better. I love it!

(#pgi2jkq) @movq@www.uninformativ.de perfect in every way. Configurable too! Thank you!

(#pgi2jkq) @movq@www.uninformativ.de yes, that’s perfect! <3

(#vq422aa) @eldersnake@we.loveprivacy.club I wanted to ask you, are you running Headscale and WireGuard on the same VPS? I want to test Headscale, but currently run a small container with WireGuard, and I wonder if I need to stop (and eventually get rid of) the container to get Headscale going. Did you use the provided .deb to install Headscale, or some other method?

(#xghlsva) @prologic@twtxt.net I read it. I understand it. Hopefully a solution can be agreed upon that solves the editing issue, whilst maintaining the cryptographic hash.

(#xghlsva) @prologic@twtxt.net I know the role of the current hash is to allow referencing (replies and, thus, threads), and it also represents a “unique” way to verify a twtxt hasn’t been tampered with. Is that second so important, if we are trying to allow edits? I know if feels good to be able to verify, but in reality, how often one does it?

@movq@www.uninformativ.de could it be possible to have compressed_subject(msg_singlelined) be configurable, so only a certain number of characters get displayed, ending on ellipses? Right now the entire twtxt is crammed into the Subject:. This request aims to make twtxts display on mutt/neomutt, etc. more like emails do.