@email@example.com (#wkjlotq) Exactly, @prologic told me in IRC about this the other day, so I adjusted tt. Prior to that I just generated twtxt.net/conv URLs for the subject hash link. If I feel like it tomorrow, I’ll send a MR. But please, you can go for it as well. :-)
@firstname.lastname@example.org (#lhi6wda) Sure. I’m currently just supporting Markdown links to include them in the URLs view so I can operate on them. Media still show the bang in front of them. But it’s good enough for now. ;-)
@email@example.com@firstname.lastname@example.org (#eqcx57q) I remember when I first heard about SQL injections back in the days and tried this on my self written PHP CMS’ login form. Surprisingly I successfully managed to break in. Absolutely not surprising at all in hindsight. I immediatly shut down everything – deny from all in the .htaccess.
Oh yeah, I just see Jupiter and Staturn next to the moon and Venus a bit further west (although it is hidden behind houses here at home). This looks really, really, really great, but my camera won’t cooperate in these light conditions. I’m totally flashed right now. Never experienced this in my life before.
@email@example.com (#uhjnvba) Yup, exactly. LANG is usually not defined in cronjobs (as aren’t most other environment variables neither). And then some weird fallbacks are gonna show their effects. Not sure whether LANG or other locale-related LC_* environment variables will be used in this case.
@prologic I reckon if the “Show my followings publicly” setting in yarnd is turned off, there should not be any # following = line in the twtxt.txt. The value is empty, but in my opinion the whole metadata field should be omitted entirely.
@firstname.lastname@example.org (#mxago7a) The legacy charset ISO 8859-15 is used in Western Europe. It appears that some Unicode character is tried to be interpreted in this other encoding, which then fails. Sounds like something with LANG, LC_CTYPE or friends. Any chance you’ve set this to en_US.UTF-8 or something similar in your interactive shell? Try env|grep -i utf-8. Your cronjob probably hasn’t set that.
@prologic (#pe5ymoa) Maybe her -00:00 timezones throws off a parser? I think I tried this edge case when coming up with the twt hash spec, but can’t tell anymore for sure. At least I’ve written this (2020-12-13T07:45:23-00:00 → 2020-12-13T07:45:23Z) explicitly down. The thing is, I just documented Go’s behavior to make sure I don’t break anything. Maybe add a test similar to this one and see what’s happening. :-?
@email@example.com (#pe5ymoa) It might be timestamps which are missing a timezone. In this case the spec says UTC must be assumed: if twt_date.tzinfo is None: twt_date = twt_date.replace(tzinfo=datetime.timezone.utc). I had to fix this in my implementation recently, too. Let me quickly provide a fix for the Python reference implementation in the spec.
@firstname.lastname@example.org (#2nstk3q) Ta! Yeah, I reckon the driver was too careless and slit off the road into the ditch. Maybe when giving way to oncoming traffic. Not sure, though. No, not shoes, croc as in crocodile. ;-)
@prologic (#kutrrnq) Currently I just have to come up with a free nick. Usually I just suffix the second, third and so on feed with an underscore and a shortend domain. I reckon it would make sense to render mentions in the user’s preferred nick. That of the viewing user that is. The mention of @<foo https://example.com/twtxt.txt> might for one user be shown as “@foo”, but “@foo_expl” for the other and “@[email protected]” for the next. So mentions would always be “rewritten” by what’s configured. That sounds great. I have to implement that in tt, at the moment it just renders the original nick from the mention itself.