~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
~/.cache/jenny should reset everything, it doesn’t store any other state. 🤔
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
> 3.
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z)I think I like this a lot. 🤔
The problem with using *hashes* always was that they’re “one-directional”: You can construct a hash from URL + timestamp + twt, but you cannot do the inverse. When I see
#weadxga, I have no idea what that could possibly refer to.But of course something like
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) has all the information you need. This could simplify twt/feed discovery quite a bit, couldn’t it? 🤔 That thing that I just implemented – jenny asking some Yarn pod for some twt hash – would not be necessary anymore. Clients could easily and automatically fetch *complete* threads instead of requiring the user to follow all relevant feeds.Only using the timestamp to identify a twt also solves the edit problem.
It even is better for non-Yarn clients, because you now don’t have to read, understand, and implement a “twt hash specification” before you can reply to someone.
The only problem, really, is that
(replyto:http://darch.dk/twtxt.txt,2024-09-15T12:06:27Z) is *so long*. Clients would have to try harder to hide this. 😅
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
@prologic Oh, interesting. It doesn’t serve JSON, though, does it?
curl -s -H 'Accept: application/json' https://search.twtxt.net/twt/j7f652q gets me an HTML page. 🤔
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
--fetch-context thingy: It can now ask Yarn pods for twt hashes.https://www.uninformativ.de/git/jenny/commit/eefd3fa09083e2206ed0d71887d2ef2884684a71.html
This is only done as a last resort if there’s no other way to find the missing twt. Like, when there’s a twt that begins with just a hash and no user mention, there’s no way for jenny to know on which feed that twt can be found, so it’ll ask some Yarn pod in that case.
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
That temperature drop was pretty sudden. Boom, cold, no warning. Give me some time to adapt, man! 😂
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
I recently took the time to find an alternative route to one of my doctors. Hardly any people using that route *and* it’s faster. Absolutely brilliant. It’s like having a chauffeur. 😅
*But* navigating through that system is also a total nightmare. Which bus takes you to which places at which times, getting info about current construction sites, all that stuff. It takes forever.
And it doesn’t help at all that this is what their website looks like:
https://movq.de/v/acb23dc1c2/s.png
You can’t move that window at the bottom. It just sits there and takes up space from the map. It gets even worse: When you ask for a route, you get to see the buses and individual stops and all that – but all in that little window with that large font! Why do we all have widescreen monitors and than stack UI items vertically?
Sure, 30 years ago it was much worse. But it could also be much better today. 😅
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
OS/2 Warp 4 came with Java and that not only meant a runtime but *a JDK* including *API docs*. So, for AoC, I could try to solve as many puzzles as I can in that environment, directly on my old Pentium. For later puzzles, I’ll definitely want to switch to my normal workstation for faster development cycles – but I can still use Java and try to backport the solutions.
Sounds interesting. 🤔
https://movq.de/v/81ac0142f2/1.ff.jpg
https://movq.de/v/81ac0142f2/2.ff.jpg
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
@lyse Oof, well, good luck. Those multi-day meetings are usually really exhausting (and mostly pointless) in our company, hopefully it’s different at yours. ✌️
# url = field:gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
# url = field:gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
# url = field:gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
# url = field:gemini://gemini.ctrl-c.club/~nristen/twtxt.txt
And I wonder if @nristen is aware that the order of those fields matter. 🤔
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
> the right way to solve this is to use public/private key(s) where you _actually_ have a public key fingerprint as your feed's unique identity that never changes
Okay, this is interesting. How would this work in practice? 🤔
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.
Btw, @prologic, in my experience, people editing their twts is a much more common thing than people changing the URL of their feed. 😅 It breaks threading all the time.