jenny was just updated today. :'-(
jenny was just updated today. :'-(
its replacing the contents of body for some reason.
its replacing the contents of body for some reason.
I don't think we need to decide all at once. If clients add support for a new method then people can use it if they like. The downside of course is that this costs developer time, so I decided to invest a few hours of my own time into a proof of concept.
With apologies to @movq for corrupting jenny's beautiful code. I don't write this expecting you to incorporate the patch, because it does complicate things and might not be a direction you want to go in. But if you like any part of this approach feel free to use bits of it; I release the patch under jenny's current LICENCE.
Supporting both kinds of reply in jenny was complicated because each email can only have one Message-Id, and because it's possible the target twt will not be seen until after the twt referencing it. The following patch uses an sqlite database to keep track of known (url, timestamp) pairs, as well as a separate table of (url, timestamp) pairs that haven't been seen yet but are wanted. When one of those "wanted" twts is finally seen, the mail file gets rewritten to include the appropriate In-Reply-To header.
Patch based on jenny commit 73a5ea81.
https://www.falsifian.org/a/oDtr/patch0.txt
Not implemented:
- Composing twts using the (replyto ...) format.
- Probably other important things I'm forgetting.
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.
2024-09-19T20:20:00+02:00\tI 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! 😅😅😅
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! 😅😅😅
I havent't looked at the code and I'm too lazy right now, does jenny also verify the fetched result against the hash?
url metadata field. So, it's not a new problem, it's exactly the same.
Luckily I can still recognize the voice, so I know it’s him, lol.
Luckily I can still recognize the voice, so I know it’s him, lol.
Luckily I can still recognize the voice, so I know it’s him, lol.
Luckily I can still recognize the voice, so I know it’s him, lol.
(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.
(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.
(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.
(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.
(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’s feeds for example). That’s not too great.Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
(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’s feeds for example). That’s not too great.Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
(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’s feeds for example). That’s not too great.Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
(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’s feeds for example). That’s not too great.Man, I’m completely torn on this. I’d almost prefer not to decide anything. 😂
(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. 🤔
(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. 🤔
(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. 🤔
(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. 🤔
Granted, it's a nice property when one can tell that it was not messed with since the author referenced it.
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.
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? 😳
But I photographed something else instead:
Possibly a large roof panel on a craneMy 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/
Screenshot of Neomutt with twtxts populated by jenny.
Screenshot of Neomutt with twtxts populated by jenny.
.deb to install Headscale, or some other method?
.deb to install Headscale, or some other method?
--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.
--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.
--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.
--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.
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. 🤔
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. 🤔
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. 🤔
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. 🤔