Image

its replacing the contents of body for some reason.

@prologic@twtxt.net Hi. i have noticed sometimes when i hit the back button i lose all the surrounding layout and just have a list of twts.

Image

@yarn_police@twtxt.net I am noticing crimes around here, but I am too afraid to say anything (points at Lyse with mouth movements, no muttering a single word). Help us, officer!

Hahahahahaahaaaahaaaaaa, brilliant! I love it, @bender@twtxt.net! :‘-D

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

@lyse@lyse.isobeef.org matter of fact, earlier you posted:

2024-09-19T20:20:00+02:00	I don't like Australians!

And then deleted it, fearing the Australian Mafia (which, as we know, is very powerful in Bavaria). But I got the hash for it, p5zdahq, and that timestamp has tt written all over it. That’s my proof! 😅😅😅

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

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

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

@david@collantes.us Such a funny picture – we’ve been to Florida once some ~30 years ago and it looked almost exactly like that. 😅

@david@collantes.us Yeah, but it happened so fast with him. 😅 I remember watching some of his talks 1-3 years ago, looked completely different, I think. 😅

Luckily I can still recognize the voice, so I know it’s him, lol.

@lyse@lyse.isobeef.org The hash/thread-id would be shorter, but you’d lose two other benefits of (replyto:…):

1. You need a special client again to compute hashes.
   
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that I’ve implemented it) – but now you’ve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.

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.

@lyse@lyse.isobeef.org Right, feed rotation gets ugly. We’d have (replyto:example.com/tw.txt,$timestamp) but maybe that feed doesn’t actually contain that stamp, so you have to got further back … but you should NOT reference an archived feed in your (replyto:…) thingy, it should still be the “main feed URL” (because the contents of archived feeds aren’t stable, see @prologic@twtxt.net’s feeds for example). That’s not too great.

Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂

… then, of course, I wouldn’t need to ask a Yarn pod for a certain twt if we used (replyto:…) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.

Only when the original feed has gone offline will querying a Yarn pod become relevant again.

I have to admit here that some of the goals/philosophy of Yarn simply don’t apply to my use cases. 😅 I don’t run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I don’t have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isn’t one of my goals. It’s a completely different thing for me. Hmmm. 🤔

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

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

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

@quark@ferengi.one Yeah, let’s see what they reveal!

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

I’m bad with faces, I know that. But I’m having a really hard time recognizing Linus in this video:

https://www.youtube.com/watch?v=4WCTGycBceg

Basically a different person to me. Is it just me or has he really changed that much? 😳

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:

Image

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/

@david@collantes.us Glad you like it. 😅

@david@collantes.us Aye, I’ve pushed some commits. (And this is really going to be the last non-trivial change. 😂)

@david@collantes.us Like that, right? https://movq.de/v/80f888d381/s.png

Okay, the recently implemented --fetch-context, which asks a Yarn pod for a twt, wouldn’t break, but jenny would not be able anymore to verify that it actually got the correct twt. That’s a concrete example where we would lose functionality.

@david@collantes.us Yeah, I was annoyed by this myself lately. twts have become so long nowadays, it really gets in the way.

@prologic@twtxt.net Can you come up with actual scenarios where it would break? Or is it more of a gut feeling?

The thing that keeps bugging me is this:

If we were to switch to location-based addressing and (replyto:…), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround “to avoid broken threads all the time”.) The net result would be less code.

