Searching We Love Privacy Club

Twts matching #meta
Sort by: Newest, Oldest, Most Relevant
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

I think it is long due dropping Facebook (now Meta) from the S&P 500 index funds. As an owner of some, I really have a problem with it—and yes, I know there is little I can do but voice it everywhere I make noise online.

​ Read More

What about a meta header for setting charset?

I myself stumbled upon .txt files not being delivered with charset: utf-8 by default.

I had to set/modify .htaccess to correct that.

It would have been easier if there had been a charset header entry “overwriting” what http server is delivering.

What do you think?

​ Read More

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

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

weewiki uses a custom org markup parser written in ANSI C to render the HTML. No emacs needed! my hope is to introduce a user-defined callback that can process these to allow for custom meta-commands.

​ Read More

Scaling Dunbar’s number up to billions of people is hard even with augments, so you can lend your voice to an Übermensch: A meta-person that represents you and thousands of others, which talks to other Übermenschen to get person-years of communication done in mere minutes

​ Read More