@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! :-)

@xuu@txt.sour.is Hahaha, nice expression. :-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. :-)

@xuu@txt.sour.is Yep!

@movq@www.uninformativ.de Riiiight, I now remember reading that a long time ago. :-)

@bender@twtxt.net I now read the German Wikipedia article on fog. These are some really beautiful pictures:

• https://upload.wikimedia.org/wikipedia/commons/a/a9/Nebelbank_in_der_W%C3%BCste_Namib_bei_Aus_%282018%29.jpg
  
• https://upload.wikimedia.org/wikipedia/commons/1/17/Space_Shuttle_Challenger_moving_through_fog.jpg
  
• https://upload.wikimedia.org/wikipedia/commons/9/96/Fog_Bow_%2819440790708%29.jpg
  
• https://upload.wikimedia.org/wikipedia/commons/a/ac/360_degrees_fogbow.jpg

@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

@xuu@txt.sour.is LOL :-D

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. :-)

Perfect, @eapl.me@eapl.me, it’s fixed again. In fact this editor seems to support the Unicode line separator character all too well, otherwise it would not have replaced it in the first place. :-D Time to switch to a more unintelligent editor. ;-)

Thanks, @bender@twtxt.net. I try to.

I haven’t noticed any smell of fog, @bender@twtxt.net. Might @nff@www.noizhardware.com’s experience stem from a similar phenomenon that creates a lovely smell after a good, air-cleaning rain shower?

I built another small shelf for the drill press. I upcycled the wooden sticks from New Year rockets that littered the neighborhood. I really love the rustic look of it: https://lyse.isobeef.org/tmp/tischbohrmaschinenregal/

When I glued the shelf between the posts of the stand, I tightened the long clamp too hard, ripping the back panel and shelf board apart. So, I had to reglue them. :-)

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.

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

Hey @eapl.me@eapl.me, your feed is broken. All U+2028 got transformed into newlines.

@movq@www.uninformativ.de Ta! Absolutely, go for it. :-)

@movq@www.uninformativ.de Oh, it’s only now that I got it… :-D

@falsifian@www.falsifian.org Thanks mate! It just occurred to me the other night that my alt choices are not the best. I should probably fix them.

This also reminds me of a JS snippet my mate wrote for navigation in browsers that don’t support incrementing numbers in the URLs. I’m using Tridactyl in Firefox and can Ctrl+A/Ctrl+X myself through albums with properly named files.

@movq@www.uninformativ.de :-D

@movq@www.uninformativ.de Yeah, I like the unstacked one better, too. But still a nice experiment I have to say. :-)

Went on a really cool walk today after the sun came out this arvo. Just 11°C and a fair bit of wind required a scarf and beanie. I love the autumn colors a lot and never tire of looking at them.

On the summit the view was absolutely terrible, because there were super low hanging clouds. But it still looked fairly spectacular. Very surreal, I could not make out the edge of the Swabian Alb. The haze just blended with the rest of the sky. Towards the sun it was just one giant white wall after half a kilometer or so. That doesn’t happen all that often here.

After dusk I saw five deer on a meadow. Well their outlines against the remaining backlit sky.

https://lyse.isobeef.org/waldspaziergang-2024-11-04/

@movq@www.uninformativ.de Because who would enjoy their show then if they took their audience with ‘em?

@bender@twtxt.net Enjoy your vacation! I’ve got you covered as I’m currently building a voodoo doll out of silvester rocket sticks in the form of a small shelf for my drill needles.

Yeah, @movq@www.uninformativ.de, on this week’s episode of Hair Care Tips™ with Lyse: It’s super rare that I have spray cream, but at the moment there is a can in the fridge. After giving it a good shake, I parked the lid right next to the plate on the cold ceran stove, so I could apply some cream on my piece of apple pie. I then put the lid back on and noticed that there was some cream on the stove now. Since I did not move the plate, I dragged my long hair right through… :-)

@movq@www.uninformativ.de Some more options:

1. Summer lightning.
   
2. Obviously aliens!11!!!1
   

I once saw a light show in the woods originating most likely from a disco a few kilometers away. That was also pretty crazy. There was absolutely zero sound reaching the valley I was in.

I dripped some whipped cream from the lid on the stove. When I licked it up I pulled my hair through the cream on my cake. :-D

Oh no, @movq@www.uninformativ.de, get well soon! My voice also sounds like it’s coming from a tin can.

Did you manage to already hide it all in your tummy, @bender@twtxt.net? :-)

@movq@www.uninformativ.de Congrats, this is cool! :-) When I returned yesterday, I saw also a bunch of those.

Oh boy, I’m looking for trapezoidal (like ACME thread) screws and nuts in left hand form. The rods are already expensive, but nuts feel like a total ripoff. A hex nut for Tr20x2 being 30mm long and 30mm in “diameter” costs me 22 bucks! O_o Just a single one, made of regular steel. A meter of rod is 21€. The more common Tr20x4 hex nut is just 7€ and the rod 17€, but 4mm pitch is a bit much for a leadscrew for semi-precision work I reckon.

Well, maybe I just use metric threads. I will sleep on this.

I heard a funny saying today: Democracy is when three foxes and a bunny decide what to have for dinner.

Good writeup, @anth@a.9srv.net! I agree to most of your points.

3.2 Timestamps: I feel no need to mandate UTC. Timezones are fine with me. But I could also live with this new restriction. I fail to see, though, how this change would make things any easier compared to the original format.

3.4 Multi-Line Twts: What exactly do you think are bad things with multi-lines?

4.1 Hash Generation: I do like the idea with with a new uuid metadata field! Any thoughts on two feeds selecting the same UUID for whatever reason? Well, the same could happen today with url.

