Searching We.Love.Privacy.Club

Twts matching #cache
Sort by: Newest, Oldest, Most Relevant
lyse
lyse.isobeef.org
 (37w ago)
↳ In-reply-to » @lyse Thanks, I think I fixed it now. Sorry for the spam.

@itsericwoodward@itsericwoodward.com No worries, all good, mate! We all have to start somewhere. Other software requests my feed several orders of magnitude more often.

I can confirm, the User-Agent header appears to be fixed. \o/

Two other things I noticed, though:

  1. There’s now an OPTIONS request for my feed coming from something that claims to be Firefox, pointing to your feed URL in the query. No clue what this is about. In any case, it’s rejected with a 405 Method Not Allowed.

  2. Not that these few requests bother me at all, but you might wanna implement caching next with either the If-Modified-Since or If-None-Match request headers. This way, if the feed hasn’t changed, the web server can reply with a 304 Not Modified and no body at all, saving unnecessary traffic. But again, this is really not an issue for me at all. I just wanted to make sure you’re aware of it, that’s all. It might be even already on your agenda. Or you might decide to never do anything about it, which is also fine for me. :-)

⤋ Read More
itsericwoodward
itsericwoodward.com
 (37w ago)

I finally solved the loading issue in my WIP reader, TwtStrm (and apologies again to anyone that got spammed while I was diagnosing the issue).

After another round of coding this weekend, I’m happy to report that it now renders all the twts (with markdown parsing), complete with localstorage and server-based file caching.

⤋ Read More
lyse
lyse.isobeef.org
 (38w ago)
↳ In-reply-to » (#altkl2a) Here is just a small list of things™ that I'm aware will break, some quite badly, others in minor ways:

@prologic@twtxt.net I know we won’t ever convince each other of the other’s favorite addressing scheme. :-D But I wanna address (haha) your concerns:

  1. I don’t see any difference between the two schemes regarding link rot and migration. If the URL changes, both approaches are equally terrible as the feed URL is part of the hashed value and reference of some sort in the location-based scheme. It doesn’t matter.

  2. The same is true for duplication and forks. Even today, the “cannonical URL” has to be chosen to build the hash. That’s exactly the same with location-based addressing. Why would a mirror only duplicate stuff with location- but not content-based addressing? I really fail to see that. Also, who is using mirrors or relays anyway? I don’t know of any such software to be honest.

  3. If there is a spam feed, I just unfollow it. Done. Not a concern for me at all. Not the slightest bit. And the byte verification is THE source of all broken threads when the conversation start is edited. Yes, this can be viewed as a feature, but how many times was it actually a feature and not more behaving as an anti-feature in terms of user experience?

  4. I don’t get your argument. If the feed in question is offline, one can simply look in local caches and see if there is a message at that particular time, just like looking up a hash. Where’s the difference? Except that the lookup key is longer or compound or whatever depending on the cache format.

  5. Even a new hashing algorithm requires work on clients etc. It’s not that you get some backwards-compatibility for free. It just cannot be backwards-compatible in my opinion, no matter which approach we take. That’s why I believe some magic time for the switch causes the least amount of trouble. You leave the old world untouched and working.

If these are general concerns, I’m completely with you. But I don’t think that they only apply to location-based addressing. That’s how I interpreted your message. I could be wrong. Happy to read your explanations. :-)

⤋ Read More
prologic
twtxt.net
 (38w ago)

Here is just a small list of things™ that I’m aware will break, some quite badly, others in minor ways:

  1. Link rot & migrations: domain changes, path reshuffles, CDN/mirror use, or moving from txt → jsonfeed will orphan replies unless every reader implements perfect 301/410 history, which they won’t.
  2. Duplication & forks: mirrors/relays produce multiple valid locations for the same post; readers see several “parents” and split the thread.
  3. Verification & spam-resistance: content addressing lets you dedupe and verify you’re pointing at exactly the post you meant (hash matches bytes). Location anchors can be replayed or spoofed more easily unless you add signing and canonicalization.
  4. Offline/cached reading: without the original URL being reachable, readers can’t resolve anchors; with hashes they can match against local caches/archives.
  5. Ecosystem churn: all existing clients, archives, and tools that assume content-derived IDs need migrations, mapping layers, and fallback logic. Expect long-lived threads to fracture across implementations.

⤋ Read More