* 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
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 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. :-)
Shelf sitting on the drill press table before installing it between the posts of the standWhen 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. :-)
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#L1278Turns 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.
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.
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.
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/
Beautiful colors in the woods
3. Summer lightning.
4. 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.
Did you manage to already hide it all in your tummy, @bender? :-)
Leaves and cows
Homemade try-square next to real squarehttps://lyse.isobeef.org/tmp/anschlagwinkel/
User-agent: *
Disallow: /
Allow: /$*
Recently, @bender made me finally switch to weechat in a tmux session on my server:
tmux new -s irc and then run weechat inside. On my local computer I then simply attach to that session, even got an alias for that: alias irc='ssh -t isobeef tmux attach -t irc' I'm now basically online 24/7 and can skip over the new messages in the backlog by hand when I start my local computer. :-DI'm very happy with that. Can't imagine ever going back right now. I'm also wondering why it took me all those years to finally make the small step. Happy IRCing!
Oh, and the
lang metadata field is indented with tabs, breaking the nice visual alignment._
Oh, and the
lang metadata field is indented with tabs, breaking the nice visual alignment._
Lol, Schnitzelklopfen mit einem in Tüte eingepackten Schlosserhammer, das kam mir so auch noch nie unter. :-D
"Like a true German, I'm going to open this beer with my eye socket." Hahahahahahaaaaa! :-D
di{ some time ago but entirely forgot about it.
Read it, prologic, it's totally worth it. That's a great writeup by some very cool dude.
The PR article by the company just speaks for itself and reinforces their dick move. No more questions. https://support.zendesk.com/hc/en-us/articles/8187090244506-Email-user-verification-bug-bounty-report-retrospective
Colored leaves in front of dark sky
I just like to send a proper
Content-Type stating the right encoding to be a good web citizen. That's all. :-)
> Clients (and human readers) just assume a flat threading
> structure by default, read things in order […]
I might misunderstand this, but I slightly disagree. Personally, I like to look at the tree structure and my client also does present me the conversation tree as an actual tree, not a flat list. Yes, this gets messy when there are a lot of branches and long messages, but I managed to live with that. Doesn't happen very often. Anyway, just a personal preference. Nothing to really worry.
> The v2 spec requires each reply to re-calculate the hash
> of the specific entry I’m replying to […]
Hmmmm, where do you read that the client has to re-calculate the hash on reply? (Sorry, I'm probably just not getting your point here in the entire paragraph.)
> Clients should not be expected to track conversations back
> across forking points […]
I agree. It totally depends on the client.
> Clients (and human readers) just assume a flat threading
> structure by default, read things in order \n
I might misunderstand this, but I slightly disagree. Personally, I like to look at the tree structure and my client also does present me the conversation tree as an actual tree, not a flat list. Yes, this gets messy when there are a lot of branches and long messages, but I managed to live with that. Doesn't happen very often. Anyway, just a personal preference. Nothing to really worry.
> The v2 spec requires each reply to re-calculate the hash
> of the specific entry I’m replying to \n
Hmmmm, where do you read that the client has to re-calculate the hash on reply? (Sorry, I'm probably just not getting your point here in the entire paragraph.)
> Clients should not be expected to track conversations back
> across forking points \n
I agree. It totally depends on the client.
Content-Type: text/plain might be not enough, as the HTTP spec defaults to Latin1 or whatever, not UTF-8. So there is a gap or room for incorrect interpretation. I could be wrong, but I understand @anth's comment that he doesn't want to even have a Content-Type header in the first place.I reckon it should be optional, but when deciding to sending one, it should be
Content-Type: text/plain; charset=utf-8. That also helps browsers pick up the right encoding right away without guessing wrong (basically always happens with Firefox here). That aids people who read raw feeds in browsers for debugging or what not. (I sometimes do that to decide if there is enough interesting content to follow the feed at hand.)
Bee hives in the evening shade
just before.
mkdir -p $dir and just retrying the command works.
Open(…) being successful and only executing the first command giving me that error. Meh.
They introduced these ribbons a few years back. It's a really cool system. The colors of the ribbons vary from town to town. It seems most actually use yellow ribbons. The rules are to be respectful, only take what you really need (common household amounts) and be careful not to break branches, not to trample down higher grass, watch out for pants and animals, etc. Sometimes, a tree owner only grants access to a few trees. So, you're only allowed to take from the explicitly marked ones. I mean, common sense really, don't be an asshole. :-)
We just pick up what has fallen down. You're also allowed to pick directly from the tree, but the apples on the ground are already fully ripe. Or bad, but you can typically distinguish between the two rather easily. The apples that fall down early are usually full of worms. Later on, it's the ripe ones. Yeah, if a ripe one lands in a patch of spoiled ones, it's also going bad fairly quickly. So, it pays off to visit regularly and check.
Not all apples are equal, though. It's important to check the variety before gathering them. Cider apples are worthless to us. They just taste awful. Typically, these are the tiny ones, but there are also some tiny ones which are actually very delicious. So, a taste test is mandatory.
Then for apple sauce we just wash off the occasional dirt on the apples at home. Typically, you can get rid of the worst already by wiping it on the grass when picking. We simply cut them in quarters, bigger apples also in eights. Bad spots and the cores are removed. To avoid oxidation, we throw them in a bowl of water with citric acid. Once that bowl is full, we transfer them into a big pot. Rinse and repeat.
The pot has some water in it, so the apples do not scorch. Shortly before we finish cutting the apples, the stove is heated. Then, we just let the whole mass heat up. Don't forget to stir every now and then. The longer it simmers, the easier it gets to actually stir the now softer mass. It also sinks down a bit. You can also use a potato masher to help get some sort of a pulp.
When the pulp is fairly soft it's pressed through a strainer. People here call the food mill "Flotte Lotte" (quick Charlotte) after a brand name. We use the tiniest sieve with 1mm holes. Unfortunately, there's no smaller one. But it gets 99.99% of the junk out, skin, missed seeds, all the coarse stuff. After each load the food mill has to be cleared from pomance, so it doesn't plug up all the holes or worse, the coarse crap is pressed through.
For some strange reason we have not figured out, we got quite a bunch of skin pieces in the apple sauce on Wednesday. Somehow they managed to get through. Very strange, this has never happened before. To filter them out, we just passed the whole thing through the Flotte Lotte a second time.
Around 10% sugar by weight is added to help preservation. A pinch of cinnamon and then it's basically ready when mixed up properly.
Fill the apple sauce is in jars and make sure to leave enough space for some expansion when getting cooked in a moment. Wipe any spilled sauce form the glas rims, close the lids with a rubber seal and clamp 'em shut. The jars are placed in a big pot or "Einkochautomat" (translates roughly to preserving machine). It's a large pot that is electrically heated and automatically maintains the temperature using a thermostat. The water level has to be about 2/3 of the top layer of the jars (they can be stacked). Any higher is unnecessary and just wastes water. The jars get cooked for half an hour at 90°C. Then, they can be lifted out with a pairs of jar tongs. After cooling down, the clamps are removed. If a jar hasn't sealed properly, you notice it right away.
The last thing is to label and store them in the cellar or somewhere.
Eventually, pull on the rubber seal's tab to open a jar, put the apple sauce on a waffle or something else and enjoy the blast of taste in your mouth. :-)
Oh, that text got a wee bit longer than anticipated. 8-)
I have the feeling that the hashing part is the most important one that should be sorted first.
Well, maybe I just use metric threads. I will sleep on this.
Anyway, I won't implement that in my client. Sounds too much effort for the tiny gain.
And yes, it literally took hours to remove 90% of the photos. It's the necessary evil. I'm never looking forward to the sorting process. The longer the hike, the worse the aftermath.
We had 3°C the other night, quite cold. That's the price to pay for the nice temperatures at daytime.
Yep, these are some sick mushrooms. No idea what they are, though. Not sure if they're edible more than once or not, but I have a feeling that one should refrain from trying. The ones I photographed here were in a nature reserve. They were a bit bigger than the others we came across on meadows. Still impressive sizes nevertheless.
The 16°C felt pretty cold with all the wind. Especially at the summit for a late lunch. The clouds covered the sun for almost the entire time and the wind blew hard. Being sweaty from the way up didn't help. The sun returned as soon as we packed up.
On the way home, it drizzled just a little bit, although the clouds were really dark. A nice surprise. All in all, we had a really nice hike. As a bonus, my mate established a new train ride record low to get home, despite all the Octoberfest crap going on right now.
Colorful leaves on a treeFrom my 395 photos, I only kept 40: https://lyse.isobeef.org/waldspaziergang-2024-09-28/ In 18's upper left corner you can see a black beetle similar to what I've seen earlier this week. The one that rolled over its side to change directions, this one didn't, though.
The mushroom in 35 and 36 was enormous, easily 20 centimeters in diameter. We came across a few of them along our journey.
But that shouldn't matter too much, as y'all know my point of view. I'm in the not so popular simplicity camp. ;-)
In any case, I wish you all some great fun and good discussions! :-)