> 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
capitalism does not solve poverty. capitalism creates poverty and then criminalizes it.
https://search.twtxt.net
https://search.twtxt.net
type=rss (e.g: https://feeds.twtxt.net/slashdot/twtxt.txt), just as feeds like @tiktok are marked as type=bot
type=rss (e.g: https://feeds.twtxt.net/slashdot/twtxt.txt), just as feeds like @tiktok are marked as type=bot
My only desire one day is to build a "Feed Builder" of sorts that allows one to say, for example, construct a Slashdot feed but without AI hype, or as another example, a BBC/ABC feed that's a digest once or twice per day.
My only desire one day is to build a "Feed Builder" of sorts that allows one to say, for example, construct a Slashdot feed but without AI hype, or as another example, a BBC/ABC feed that's a digest once or twice per day.
"yarn_pods_for_discovery": ["https://twtxt.net", "https://txt.sour.is"],
"yarn_pods_for_discovery": ["https://twtxt.net", "https://txt.sour.is"],
Original:
Modified:
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
`(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
twtxt.txt in the raw, and the cases above can all be caught with this regex: `\\([\\w-]*reply[\\w-]*\\:` Is this something that would work?
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
`(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
twtxt.txt in the raw, and the cases above can all be caught with this regex: `\\([\\w-]*reply[\\w-]*\\:` Is this something that would work?
Notice the difference? Soren edited, and broke everything.
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)' 2.
`(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' 2. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)' I know it's longer that 7-11 characters, but it's self-explaining when looking at the
twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?
Subject: The [tag URI scheme](https://en.wikipedia.org/wiki/Tag_URI_scheme) looks interesting. I like that it human read- and writable. And since we already got the timestamp in the twtxt.txt it would be
somewhat trivial to parse. But there are still the issue with what the name/id should be... Maybe it doesn't have to bee that stick? Instead of using `tag:` as the prefix/protocol, it would more it clear
what we are talking about by using `in-reply-to:` (https://indieweb.org/in-reply-to) or `replyto:` similar to `mailto:` 1. `(reply:sorenpeter@darch.dk,2024-09-15T12:06:27Z)` 2.
`(in-reply-to:darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` 3. `(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)` I know it's longer that 7-11 characters, but it's self-explaining when looking at the
twtxt.txt in the raw, and the cases above can all be caught with this regex: `\([\w-]*reply[\w-]*\:` Is this something that would work?
Notice the difference? Soren edited, and broke everything.
"sorenpeter (soren)" <sorenpeter>
sorenpeter <sorenpeter>
"sorenpeter (soren)" <sorenpeter>
sorenpeter <sorenpeter>
Message-Id: <hns535a@twtxt>
X-twtxt-feed-url: https://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>
And
Message-Id: <weadxga@twtxt>
X-twtxt-feed-url: http://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>
Two feed URLs, one HTTPS, the other HTTP.
Message-Id: <hns535a@twtxt>
X-twtxt-feed-url: https://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>
And
Message-Id: <weadxga@twtxt>
X-twtxt-feed-url: http://darch.dk/twtxt.txt
In-Reply-To: <pvju5cq@twtxt>
Two feed URLs, one HTTPS, the other HTTP.
I'll set up jenny and mutt on another computer and see how it goes from there.
I'll set up jenny and mutt on another computer and see how it goes from there.
I'll set up jenny and mutt on another computer and see how it goes from there.