Searching We.Love.Privacy.Club

Twts matching #Twt
Sort by: Newest, Oldest, Most Relevant
stackeffect
twtxt.stackeffect.de
 (4y ago)
↳ In-reply-to » @movq Another feature request: sometimes I start writing a twt but then would like to discard it. It would be great if jeny could detect that I did not wrote (or saved) anything and then discards the twt instead of creating an "empty" one.

@movq@www.uninformativ.de I don’t by your example (rebasing behaviour), sorry.

Writing a twt is more similiar to writing a commit message. Git does quite some checks to detect that nothing new was written and happily discards a commit if you just leave the editor. You don’t need any special action, just quit your editor. Git will take care for the rest.

But it’s OK as it is. I just didn’t expect that I have to select and delete all to discard a twt. So it’s C-x h C-w C-x C-c for me.

⤋ Read More
stackeffect
twtxt.stackeffect.de
 (4y ago)
↳ In-reply-to » @movq Today I had unexpected old twts after jenny -f. Have now jennys cache under revision control, automatically commiting changes after each fetch. Let's see if this helps finding a (possible) bug.

@movq@www.uninformativ.de Your scenario would produce observed behaviour, agreed. On the other side I’m sure I’ve set very URL in lasttwt > 1630000000.0 (manually, in my editor).

But I can’t reproduce any weird behaviour right now. I’ve tried to “blackhole” twt.nfld.uk temporarily. That does not have any effect.

I’ve also tried to force twt.nfld.uk to deliver an empty twtxt. That does not have any effect either.

So I guess everything is fine with jenny.

I have wrapped jenny into some shell script to versionize ~/.cache/jenney. This way I have better data if anything unexprected is showing again.

⤋ Read More
stackeffect
twtxt.stackeffect.de
 (4y ago)
↳ In-reply-to » @movq Today I had unexpected old twts after jenny -f. Have now jennys cache under revision control, automatically commiting changes after each fetch. Let's see if this helps finding a (possible) bug.

@movq@www.uninformativ.de Yes, it was exactly those twts. I don’t think I’ve managed to “match” the downtime while fetching twts. But even if I had, how can this lead to inserting old twts?

⤋ Read More
stackeffect
twtxt.stackeffect.de
 (4y ago)

@movq@www.uninformativ.de What do you think about this?

diff –git a/jenny b/jenny
index b47c78e..20cf659 100755
— a/jenny
+++ b/jenny
@@ -278,7 +278,8 @@ def prefill_for(email, reply_to_this, self_mentions):
def process_feed(config, nick, url, content, lasttwt):

 nick_address, nick_desc = decide_nick(content, nick)
 url_for_hash = decide_url_for_hash(content, url)

  • new_lasttwt = parse(‘1800-01-01T12:00:00+00:00’).timestamp()

  • # new_lasttwt = parse(‘1800-01-01T12:00:00+00:00’).timestamp()

  • new_lasttwt = None

    for line in twt_lines_from_content(content):

     res = twt_line_to_mail(

    @@ -296,7 +297,7 @@ def process_feed(config, nick, url, content, lasttwt):

     twt_stamp = twt_date.timestamp()
 if lasttwt is not None and lasttwt >= twt_stamp:
     continue

  • if twt_stamp > new_lasttwt:

  • if not new_lasttwt or twt_stamp > new_lasttwt:

         new_lasttwt = twt_stamp


 mailname_new = join(config['maildir_target'], 'new', twt_hash)

⤋ Read More
stackeffect
twtxt.stackeffect.de
 (4y ago)
↳ In-reply-to » My thoughts about range requests

@movq@www.uninformativ.de

Don’t miss step 0 (I should have made this a separate point): having a meta header promising appending twts with strictly monotonically increasing timestamps.

(Also, I’d first like to see the pagination thingy implemented.)

In jenny I would like to see “don’t process previously fetched twts” AKA “Allow the user to archive/delete old twts” feature implemented ;-)

⤋ Read More
stackeffect
twtxt.stackeffect.de
 (4y ago)

My thoughts about range requests

Additionally to pagination also range request should be used to reduce traffic.

I understand that there are corner cases making this a complicated matter.

I would like to see a meta header saying that the given twtxt is append only with increasing timestamps so that a simple strategy can detect valid content fetched per range request.

  1. read meta part per range request
  2. read last fetched twt at expected range (as known from last fetch)
  3. if fetched content starts with expected twt then process rest of data
  4. if fetched content doesn’t start with expected twt discard all and fall back to fetching whole twtxt

Pagination (e.g. archiving old content in a different file) will lead to point 4.

Of course especially pods should support range requests, correct @prologic@twtxt.net?

⤋ Read More
stackeffect
twtxt.stackeffect.de
 (4y ago)

My thoughts about pagination (paging)

Following the discussion about pagination (paging) I think that’s the right thing to do.

Fetching the same content again and again with only a marginal portion of actually new twts is unbearable and does not scale in any way. It’s not only a waste of bandwidth but with increasing number of fetchers it will also become a problem for pods to serve all requests.

Because it’s so easy to implement and simple to understand, splitting twtxt file in parts with next and prev pointers seems a really amazing solution.

As in RFC5005 there should also be a meta header pointing to the main URL, e.g. current or baseurl or something like that. This way hashes can calculated correctly even for archived twts.

⤋ Read More