-n 🫠
> Or maybe url changes could somehow be combined with the archive feeds extension? Could the url metadata field be local to each archive file, so that to switch to a new url all you need to do is archive everything you’ve got and start a new file at the new url?
👌
> Or maybe url changes could somehow be combined with the archive feeds extension? Could the url metadata field be local to each archive file, so that to switch to a new url all you need to do is archive everything you’ve got and start a new file at the new url?
👌
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
[o6dsrga] [2020-07-18 12:39:52+00:00] [Hello World! 😊]
Does *that* work for you? 🤔
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
[o6dsrga] [2020-07-18 12:39:52+00:00] [Hello World! 😊]
Does *that* work for you? 🤔
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
[o6dsrga] [2020-07-18 12:39:52+00:00] [Hello World! 😊]
Does *that* work for you? 🤔
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
\n \n \n
Does *that* work for you? 🤔
$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/6 | head
[o6dsrga] [2020-07-18 12:39:52+00:00] [Hello World! 😊]
Does *that* work for you? 🤔
> I don't really have a problem with editing twts, or someone changing their feed's URL.
Personally I think the folks that do are rightfully pedantic and like a good user experience, which I don't blame 'em. I would expect the same too. Anyway, just wanted to get that out there, I believe we can support editing and identity in a way that is still simple, as long as we bring clients along for the ride with us. The old/legacy original client though will have to remain well, ya know 😅
> I don't really have a problem with editing twts, or someone changing their feed's URL.
Personally I think the folks that do are rightfully pedantic and like a good user experience, which I don't blame 'em. I would expect the same too. Anyway, just wanted to get that out there, I believe we can support editing and identity in a way that is still simple, as long as we bring clients along for the ride with us. The old/legacy original client though will have to remain well, ya know 😅
> (#w4chkna) @falsifian You mean the idea of being able to inline
# url = changes in your feed?Yes, that one. But @lyse pointed out suffers a compatibility issue, since currently the first listed url is used for hashing, not the last. Unless your feed is in reverse chronological order. Heh, I guess another metadata field could indicate which version to use.
Or maybe url changes could somehow be combined with the archive feeds extension? Could the url metadata field be local to each archive file, so that to switch to a new url all you need to do is archive everything you've got and start a new file at the new url?
I don't think it's that likely my feed url will change.
(#hash;#originalHash) would also work.Maybe I’m being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic – or maybe I didn’t even send that twt, I don’t remember 😅), I never really liked hashes to begin with. They aren’t super hard to implement but they are kind of against the beauty of the original twtxt – because you *need* special client support for them. It’s not something that you could write manually in your
twtxt.txt file. With @sorenpeter’s proposal, though, that would be possible.I don’t know … maybe it’s just me. 🥴
I’m also being a bit selfish, to be honest: Implementing
(#hash;#originalHash) in jenny *for editing your own feed* would not be a no-brainer. (Editing is already kind of unsupported, actually.) It wouldn’t be a problem to implement it for fetching other people’s feeds, though.
(#hash;#originalHash) would also work.Maybe I’m being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic – or maybe I didn’t even send that twt, I don’t remember 😅), I never really liked hashes to begin with. They aren’t super hard to implement but they are kind of against the beauty of the original twtxt – because you *need* special client support for them. It’s not something that you could write manually in your
twtxt.txt file. With @sorenpeter’s proposal, though, that would be possible.I don’t know … maybe it’s just me. 🥴
I’m also being a bit selfish, to be honest: Implementing
(#hash;#originalHash) in jenny *for editing your own feed* would not be a no-brainer. (Editing is already kind of unsupported, actually.) It wouldn’t be a problem to implement it for fetching other people’s feeds, though.
(#hash;#originalHash) would also work.Maybe I’m being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic – or maybe I didn’t even send that twt, I don’t remember 😅), I never really liked hashes to begin with. They aren’t super hard to implement but they are kind of against the beauty of the original twtxt – because you *need* special client support for them. It’s not something that you could write manually in your
twtxt.txt file. With @sorenpeter’s proposal, though, that would be possible.I don’t know … maybe it’s just me. 🥴
I’m also being a bit selfish, to be honest: Implementing
(#hash;#originalHash) in jenny *for editing your own feed* would not be a no-brainer. (Editing is already kind of unsupported, actually.) It wouldn’t be a problem to implement it for fetching other people’s feeds, though.
(#hash;#originalHash) would also work.Maybe I’m being a bit too purist/minimalistic here. As I said before (in one of the 1372739 posts on this topic – or maybe I didn’t even send that twt, I don’t remember 😅), I never really liked hashes to begin with. They aren’t super hard to implement but they are kind of against the beauty of the original twtxt – because you *need* special client support for them. It’s not something that you could write manually in your
twtxt.txt file. With @sorenpeter’s proposal, though, that would be possible.I don’t know … maybe it’s just me. 🥴
I’m also being a bit selfish, to be honest: Implementing
(#hash;#originalHash) in jenny *for editing your own feed* would not be a no-brainer. (Editing is already kind of unsupported, actually.) It wouldn’t be a problem to implement it for fetching other people’s feeds, though.
A feed URL is plenty good enough for me. Since I only fetch feeds that I explicity follow, there is some basic trust in those feeds already. Spoofing, impersonation and what not are no issues for me. If I were to find out otherwise, I just unsubscribe from the evil feed. Done.
To retrieve public feeds, I just rely on TLS. Most are served via HTTPS. If a feed is down, I'm not trying to fetch it from some other source, I just wait and try again later. So signed messages/feeds are not a use case I'm particularly benefitting from.
To me, it's just not worth at all adding this crypto complexity on top.
h
twtxt2html $HOME/path/to/local_twtxt_dir/twtxt.txt > $HOME/path/to/local_twtxt_dir/log.html && \
scp $HOME/path/to/local_twtxt_dir/log.html user@remotehost:/path/to/static_files_dir/
I've been lazy to add it to my publish_command script, now I can just copy/pasta from the twt 😅
h
twtxt2html $HOME/path/to/local_twtxt_dir/twtxt.txt > $HOME/path/to/local_twtxt_dir/log.html && \\
scp $HOME/path/to/local_twtxt_dir/log.html user@remotehost:/path/to/static_files_dir/
I've been lazy to add it to my publish_command script, now I can just copy/pasta from the twt 😅
h
twtxt2html $HOME/path/to/local_twtxt_dir/twtxt.txt > $HOME/path/to/local_twtxt_dir/log.html && \
scp $HOME/path/to/local_twtxt_dir/log.html user@remotehost:/path/to/static_files_dir/
I've been lazy to add it to my publish_command script, now I can just copy/pasta from the twt 😅
jenny fetches archives, yes, but that twtxt I am referring about is no longer. If you fetch it, but I don't, there is certainly something going on...
jenny fetches archives, yes, but that twtxt I am referring about is no longer. If you fetch it, but I don't, there is certainly something going on...
<timestamp> (#hash;#originalHash) <content> For example._
<timestamp> (#hash;#originalHash) <content> For example._
~/.cache/jenny and ~/Mail/twt/cur, and a subsequent jenny -f properly fetches everything.Do you see all the “Fetching archived feed …” messages?
~/.cache/jenny and ~/Mail/twt/cur, and a subsequent jenny -f properly fetches everything.Do you see all the “Fetching archived feed …” messages?
~/.cache/jenny and ~/Mail/twt/cur, and a subsequent jenny -f properly fetches everything.Do you see all the “Fetching archived feed …” messages?
~/.cache/jenny and ~/Mail/twt/cur, and a subsequent jenny -f properly fetches everything.Do you see all the “Fetching archived feed …” messages?
> Your propose scheme while simple doesn't do this.
It doesn’t do that because it’s not taking the content of a twt into account (only its timestamp). Okay. But the mere fact that we’re talking about “how to solve the edit problem” stems from using content addressing – so maybe content addressing isn’t the best thing to use here? 🤔
> Your propose scheme while simple doesn't do this.
It doesn’t do that because it’s not taking the content of a twt into account (only its timestamp). Okay. But the mere fact that we’re talking about “how to solve the edit problem” stems from using content addressing – so maybe content addressing isn’t the best thing to use here? 🤔
> Your propose scheme while simple doesn't do this.
It doesn’t do that because it’s not taking the content of a twt into account (only its timestamp). Okay. But the mere fact that we’re talking about “how to solve the edit problem” stems from using content addressing – so maybe content addressing isn’t the best thing to use here? 🤔
> Your propose scheme while simple doesn't do this.
It doesn’t do that because it’s not taking the content of a twt into account (only its timestamp). Okay. But the mere fact that we’re talking about “how to solve the edit problem” stems from using content addressing – so maybe content addressing isn’t the best thing to use here? 🤔
El chocolate no engorda, engordas tú. ⌘ Read more****
It’s a cool idea and it’s cool technology. It would (probably) even be fun to implement.
But do we need it? Or rather, does twtxt need it? What problem are you trying to solve – are people migrating their feeds to new URLs all the time? 🤔 That’s rather rare in my experience. The URL as the primary identifier of a feed works fine for me.
Maybe I just don’t understand the problem well enough yet? 🤔
It’s a cool idea and it’s cool technology. It would (probably) even be fun to implement.
But do we need it? Or rather, does twtxt need it? What problem are you trying to solve – are people migrating their feeds to new URLs all the time? 🤔 That’s rather rare in my experience. The URL as the primary identifier of a feed works fine for me.
Maybe I just don’t understand the problem well enough yet? 🤔
It’s a cool idea and it’s cool technology. It would (probably) even be fun to implement.
But do we need it? Or rather, does twtxt need it? What problem are you trying to solve – are people migrating their feeds to new URLs all the time? 🤔 That’s rather rare in my experience. The URL as the primary identifier of a feed works fine for me.
Maybe I just don’t understand the problem well enough yet? 🤔
It’s a cool idea and it’s cool technology. It would (probably) even be fun to implement.
But do we need it? Or rather, does twtxt need it? What problem are you trying to solve – are people migrating their feeds to new URLs all the time? 🤔 That’s rather rare in my experience. The URL as the primary identifier of a feed works fine for me.
Maybe I just don’t understand the problem well enough yet? 🤔
commit 6e8ce5afdabd5eac22eae4275407b3bd2a167daf (HEAD -> main, origin/main, origin/HEAD), I keep myself up-to-date, LOL. Still, that specific twtxt (o6dsrga) is no longer.
commit 6e8ce5afdabd5eac22eae4275407b3bd2a167daf (HEAD -> main, origin/main, origin/HEAD), I keep myself up-to-date, LOL. Still, that specific twtxt (o6dsrga) is no longer.
> jenny does fetch archived feeds during the normal
jenny -f operation […]… *but* you need to use the current Git version which includes this commit:
https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
There was a bug that broke on @prologic’s feed. 🥴
> jenny does fetch archived feeds during the normal
jenny -f operation […]… *but* you need to use the current Git version which includes this commit:
https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
There was a bug that broke on @prologic’s feed. 🥴
> jenny does fetch archived feeds during the normal
jenny -f operation […]… *but* you need to use the current Git version which includes this commit:
https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
There was a bug that broke on @prologic’s feed. 🥴
> jenny does fetch archived feeds during the normal
jenny -f operation \n… *but* you need to use the current Git version which includes this commit:
https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
There was a bug that broke on @prologic’s feed. 🥴
> jenny does fetch archived feeds during the normal
jenny -f operation […]… *but* you need to use the current Git version which includes this commit:
https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
There was a bug that broke on @prologic’s feed. 🥴
> Since
jenny can't fetch archived twtxtsI wiped my entire maildir and re-fetched everything. I did that recently because @aelaraji asked me to 😅, but I guess I also did this back in 2023.
> What did you do to make yours work?
jenny does fetch archived feeds during the normal
jenny -f operation. Only when using the recently implemented --fetch-context, archived feeds are not fetched (yet). That was an oversight and I intend to fix that.
> Since
jenny can't fetch archived twtxtsI wiped my entire maildir and re-fetched everything. I did that recently because @aelaraji asked me to 😅, but I guess I also did this back in 2023.
> What did you do to make yours work?
jenny does fetch archived feeds during the normal
jenny -f operation. Only when using the recently implemented --fetch-context, archived feeds are not fetched (yet). That was an oversight and I intend to fix that.
> Since
jenny can't fetch archived twtxtsI wiped my entire maildir and re-fetched everything. I did that recently because @aelaraji asked me to 😅, but I guess I also did this back in 2023.
> What did you do to make yours work?
jenny does fetch archived feeds during the normal
jenny -f operation. Only when using the recently implemented --fetch-context, archived feeds are not fetched (yet). That was an oversight and I intend to fix that.
> Since
jenny can't fetch archived twtxtsI wiped my entire maildir and re-fetched everything. I did that recently because @aelaraji asked me to 😅, but I guess I also did this back in 2023.
> What did you do to make yours work?
jenny does fetch archived feeds during the normal
jenny -f operation. Only when using the recently implemented --fetch-context, archived feeds are not fetched (yet). That was an oversight and I intend to fix that.
jenny to convert twtxt.txt to HTML using @prologic's code?
oh man, this was great! little to no humidity and 63F outside with hills. felt stupid easy which i think being able to breathe easily really was the main reason.
#running
oh man, this was great! little to no humidity and 63F outside with hills. felt stupid easy which i think being able to breathe easily really was the main reason.
#running
oh man, this was great! little to no humidity and 63F outside with hills. felt stupid easy which i think being able to breathe easily really was the main reason.
#running
n7gavoa.
n7gavoa.
o6dsrga, but I can't find the source for it (the raw file). I reset everything, and re-fetched fresh feeds (allegedly including archives). Where is it?
o6dsrga, but I can't find the source for it (the raw file). I reset everything, and re-fetched fresh feeds (allegedly including archives). Where is it?
twtxt.txt I see this line:
2024-09-16T17:37:14+00:00\t(#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>
@<quark https://ferengi.one/twtxt.txt> This is what I get. 🤔
Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (
Message-Id: <o6dsrga>), looks like this:
2024-09-16T16:42:27+00:00\t(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
What did you do to make yours work? I simply went to the oldest @prologic's entry on my Maildir, and replied to it (
jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny can't fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?
twtxt.txt I see this line:
2024-09-16T17:37:14+00:00 (#o6dsrga) @<prologic https://twtxt.net/user/prologic/twtxt.txt>
@<quark https://ferengi.one/twtxt.txt> This is what I get. 🤔
Which is using the right hash. Mine, on the other hand, when I replied to the original, old style message (
Message-Id: <o6dsrga>), looks like this:
2024-09-16T16:42:27+00:00 (#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
What did you do to make yours work? I simply went to the oldest @prologic's entry on my Maildir, and replied to it (
jenny set the reply-to hash to #o, even though the Message-Id is o6dsrga). Since jenny can't fetch archived twtxts, how could I go to re-fetch everything? And, most importantly, would re-fetching fix the Message-Id:?
¿Quien dijo que con las dietas se come menos? ⌘ Read more****
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
>
Message-Id: <o6dsrga>That’s an older format that was used before jenny version v23.04. It should look like this nowadays:
>
Message-Id: <o6dsrga@twtxt>Changelog entry from back then:
v23.04 2023-04-19
[Changed]
- The format of the "Message-Id" and "In-Reply-To" headers has
changed. They now need an "@twtxt" suffix to be more compliant with
RFC(2)822. This fixes issues when using aerc
(https://aerc-mail.org/) as a frontend instead of mutt.
If you want to retain compatibility with existing files in your
maildir, you must manually add this suffix to these headers. (Or go
ahead and re-sync everything.)
I guess I could have added backwards compatibility to the code. Maybe I’ll fix that later. 🤔
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions:(#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person.
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!
@<movq https://www.uninformativ.de/twtxt.txt> ) is also long, but we live with it anyway. In a way a replyto: is just a mention of a twt instead of a feed/person. Maybe we chould even model the syntax for replies on mentions: (#<2024-09-17T08:39:18Z https://www.eksempel.dk/twtxt.txt>) ?!