Implementing this whole (edit:#hash) thing means more code. (For jenny, specifically, a lot more code, if I want to allow users to create such twts.)

Do you see why I’m so reluctant to jump on this bandwagon? 😅

I haven’t come up yet with good, concrete examples where (replyto:…) would break. As soon as that happens, I’ll change my mind. 🤔

For implementations, it would be nice if “update twts” always came after the twt they are referring to. So I thought about using this opportunity to mandate append-style feeds. But that’s just me being lazy. Implementations will have to be able to cope with any order, because feeds cannot/should not be trusted. 🫤

@david@collantes.us I think we can!

Trying to sum up the current proposal (keeping hashes):

1. Extend the hash length to avoid collisions.
   
2. Introduce the concept of, what shall we call it, “update twts”.
   
   • A twt starting with (edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.
     
   • A twt starting with (delete:#3f36byq) advises clients to delete #3f36byq from their storage.
     

Right?

@prologic@twtxt.net

you’d never have been able to find let alone pull up that ~3yr old Twt of me (my very first), hell I’d even though I lost my first feed file or it became corrupted or something

I get what you mean, but to be fair, it’s much less mysterious than that. 😅 The twt in question exists in your archived feed. It’s not like I pulled it out of some cache of an unrelated Yarn pod.

But, yes, I could have done that and I could have verified that it actually is the twt I was looking for. So that’s clearly an advantage of the current system.

e.g: Shutdown yarnd and cp -a yarn.db yarn.db.bak before testing this PR/branch.

Can I get someone like maybe @xuu@txt.sour.is or @abucci@anthony.buc.ci or even @eldersnake@we.loveprivacy.club – If you have some spare time – to test this yarnd PR that upgrades the Bitcask dependency for its internal database to v2? 🙏

VERY IMPORTANT If you do; Please Please Please backup your yarn.db database first! 😅 Heaven knows I don’t want to be responsible for fucking up a production database here or there 🤣

nevermind; I think this might be some changes internally in Go 1.23 and a dependency I needed to update 🤞

Can someone much smarter than me help me figure out a couple of newly discovered deadlocks in yarnd that I think have always been there, but only recently uncovered by the Go 1.23 compiler.

https://git.mills.io/yarnsocial/yarn/issues/1175

Location Addressing is fine in smaller or single systems. But when you’re talking about large decentralised systems with no single point of control (kind of the point) things like independable variable integrity become quite important.

What is being proposed as a counter to content-addressing is called location-addressing. Two very different approaches, both with pros/cons of course. But a local cannot be verified, the content cannot be be guaranteed to be authenticate in any way, you just have to implicitly trust that the location points to the right thing.

For example, without content-addressing, you’d never have been able to find let alone pull up that ~3yr old Twt of me (my very first), hell I’d even though I lost my first feed file or it became corrupted or something 🤣 – If that were the case, it would actually be possible to reconstruct the feed and verify every single Twt against the caches of all of you 🤣

@david@collantes.us I really thinks articles like this explain the benefits far better than I can.

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

@david@collantes.us Oh ! 🤦‍♂️

@david@collantes.us Witout including the content, it’s no longer really “content addressing” now is it? You’re essentially only addressing say nick+timestamp or url+timestamp.

@prologic@twtxt.net how about hashing a combination of nick/timestamp, or url/timestamp only, and not the twtxt content? On edit those will not change, so no breaking of threads. I know, I know, just adding noise here. :-P

Speaking of AI tech (sorry!); Just came across this really cool tool built by some engineers at Google™ (currently completely free to use without any signup) called NotebookLM 👌 Looks really good for summarizing and talking to document 📃

@eldersnake@we.loveprivacy.club Yeah I’m looking forward to that myself 🤣 It’ll be great to see where technology grow to a level of maturity and efficiency where you can run the tools on your own PC or Device and use it for what, so far, I’ve found it to be somewhat decent at; Auto-Complete, Search and Q&A.

@prologic@twtxt.net That’s definitely a little less depressing, when thinking of it that way 🤣 Be interesting when the hype dies down.

I’m not the biggest Apple fan around, but that is pretty awesome.

@sorenpeter@darch.dk I really don’t think we can ignore the last ~3 years and a bit of this threading model working quite well for us as a community across a very diverse set of clients and platforms. We cannot just drop something that “mostly works just fine” for the sake of “simplicity”. We have to weight up all the options. There are very real benefits to using content addressing here that really IMO shouldn’t be disregarded so lightly that actually provide a lot of implicit value that users of various clients just don’t get to see. I’d recommend reading up on the ideas behind content addressing before simply dismissing the Twt Hash spec entirely, it wasn’t even written or formalised by me, but I understand how it works quite well 😅 The guy that wrote the spec was (is?) way smarter than I was back then, probably still is now 🤣

@falsifian@www.falsifian.org Right I see. Yeah maybe we want to avoid that 🤣 I do kind of tend to agree with @xuu@txt.sour.is in another thread that there isn’t actually anything wrong with our use of Blake2 at all really, but we may want to consider all our options.