lyse

lyse.isobeef.org

No description provided.

Recent twts from lyse
In-reply-to » It’s been so rainy and windy and cold these last few days, I hardly left the house. 😩

@movq@www.uninformativ.de Yesterday, it was relatively nice at 11°C or so. Very windy and completely gray, though. Today, the sun was out at roughly just 5°C. The colors glowed much more in reality than in the photos: https://lyse.isobeef.org/morgensonne-2024-11-20/

I finally changed the broken gear shift bowden cable of my bicycle in a longer lunch break.

⤋ Read More
In-reply-to » Time to rotate three months into archive feeds again.

@bender@twtxt.net My made-up rule is to keep at least three full months in the main feed and when rotating, I create one feed per month.

@doesnm@doesnm.p.psf.lt There is no real recommendation I think. But if you hit half a MiB or so, it might be worth considering to rotate in order to keep the network traffic low. People with bad connectivitiy might appreciate it. I want to implement HTTP range requests in my client rewrite at some point in time (but first, it has to become kinda usable, though).

⤋ Read More
In-reply-to » I didn’t realize that the queens of our very common black ants are huge: https://www.youtube.com/watch?v=UjbAsdiE7ZI

@movq@www.uninformativ.de When looking closely in the woods, I can spot ants that are sized the width of a finger. Soldier ants are also often larger than the workers they protect. But yeah, most ants in our regions are relatively small. :-)

⤋ Read More
In-reply-to » Giving paper notebooks another try. I love paper notebooks. The problem is that I'm very chaotic writing my ideas.

@movq@www.uninformativ.de I’m all in on paper. In fact I noted down a todo item today on a physical sheet of paper when I was on the phone with a workmate. It then occurred to me that I could have just written it in a scratch file.

The parchment, on the other hand, might be a bit wasteful for just temporary ideas that are not perfectly layed out yet.

⤋ Read More
In-reply-to » Numbers are hard. I just almost accidentally sent 33k€ to someone via bank transfer, because the banking website interpreted 334.90 as 33490,00. 😬 This is germany, so it wants a comma, not a dot …

@movq@www.uninformativ.de Yeah, the Swiss and C++ programmers use apostrophes. :-) My grandpa had an electronic desk calculator that also used some kind of apostrophes as the thousands separator on its cool display. Maybe it consisted of Nixie tubes, can’t remember anymore.

I think non-breaking spaces are preferred nowadays to avoid the confusion.

⤋ Read More
In-reply-to » Numbers are hard. I just almost accidentally sent 33k€ to someone via bank transfer, because the banking website interpreted 334.90 as 33490,00. 😬 This is germany, so it wants a comma, not a dot …

@movq@www.uninformativ.de The dot is the thousands separator, so I’m surprised that it did not interpret it as €334,900.00. Luckily, you caught it in time! :-)

⤋ Read More
In-reply-to » @sorenpeter Section 7 on emojis: Exactly that, it's an avatar for text interfaces. The metadata name needs tweaking, but that's a cool idea. If I implemented this in my client, I'd make the text avatar overridable by the user, though. Otherwise I'd probably only see boxes for everbody in my terminal. :-D

@bender@twtxt.net Fair point, could be. I probably have to implement it first or create some kind of a mockup to spare me the effort of some feature that I rip out again. :-)

⤋ Read More
⤋ Read More
In-reply-to » @eapl.me here are my replies (somewhat similar to Lyse's and James')

@sorenpeter@darch.dk Section 7 on emojis: Exactly that, it’s an avatar for text interfaces. The metadata name needs tweaking, but that’s a cool idea. If I implemented this in my client, I’d make the text avatar overridable by the user, though. Otherwise I’d probably only see boxes for everbody in my terminal. :-D

⤋ Read More
In-reply-to » Thanks @lyse! I'm replying here https://text.eapl.mx/reply-to-lyse-about-twtxt

Thank you, @eapl.me@eapl.me! No need to apologize in the introduction, all good. :-)

Section 3: I’m a bit on the fence regarding documenting the HTTP caching headers. It’s a very general HTTP thing, so there is nothing special about them for twtxt. No need for the Twtxt Specification to actually redo it. But on the other hand, a short hint could certainly help client developers and feed authors. Maybe it’s thanks to my distro’s Ngninx maintainer, but I did not configure anything for the Last-Modified and ETag headers to be included in the response, the web server just already did it automatically.

