caesar

twtxt.net

https://caesarschinas.com/

Recent twts from caesar

In-reply-to » @prologic so far as I can see both your and my most recent replies to #x6zqkha just disappeared - a bug?

@prologic@twtxt.net Hmm, if I post a message and then it’s gone when I reload the page, or if the message I replied to has gone, that’s definitely a bug from the UX point of view 😆 … but perhaps unavoidable in a distributed system. But since we’re both on the same pod, I don’t see why that’s an issue? Or is this pod itself running on some kind of distributed architecture?

In-reply-to » @nexeq given lightweight nature of yarnd and the twtxt protocol in general relying on a text file and a cache layer, a poderator who would desire to have n(x) timeline (i.e. all tweets from 2017 to today) would have to invest heavily in infrastructure and the protocol twtxt and client yarnd would have to be redesigned from the ground up.

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)

In-reply-to » @nexeq given lightweight nature of yarnd and the twtxt protocol in general relying on a text file and a cache layer, a poderator who would desire to have n(x) timeline (i.e. all tweets from 2017 to today) would have to invest heavily in infrastructure and the protocol twtxt and client yarnd would have to be redesigned from the ground up.

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.

In-reply-to » @nexeq given lightweight nature of yarnd and the twtxt protocol in general relying on a text file and a cache layer, a poderator who would desire to have n(x) timeline (i.e. all tweets from 2017 to today) would have to invest heavily in infrastructure and the protocol twtxt and client yarnd would have to be redesigned from the ground up.

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 😆

In-reply-to » @nexeq given lightweight nature of yarnd and the twtxt protocol in general relying on a text file and a cache layer, a poderator who would desire to have n(x) timeline (i.e. all tweets from 2017 to today) would have to invest heavily in infrastructure and the protocol twtxt and client yarnd would have to be redesigned from the ground up.

@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? 🤔

In-reply-to » @nexeq given lightweight nature of yarnd and the twtxt protocol in general relying on a text file and a cache layer, a poderator who would desire to have n(x) timeline (i.e. all tweets from 2017 to today) would have to invest heavily in infrastructure and the protocol twtxt and client yarnd would have to be redesigned from the ground up.

@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. 🤔

In-reply-to » Oh boi 😅 After having used [Matrix] for a bit over a day or so now (after having some initial troubles with "Federating") I have some really strong reservations on Matrix, Bridges and that whole ecosystem and it's architecture 😂 I'm really not certain I can live with some of the "decisions", "architectures" "culture" and over-engineering nature that is [Matrix] 🤔 #Matrix #Thoughts

@prologic@twtxt.net Hmm but if you’re self-hosting the bridges (the only option I think since they generally have to run on the same machine as the Matrix server) that man in the middle is yourself 😉

Of course you do have to trust the code, but it’s all open source.

In-reply-to » @nexeq given lightweight nature of yarnd and the twtxt protocol in general relying on a text file and a cache layer, a poderator who would desire to have n(x) timeline (i.e. all tweets from 2017 to today) would have to invest heavily in infrastructure and the protocol twtxt and client yarnd would have to be redesigned from the ground up.

@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?

In-reply-to » Oh boi 😅 After having used [Matrix] for a bit over a day or so now (after having some initial troubles with "Federating") I have some really strong reservations on Matrix, Bridges and that whole ecosystem and it's architecture 😂 I'm really not certain I can live with some of the "decisions", "architectures" "culture" and over-engineering nature that is [Matrix] 🤔 #Matrix #Thoughts

@prologic@twtxt.net but if you used those external services directly without bridging, you’d still have to trust all those things, right? Take, say, FB Messenger. Whether I ‘bridge’ it to Matrix or use Messenger directly, I have to ‘trust’ Facebook (ha ha, as if! 😆) Same for Signal, WhatsApp, IRC, or anything else you bridge to.
That said, I don’t really use bridging much; for the services I tried it for it was too much hassle making the bridge work for it to be worthwhile.