# next = <link> and # prev = <link> Metdata in their feed to link to previous/older versions of their feed. I _think_ this is the easier way to implement this that works no matter how you host or the client used.~
# next = <link> and # prev = <link> Metdata in their feed to link to previous/older versions of their feed. I _think_ this is the easier way to implement this that works no matter how you host or the client used.~
next and prev in metadata, IIUC. And that should work pretty well. š¤
next and prev in metadata, IIUC. And that should work pretty well. š¤
next and prev in metadata, IIUC. And that should work pretty well. š¤
prev/next should do. Btw. I find it quite weird that RFC 5005 calls the link relations previous and next for paged but prev-archive and next-archive for archived feeds. Do we want to tie any paging/archiving semantics to that? Also use first and last? Too bad that link is already taken as titled hyperlinks in the metadata. What are your thoughts?
twtxt-2021-10-25.txt: Feed of twts starting at 2021-10-25. For now, this is the ācurrentā feed.\n- twtxt-2021-10-25.txt keeps growing for a while by appending new twts at the end.\n- Once twtxt-2021-10-25.txt is āfullā, we add a next field to its metadata which points to ā¦\n- ā¦ twtxt-2021-11-01.txt, which is initially empty except for a prev field that points back to twtxt-2021-10-25.txt. From this point on, twtxt-2021-11-01.txt is the ācurrentā feed. It keeps growing in the same way. Eventually, itās full and superseded by the next (partial) feed.\n- twtxt.txt could then be a symlink to the ācurrentā feed file.\n- Non-current feeds could now indeed be considered as āarchivedā: Nothing ever changes in them anymore (except for metadata maybe? What if I change my nickname or feed URL?)\n\nWell, at least thatās how Iād go about implementing this in jenny. š
-
twtxt-2021-10-25.txt: Feed of twts starting at 2021-10-25. For now, this is the ācurrentā feed.-
twtxt-2021-10-25.txt keeps growing for a while by appending new twts at the end.- Once
twtxt-2021-10-25.txt is āfullā, we add a next field to its metadata which points to ā¦- ā¦
twtxt-2021-11-01.txt, which is initially empty except for a prev field that points back to twtxt-2021-10-25.txt. From this point on, twtxt-2021-11-01.txt is the ācurrentā feed. It keeps growing in the same way. Eventually, itās full and superseded by the next (partial) feed.-
twtxt.txt could then be a symlink to the ācurrentā feed file.- Non-current feeds could now indeed be considered as āarchivedā: Nothing ever changes in them anymore (except for metadata maybe? What if I change my nickname or feed URL?)
Well, at least thatās how Iād go about implementing this in jenny. š
-
twtxt-2021-10-25.txt: Feed of twts starting at 2021-10-25. For now, this is the ācurrentā feed.-
twtxt-2021-10-25.txt keeps growing for a while by appending new twts at the end.- Once
twtxt-2021-10-25.txt is āfullā, we add a next field to its metadata which points to ā¦- ā¦
twtxt-2021-11-01.txt, which is initially empty except for a prev field that points back to twtxt-2021-10-25.txt. From this point on, twtxt-2021-11-01.txt is the ācurrentā feed. It keeps growing in the same way. Eventually, itās full and superseded by the next (partial) feed.-
twtxt.txt could then be a symlink to the ācurrentā feed file.- Non-current feeds could now indeed be considered as āarchivedā: Nothing ever changes in them anymore (except for metadata maybe? What if I change my nickname or feed URL?)
Well, at least thatās how Iād go about implementing this in jenny. š
-
twtxt-2021-10-25.txt: Feed of twts starting at 2021-10-25. For now, this is the ācurrentā feed.-
twtxt-2021-10-25.txt keeps growing for a while by appending new twts at the end.- Once
twtxt-2021-10-25.txt is āfullā, we add a next field to its metadata which points to ā¦- ā¦
twtxt-2021-11-01.txt, which is initially empty except for a prev field that points back to twtxt-2021-10-25.txt. From this point on, twtxt-2021-11-01.txt is the ācurrentā feed. It keeps growing in the same way. Eventually, itās full and superseded by the next (partial) feed.-
twtxt.txt could then be a symlink to the ācurrentā feed file.- Non-current feeds could now indeed be considered as āarchivedā: Nothing ever changes in them anymore (except for metadata maybe? What if I change my nickname or feed URL?)
Well, at least thatās how Iād go about implementing this in jenny. š
I would recommend a longer rotation, perhaps? The way I see it, you are proposing a monthly one. That can make metadata huge too. Maybe yearly, or every 6 months?
yarnd will to as in practice this turns out to be a "good" value and approximately a year of Twts for socially active persons š~
yarnd will to as in practice this turns out to be a "good" value and approximately a year of Twts for socially active persons š~
$n months or $m twts, whichever comes firstā, both variables being customizable. I mean, thereās no point in āpaginatingā a feed if thereās very little traffic.
$n months or $m twts, whichever comes firstā, both variables being customizable. I mean, thereās no point in āpaginatingā a feed if thereās very little traffic.
$n months or $m twts, whichever comes firstā, both variables being customizable. I mean, thereās no point in āpaginatingā a feed if thereās very little traffic.
> changing the URL causes twt hashes to break again. The never ending story.
It's actually not really as big of a problem as we've made it out to be in past conversations. If enough clients have seen versions of the feed then they'll have old copies of the Twts with the previous Hash and thus there will still be a valid chain. What changing the URL or the content of a individual Twt really does is fork the chain. Which isn't so bad IHMO. Just something to be aware of I guess? š¤
> changing the URL causes twt hashes to break again. The never ending story.
It's actually not really as big of a problem as we've made it out to be in past conversations. If enough clients have seen versions of the feed then they'll have old copies of the Twts with the previous Hash and thus there will still be a valid chain. What changing the URL or the content of a individual Twt really does is fork the chain. Which isn't so bad IHMO. Just something to be aware of I guess? š¤
twtxt client for example just caches a copy of the current feed, so on next update cycle it just replaces everything it had for this feed with the current contents. I'd imagine that's a common model.
yarndās cache originally came from twet in the early days and morphed over time to what it is now.Gbe Twt Hash extension had the most influence.
I donāt think just sucking down the feed and storing the file is the most efficient nor useful thing to do given how weāve extended the spec.
yarndās cache originally came from twet in the early days and morphed over time to what it is now.\n\nGbe Twt Hash extension had the most influence.\n\nI donāt think just sucking down the feed and storing the file is the most efficient nor useful thing to do given how weāve extended the spec.
yarndās cache originally came from twet in the early days and morphed over time to what it is now.Gbe Twt Hash extension had the most influence.
I donāt think just sucking down the feed and storing the file is the most efficient nor useful thing to do given how weāve extended the spec.