5.1 Reply to last & 5.2 More work to backtrack: I do not understand anything you’re saying. Can you rephrase that?

8.1 Metadata should be collected up front: I generally agree, but if the uuid metadata field were a feed URL and no real UUID, there should be probably an exception to change the feed URL mid-file after relocation.

@aelaraji@aelaraji.com @mckinley@twtxt.net rsync -avzr with an optional --progress is what I always use. Ah, I could use the shorter -P, thanks @movq@www.uninformativ.de.

@falsifian@www.falsifian.org Yeah, delete requests feel very odd.

Now WTF!? Suddenly, @falsifian@www.falsifian.org’s feed renders broken in my tt Python implementation. Exactly what I had with my Go rewrite. I haven’t touched the Python stuff in ages, though. Also, tt and tt2 do not share any data at all.

By any chance, did you remove the ; charset=utf-8 from your Content-Type: text/plain header, falsifian?

@movq@www.uninformativ.de Non-ASCII characters were broken. Like U+2028, degrees (°), etc.

Turns out I used a silly library to detect the encoding and transform to UTF-8 if needed. When there is no Content-Type header, like for local files, it looks at the first 1024 bytes. Since it only saw ASCII in that region, the damn thing assumed the data to be in Windows-1252 (which for web pages kinda makes sense):

// TODO: change default depending on user's locale?
return charmap.Windows1252, "windows-1252", false

https://cs.opensource.google/go/x/net/+/master:html/charset/charset.go;l=102

This default is hardcoded and cannot be changed.

Trying to be smart and adding automatic support for other encodings turned out to be a bad move on my end. At least I can reduce my dependency list again. :-)

I now just reject everything that explicitly specifies something different than text/plain and an optional charset other than utf-8 (ignoring casing). Otherwise I assume it’s in UTF-8 (just like the twtxt file format specification mandates) and hope for the best.

Hmmmm, I somehow run into an encoding problem where my inserted data end up mangled in the database. But, both SQLite and Go use UTF-8. What’s happening here? :-?

@movq@www.uninformativ.de Yep, that’s very nice music. :-)

Can’t help myself, but I have to include the Uranus song now. :-D https://www.youtube.com/watch?v=OSWszdSHkyE#t=7

@falsifian@www.falsifian.org In my opinion it was a mistake that we defined the first url field in the feed to define the URL for hashing. It should have been the last encountered one. Then, assuming append-style feeds, you could override the old URL with a new one from a certain point on:

# url = https://example.com/alias/txtxt.txt
# url = https://example.com/initial/twtxt.txt
<message 1 uses the initial URL>
<message 2 uses the initial URL, too>
# url = https://example.com/new/twtxt.txt
<message 3 uses the new URL>
# url = https://example.com/brand-new/twtxt.txt
<message 4 uses the brand new URL>

In theory, the same could be done for prepend-style feeds. They do exist, I’ve come around them. The parser would just have to calculate the hashes afterwards and not immediately.

@aelaraji@aelaraji.com Just move to Mars to get an extra hour a day: https://spaceplace.nasa.gov/days/en/ If that’s not enough, Mercury should have you covered for sure.

When we passed a few horses in the forest, there was really strong soup odor in the air. It didn’t smell like horse at all, but soup. Maybe they’ve been soup horses, chickens were out of stock.

29°C, zero wind, extremely humid, luckily the sun was behind the clouds. I’m soaking wet, sweat ran down in streams and dripped in my eyes, it burned a bit. The sky is getting a little dark, I hope the thunderstorm and rain are really arriving here later. Rain had always been finally cancelled the couple last days.

I’m gotta go cool off my fingers now, they’re swollen from the heat.

Yeah, user error on my end, never mind. The persisted settings.yaml overrides the command line arguments. That’s surprising to me. I expected the command line options to overrule the config file. Oh well.

@abucci@anthony.buc.ci You can also use -R=false on the command line or leave it out entirely. When explicitly stating -R=false, there has to be an equal sign. With a space (-R false) it’s somehow parsed as -R which is equivalent to -R=true. O_o Very weird. I’d really like to see an error instead.

I still have to figure out the precedence of the settings.yaml or command line arguments. I’m probably holding it wrong, but it seems to give me different results…

@quark@ferengi.one @movq@www.uninformativ.de A general workaround in these cases is to wrap the command in a shell script and reference said script instead.

@mckinley@twtxt.net Wow, I was not aware, that there are different kinds of blackberries. But of course there are. Everything has all sorts of different species, why would it be different with these tasty guys? :-)

I just read up on them and – surprise, surprise – it turns out, the Himalayans are not native to most of Europe either. Doh! It gets even more interesting, their origin is unclear. Maybe Armenia and the Caucasus region. Fascinating!

@abucci@anthony.buc.ci Thank you for using Lyse’s Unofficial Yarnd Help Desk: https://lyse.isobeef.org/tmp/yarnd-disable-registrations.png

Today, I learned about vim "+normal $", how cool! :-) Thanks @quark@ferengi.one!

So, by “evolve” you actually mean “remove”, @prologic@twtxt.net? :-?

Correct, @bender@twtxt.net. Since the very beginning, my twtxt flow is very flawed. But it turns out to be an advantage for this sort of problem. :-) I still use the official (but patched) twtxt client by buckket to actually fetch and fill the cache. I think one of of the patches played around with the error reporting. This way, any problems with fetching or parsing feeds show up immediately. Once I think, I’ve seen enough errors, I unsubscribe.

tt is just a viewer into the cache. The read statuses are stored in a separate database file.

It also happened a few times, that I thought some feed was permanently dead and removed it from my list. But then, others mentioned it, so I resubscribed.

@falsifian@www.falsifian.org @bender@twtxt.net I’d certainly hate my client for automatic feed unsubscription, too.