jenny:
From: quark <quark>
Subject: (#o) @prologic this was your first twtxt. Cool! :-P
Date: Mon, 16 Sep 2024 12:42:27 -0400
Message-Id: <k7imvia@twtxt>
X-twtxt-feed-url: https://ferengi.one/twtxt.txt
(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
jenny:
From: quark <quark>
Subject: (#o) @prologic this was your first twtxt. Cool! :-P
Date: Mon, 16 Sep 2024 12:42:27 -0400
Message-Id: <k7imvia@twtxt>
X-twtxt-feed-url: https://ferengi.one/twtxt.txt
(#o) @<prologic https://twtxt.net/user/prologic/twtxt.txt> this was your first twtxt. Cool! :-P
From: prologic <prologic>
Subject: Hello World! 😊
Date: Sat, 18 Jul 2020 08:39:52 -0400
Message-Id: <o6dsrga>
X-twtxt-feed-url: https://twtxt.net/user/prologic/twtxt.txt
Hello World! 😊
And see how the hash shows... Is it because that hash isn't longer used?
From: prologic <prologic>
Subject: Hello World! 😊
Date: Sat, 18 Jul 2020 08:39:52 -0400
Message-Id: <o6dsrga>
X-twtxt-feed-url: https://twtxt.net/user/prologic/twtxt.txt
Hello World! 😊
And see how the hash shows... Is it because that hash isn't longer used?
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
Jenny has to look for the metadata fields, it must find the
# prev = ... line. To do so, I naively wrote something along these lines:
for line in content.splitlines():
if line.startswith('# prev = '):
...
Problem is, we use \\u2028 a lot in twtxt feeds and Python interprets those as line separators as well. That’s not what we want here. Jenny must only split at a
\\n.Now @prologic had a quote/copy of some of his metadata fields in a twt. Like so:
# prev = foo bar
Perfectly legitimate, but now jenny found the
# prev = *twice* (once in the actual header, once in a twt), didn’t know what to do, and thus did not fetch the archived feeds. 🤦Should be fixed in this commit: https://www.uninformativ.de/git/jenny/commit/6e8ce5afdabd5eac22eae4275407b3bd2a167daf.html
But yes, this has a nice discoverability bonus. And even simpler than a hash, that's right.
~/.cache/jenny and my maildir_target when I tried to reset things. Still got wrecked 😅 If it's not too much to ask, could you backup or/change your
maildir_target and give it a try with an empty directory?
~/.cache/jenny and my maildir_target when I tried to reset things. Still got wrecked 😅 If it's not too much to ask, could you backup or/change your
maildir_target and give it a try with an empty directory?
~/.cache/jenny and my maildir_target when I tried to reset things. Still got wrecked 😅 If it's not too much to ask, could you backup or/change your
maildir_target and give it a try with an empty directory?
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
PS: I still can't get your and bender's archived twts (at least the ones I've noticed), nor can I
--fetch-context on replays to them. your oldest is the one from 2024-06-14 18:22 ... I can see lyse's tho! but I doubt this is related the edit issue but this helps with something.
PS: I still can't get your and bender's archived twts (at least the ones I've noticed), nor can I
--fetch-context on replays to them. your oldest is the one from 2024-06-14 18:22 ... I can see lyse's tho! but I doubt this is related the edit issue but this helps with something.
PS: I still can't get your and bender's archived twts (at least the ones I've noticed), nor can I
--fetch-context on replays to them. your oldest is the one from 2024-06-14 18:22 ... I can see lyse's tho! but I doubt this is related the edit issue but this helps with something.
- It all started with a LOT of his old twts starting back in 2020 showing in a weird way, some were empty others were duplicates and a lot more got marked for deletion by neomutt with the
D tag. - After trying to restart things with a fresh Maildir, I couldn't fetch a lot of twts, even mine which was a replay to one of his. but then I was able to after temporarily deleting his link from my follow file.
then @quark and @bender pointed out the inconsistent from: + feed url and the twt edit
- It all started with a LOT of his old twts starting back in 2020 showing in a weird way, some were empty others were duplicates and a lot more got marked for deletion by neomutt with the
D tag. - After trying to restart things with a fresh Maildir, I couldn't fetch a lot of twts, even mine which was a replay to one of his. but then I was able to after temporarily deleting his link from my follow file.
then @quark and @bender pointed out the inconsistent from: + feed url and the twt edit
- It all started with a LOT of his old twts starting back in 2020 showing in a weird way, some were empty others were duplicates and a lot more got marked for deletion by neomutt with the
D tag. - After trying to restart things with a fresh Maildir, I couldn't fetch a lot of twts, even mine which was a replay to one of his. but then I was able to after temporarily deleting his link from my follow file.
then @quark and @bender pointed out the inconsistent from: + feed url and the twt edit
(r:https://...). 😅
(r:https://...). 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> The second value of prev is a name relative to the base directory of the feed’s URL in url (more specifically, in the URL that the client used to retrieve the feed). In the example above, prev would evaluate to the full URL https://example.com/twtxt-2021-10-18.txt for HTTPS and gopher://example.com/0/twtxt-2021-10-18.txt for Gopher.
> The second value of prev is a name relative to the base directory of the feed’s URL in url (more specifically, in the URL that the client used to retrieve the feed). In the example above, prev would evaluate to the full URL https://example.com/twtxt-2021-10-18.txt for HTTPS and gopher://example.com/0/twtxt-2021-10-18.txt for Gopher.
prev = hash twtxt.txt/n instead of a link by design? I couldn't fetch any, nor can I do a --fetch-context on replays to your old twts.
prev = hash twtxt.txt/n instead of a link by design? I couldn't fetch any, nor can I do a --fetch-context on replays to your old twts.
prev = hash twtxt.txt/n instead of a link by design? I couldn't fetch any, nor can I do a --fetch-context on replays to your old twts.
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
> No keyboards were harmed during this experiment... yet.
> No keyboards were harmed during this experiment... yet.
> No keyboards were harmed during this experiment... yet.
#catsoftwtxt
/https://duque-terron.cat/media/photos/IMG_2015.jpeg) #catsoftwtxt
#catsoftwtxt
#catsoftwtxt
/https://duque-terron.cat/media/photos/IMG_2013.jpeg) #catsoftwtxt
#catsoftwtxt