And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂
And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂
And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂
And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂
And I guess the release after that is going to include all the threading/hashing stuff – if we can decide on one of the proposals. 😂
\\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\\\n2020-07-18T12:39:52Z\\\\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\n2020-07-18T12:39:52Z\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\n2020-07-18T12:39:52Z\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\n2020-07-18T12:39:52Z\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! 😊" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
2024-09-18T23:08:00+10:00 Hllo World
2024-09-18T23:10:43+10:00 (edit:#229d24612a2) Hello World
2024-09-18T23:08:00+10:00\tHllo World
2024-09-18T23:10:43+10:00\t(edit:#229d24612a2) Hello World
2024-09-18T23:08:00+10:00 Hllo World
2024-09-18T23:10:43+10:00 (edit:#229d24612a2) Hello World
2024-09-18T23:08:00+10:00 Hllo World
2024-09-18T23:10:43+10:00 (edit:#229d24612a2) Hello World
It works for us because there are enough people around and there’s a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week you’re the poor bastard who is legally required to fix shit. That’s just horrible, I don’t want that. 😅
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. 😂
It works for us because there are enough people around and there’s a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week you’re the poor bastard who is legally required to fix shit. That’s just horrible, I don’t want that. 😅
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. 😂
It works for us because there are enough people around and there’s a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week you’re the poor bastard who is legally required to fix shit. That’s just horrible, I don’t want that. 😅
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. 😂
It works for us because there are enough people around and there’s a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week you’re the poor bastard who is legally required to fix shit. That’s just horrible, I don’t want that. 😅
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. 😂
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
And, well, I also need that thing for 2FA. 😅
And, well, I also need that thing for 2FA. 😅
And, well, I also need that thing for 2FA. 😅
And, well, I also need that thing for 2FA. 😅
Mangled in what way? How does it look like? 🤔
Mangled in what way? How does it look like? 🤔
Mangled in what way? How does it look like? 🤔
Mangled in what way? How does it look like? 🤔
> i hope we don't go chasing mass-appeal
I don’t think this is going to happen any time soon.
What makes twtxt unique is its radical *technical* simplicity. And that means you have to be a *tech-savvy* person to appreciate twtxt and *that* means mass-appeal is pretty much out of the question to begin with. 😅
Yarn adds a lot of user-friendliness and, in a way, does try to appeal to the masses. And it almost worked. When Twitter died, we saw a substantial influx of new users, didn’t we? Only problem is, Mastodon had a massive headstart. The Fediverse was already huge, so what did Yarn/twtxt have to offer? It is *way simpler* and *way easier to self-host*, but who cares about that? Right, the tech-savvy people, not the masses. Many of the tech-savvy people were already using Mastodon, though, and, frankly, “simplicity” is not something that a lot of folks even care about. Thus Yarn/twtxt never took off.
> i hope we don't go chasing mass-appeal
I don’t think this is going to happen any time soon.
What makes twtxt unique is its radical *technical* simplicity. And that means you have to be a *tech-savvy* person to appreciate twtxt and *that* means mass-appeal is pretty much out of the question to begin with. 😅
Yarn adds a lot of user-friendliness and, in a way, does try to appeal to the masses. And it almost worked. When Twitter died, we saw a substantial influx of new users, didn’t we? Only problem is, Mastodon had a massive headstart. The Fediverse was already huge, so what did Yarn/twtxt have to offer? It is *way simpler* and *way easier to self-host*, but who cares about that? Right, the tech-savvy people, not the masses. Many of the tech-savvy people were already using Mastodon, though, and, frankly, “simplicity” is not something that a lot of folks even care about. Thus Yarn/twtxt never took off.
> i hope we don't go chasing mass-appeal
I don’t think this is going to happen any time soon.
What makes twtxt unique is its radical *technical* simplicity. And that means you have to be a *tech-savvy* person to appreciate twtxt and *that* means mass-appeal is pretty much out of the question to begin with. 😅
Yarn adds a lot of user-friendliness and, in a way, does try to appeal to the masses. And it almost worked. When Twitter died, we saw a substantial influx of new users, didn’t we? Only problem is, Mastodon had a massive headstart. The Fediverse was already huge, so what did Yarn/twtxt have to offer? It is *way simpler* and *way easier to self-host*, but who cares about that? Right, the tech-savvy people, not the masses. Many of the tech-savvy people were already using Mastodon, though, and, frankly, “simplicity” is not something that a lot of folks even care about. Thus Yarn/twtxt never took off.
> i hope we don't go chasing mass-appeal
I don’t think this is going to happen any time soon.
What makes twtxt unique is its radical *technical* simplicity. And that means you have to be a *tech-savvy* person to appreciate twtxt and *that* means mass-appeal is pretty much out of the question to begin with. 😅
Yarn adds a lot of user-friendliness and, in a way, does try to appeal to the masses. And it almost worked. When Twitter died, we saw a substantial influx of new users, didn’t we? Only problem is, Mastodon had a massive headstart. The Fediverse was already huge, so what did Yarn/twtxt have to offer? It is *way simpler* and *way easier to self-host*, but who cares about that? Right, the tech-savvy people, not the masses. Many of the tech-savvy people were already using Mastodon, though, and, frankly, “simplicity” is not something that a lot of folks even care about. Thus Yarn/twtxt never took off.
$ 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? 🤔
(#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.
~/.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? 🤔
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? 🤔
> 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.
>
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. 🤔
--fetch-context doesn’t go back into archived feeds … 🤦
--fetch-context doesn’t go back into archived feeds … 🤦