The more that I think about it while typing this reply, the more I think your recommendation suggestion is actually really great. It will definitely beneficial for client developers. In almost all client implementation cases I’d say one has to actually do something specifically in the code to send the If-Modified-Since and/or If-None-Match request headers. There is no magic that will do it automatically, as one has to combine data from the last response with the new request.

But I also came across feeds that serve zero response headers that make caching possible at all. So, an explicit recommendation enables feed authors to check their server setups. Yeah, let’s absolutely do this! :-)

Regarding section 4 about feed discovery: Yeah, non-HTTP transport protocols are an issue as they do not have User-Agent headers. How exactly do you envision the discovery_url to work, though? I wouldn’t limit the transports to HTTP(S) in the Twtxt Specification, though. It’s up to the client to decide which protocols it wants to support.

Since I currently rely on buckket’s twtxt client to fetch the feeds, I can only follow http(s):// (and file://) feeds. But in tt2 I will certainly add some gopher:// and gemini:// at some point in time.

Some time ago, @movq@www.uninformativ.de found out that some Gopher/Gemini users prefer to just get an e-mail from people following them: https://twtxt.net/twt/dikni6q So, it might not even be something to be solved as there is no problem in the first place.

Section 5 on protocol support: You’re right, announcing the different transports in the url metadata would certainly help. :-)

Section 7 on emojis: Your idea of TUI/CLI avatars is really intriguing I have to say. Maybe I will pick this up in tt2 some day. :-)

⤋ Read More
In-reply-to » I've been thinking of a few improvements for the next generation of twtxt spec, let me know if these are useful or interesting :) https://text.eapl.mx/a-few-ideas-for-a-next-twtxt-version

Righto, @eapl.me@eapl.me, ta for the writeup. Here we go. :-)

Metadata on individual twts are too much for me. I do like the simplicity of the current spec. But I understand where you’re coming from.

Numbering twts in a feed is basically the attempt of generating message IDs. It’s an interesting idea, but I reckon it is not even needed. I’d simply use location based addressing (feed URL + ‘#’ + timestamp) instead of content addressing. If one really wanted to, one could hash the feed URL and timestamp, but the raw form would actually improve disoverability and would not even require a richer client. But the majority of twtxt users in the last poll wanted to stick with content addressing.

yarnd actually sends If-Modified-Since request headers. Not only can I observe heaps of 304 responses for yarnds in my access log, but in Cache.FetchFeeds(…) we can actually see If-Modified-Since being deployed when the feed has been retrieved with a Last-Modified response header before: https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/cache.go#L1278

Turns out etags with If-None-Match are only supported when yarnd serves avatars (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/handlers.go#L158) and media uploads (https://git.mills.io/yarnsocial/yarn/src/commit/98eee5124ae425deb825fb5f8788a0773ec5bdd0/internal/media_handlers.go#L71). However, it ignores possible etags when fetching feeds.

I don’t understand how the discovery URLs should work to replace the User-Agent header in HTTP(S) requests. Do you mind to elaborate?

Different protocols are basically just a client thing.

I reckon it’s best to just avoid mixing several languages in one feed in the first place. Personally, I find it okay to occasionally write messages in other languages, but if that happens on a more regularly basis, I’d definitely create a different feed for other languages.

Isn’t the emoji thing “just” a client feature? So, feed do not even have to state any emojis. As a user I’d configure my client to use a certain symbol for feed ABC. Currently, I can do a similar thing in tt where I assign colors to feeds. On the other hand, what if a user wants to control what symbol should be displayed, similar to the feed’s nick? Hmm. But still, my terminal font doesn’t even render most of emojis. So, Unicode boxes everywhere. This makes me think it should actually be a only client feature.

⤋ Read More
In-reply-to » FYI 👋 I will be deleting the following inactive users from my pod (twtxt.net) soon™:

@prologic@twtxt.net Yeah, the principle of data economy. :-)

Btw. if you blindly run the command again in a few days, your query might match new feeds that are not included in today’s list. Hence, some accounts might be dropped without a warning. But then, they probably don’t care.

⤋ Read More