(#tuizh4q) @mutefall@twtxt.net @prologic@twtxt.net I don’t understand this answer at all from a technical perspective (leaving any philosophical arguments aside). A twtxt file is literally a flat file containing a list of all of a person’s posts. Surely simply displaying all of that person’s posts in Yarn should be the easiest possible thing to do, way easier than threading etc. Why would it require “investing heavily in infrastructure” or for the protocol to be “redesigned from the ground up”?

I’m guessing I’ve misunderstood what you’re saying; can you help me understand?

(#tuizh4q) @prologic@twtxt.net

How do you display this in any reasonable way?

Pagination? Like Yarn uses elsewhere. Or infinite scroll, but from the server side that’s still pagination.

Which is what? To view the entire contents one someone’s feed? 😅

Exactly. Every other social network has that feature; I’ve missed it here serveral times already and it looks like I’m not the only one.

I still don’t get the difficulty from a technical point of view I’m afraid. 🤔

(#tuizh4q) @prologic@twtxt.net

philosophical reasons […] design decision

That I can understand (though to the extent that I understand it, I think I disagree with it 😄). I was asking more about the technical barriers @mutefall@twtxt.net mentioned.

responses are provided from the cache

I see, so we’re taking about an architectural limitation in Yarn, rather than twtxt. Still, I know cache invalidation is famously hard, but surely an intentional page load from a user trying to view a feed that isn’t (fully) cached is about the best signal you could get to fetch that data from the origin? 🤔

(#tuizh4q) I’m clearly going to have to take a proper look at the code and get a feeling for the data architecture to understand this! From the outside I have to say if something as simple as “display all of a user’s posts” is impossible – especially when a twtxt file is literally a list of all of a user’s posts – it feels like some very strange architectural choices must have been made… but I am also well aware that a lot of painstaking thought by very clever people has gone into this, and I haven’t even looked at the code, so don’t mind me 😆

(#tuizh4q) I also totally get whet you’re saying about a twtxt file potentially growing to be huge. I guess that, and the fact that it’s necessary to work around it with a significant caching architecture, is a major downside to the model of twtxt itself which I hadn’t considered.

(#tuizh4q) I guess I should go read the code before asking too many questions, but I’m a little puzzled why the same issues with a feed being huge don’t present an issue every time you want to poll for updates? Particularly with the apparent convention of the newest posts being at the bottom of the file.

As for pagination, sure, it can be hard, but why would it be harder in this case than in the cases where Yarn already does it?

(As for infinite scroll, if you have pagination on the server side already, it’s trivial on the client side. Yes you need JS of course, but not a lot)

(#tuizh4q) Sorry I’m late, on the discussion, but as I see it. A big redis cluster will solve that issue (Twitter uses it) and a bit of js for the pagination client side. BUT the ability to be able to edit a post (impossible in twitter) makes it hard to have a big redis cluster.
The hardest part will mainly be for the client command line app.

(#tuizh4q) Time stamp +user id+ hashtwt should be enough. So you can have an append log and do the edit in the application.