Luckily I can still recognize the voice, so I know itās him, lol.
Luckily I can still recognize the voice, so I know itās him, lol.
(replyto:ā¦):1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that Iāve implemented it) ā but now youāve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
(replyto:ā¦):1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that Iāve implemented it) ā but now youāve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
(replyto:ā¦):1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that Iāve implemented it) ā but now youāve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
(replyto:ā¦):1. You need a special client again to compute hashes.
2. The original feed URL is no longer visible, thus you might need to ask a Yarn pod occasionally for missing twts (I do that surprisingly often, now that Iāve implemented it) ā but now youāve lost the guarantee that Yarn gives you the correct information, because you can no longer verify it.
(replyto:example.com/tw.txt,$timestamp) but maybe that feed doesnāt actually contain that stamp, so you have to got further back ā¦ but you should NOT reference an archived feed in your (replyto:ā¦) thingy, it should still be the āmain feed URLā (because the contents of archived feeds arenāt stable, see @prologicās feeds for example). Thatās not too great.Man, Iām completely torn on this. Iād almost prefer not to decide anything. š
(replyto:example.com/tw.txt,$timestamp) but maybe that feed doesnāt actually contain that stamp, so you have to got further back ā¦ but you should NOT reference an archived feed in your (replyto:ā¦) thingy, it should still be the āmain feed URLā (because the contents of archived feeds arenāt stable, see @prologicās feeds for example). Thatās not too great.Man, Iām completely torn on this. Iād almost prefer not to decide anything. š
(replyto:example.com/tw.txt,$timestamp) but maybe that feed doesnāt actually contain that stamp, so you have to got further back ā¦ but you should NOT reference an archived feed in your (replyto:ā¦) thingy, it should still be the āmain feed URLā (because the contents of archived feeds arenāt stable, see @prologicās feeds for example). Thatās not too great.Man, Iām completely torn on this. Iād almost prefer not to decide anything. š
(replyto:example.com/tw.txt,$timestamp) but maybe that feed doesnāt actually contain that stamp, so you have to got further back ā¦ but you should NOT reference an archived feed in your (replyto:ā¦) thingy, it should still be the āmain feed URLā (because the contents of archived feeds arenāt stable, see @prologicās feeds for example). Thatās not too great.Man, Iām completely torn on this. Iād almost prefer not to decide anything. š
(replyto:ā¦) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply donāt apply to my use cases. š I donāt run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I donāt have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isnāt one of my goals. Itās a completely different thing for me. Hmmm. š¤
(replyto:ā¦) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply donāt apply to my use cases. š I donāt run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I donāt have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isnāt one of my goals. Itās a completely different thing for me. Hmmm. š¤
(replyto:ā¦) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply donāt apply to my use cases. š I donāt run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I donāt have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isnāt one of my goals. Itās a completely different thing for me. Hmmm. š¤
(replyto:ā¦) instead of (#123467), because the original source of the twt is no longer obscured by a hash value and I can just pull the original feed. Asking a Yarn pod is only interesting at the moment because I have no idea where to get (#123467) from.Only when the original feed has gone offline will querying a Yarn pod become relevant again.
I have to admit here that some of the goals/philosophy of Yarn simply donāt apply to my use cases. š I donāt run a daemon that speaks a gossipping protocol with neighboring pods or stuff like that. I think I donāt have a hard time accepting that feeds might go offline in two months, so be it. Digging up ancient twts from some sort of globally distributed file system isnāt one of my goals. Itās a completely different thing for me. Hmmm. š¤
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? š³
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? š³
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? š³
https://www.youtube.com/watch?v=4WCTGycBceg
Basically a different person to me. Is it just me or has he really changed that much? š³
--fetch-context, which asks a Yarn pod for a twt, wouldnāt *break*, but jenny would not be able anymore to verify that it actually got the correct twt. Thatās a concrete example where we would lose functionality.
--fetch-context, which asks a Yarn pod for a twt, wouldnāt *break*, but jenny would not be able anymore to verify that it actually got the correct twt. Thatās a concrete example where we would lose functionality.
--fetch-context, which asks a Yarn pod for a twt, wouldnāt *break*, but jenny would not be able anymore to verify that it actually got the correct twt. Thatās a concrete example where we would lose functionality.
--fetch-context, which asks a Yarn pod for a twt, wouldnāt *break*, but jenny would not be able anymore to verify that it actually got the correct twt. Thatās a concrete example where we would lose functionality.
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and
(replyto:ā¦), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround āto avoid broken threads all the timeā.) The net result would be *less code*.Implementing this whole
(edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)Do you see why Iām so reluctant to jump on this bandwagon? š
I havenāt come up yet with good, concrete examples where
(replyto:ā¦) would break. As soon as that happens, Iāll change my mind. š¤
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and
(replyto:ā¦), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround āto avoid broken threads all the timeā.) The net result would be *less code*.Implementing this whole
(edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)Do you see why Iām so reluctant to jump on this bandwagon? š
I havenāt come up yet with good, concrete examples where
(replyto:ā¦) would break. As soon as that happens, Iāll change my mind. š¤
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and
(replyto:ā¦), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround āto avoid broken threads all the timeā.) The net result would be *less code*.Implementing this whole
(edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)Do you see why Iām so reluctant to jump on this bandwagon? š
I havenāt come up yet with good, concrete examples where
(replyto:ā¦) would break. As soon as that happens, Iāll change my mind. š¤
The thing that keeps bugging me is this:
If we were to switch to location-based addressing and
(replyto:ā¦), the edit problem would resolve itself. Implementations could use that exact string (e.g., https://example.com/tw.txt,2024-09-18T12:45Z) as the internal identifier of a twt and that is pretty much the only change that you have to make. And then you could throw away all code and tests currently required for calculating hashes. (In jenny, I would also be able to and actually have to remove that code that skips over twts with a timestamp older than $last_fetch. This only got added as a workaround āto avoid broken threads all the timeā.) The net result would be *less code*.Implementing this whole
(edit:#hash) thing means *more code*. (For jenny, specifically, *a lot* more code, if I want to allow users to create such twts.)Do you see why Iām so reluctant to jump on this bandwagon? š
I havenāt come up yet with good, concrete examples where
(replyto:ā¦) would break. As soon as that happens, Iāll change my mind. š¤
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, āupdate twtsā.
- A twt starting with
(edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.- A twt starting with
(delete:#3f36byq) advises clients to delete #3f36byq from their storage.Right?
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, āupdate twtsā.
- A twt starting with
(edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.- A twt starting with
(delete:#3f36byq) advises clients to delete #3f36byq from their storage.Right?
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, āupdate twtsā.
- A twt starting with
(edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.- A twt starting with
(delete:#3f36byq) advises clients to delete #3f36byq from their storage.Right?
1. Extend the hash length to avoid collisions.
2. Introduce the concept of, what shall we call it, āupdate twtsā.
- A twt starting with
(edit:#3f36byq) tells clients to update the twt #3f36byq with the content of this particular twt.- A twt starting with
(delete:#3f36byq) advises clients to delete #3f36byq from their storage.Right?
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, itās much less mysterious than that. š The twt in question exists in your archived feed. Itās not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So thatās clearly an advantage of the current system.~
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, itās much less mysterious than that. š The twt in question exists in your archived feed. Itās not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So thatās clearly an advantage of the current system.~
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, itās much less mysterious than that. š The twt in question exists in your archived feed. Itās not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So thatās clearly an advantage of the current system.~
> you'd never have been able to find let alone pull up that ~3yr old Twt of me (_my very first_), hell I'd even though I lost my first feed file or it became corrupted or something
I get what you mean, but to be fair, itās much less mysterious than that. š The twt in question exists in your archived feed. Itās not like I pulled it out of some cache of an unrelated Yarn pod.
But, yes, I *could have* done that and I could have verified that it actually is the twt I was looking for. So thatās clearly an advantage of the current system.~
It would be easy to do for releases, but itās a little hard to do for all the commits in between ā jenny has no build process, so thereās no easy way to incorporate the output of
git describe, for example.
It would be easy to do for releases, but itās a little hard to do for all the commits in between ā jenny has no build process, so thereās no easy way to incorporate the output of
git describe, for example.
It would be easy to do for releases, but itās a little hard to do for all the commits in between ā jenny has no build process, so thereās no easy way to incorporate the output of
git describe, for example.
It would be easy to do for releases, but itās a little hard to do for all the commits in between ā jenny has no build process, so thereās no easy way to incorporate the output of
git describe, for example.
The
(replyto:ā¦) proposal is definitely more in the spirit of twtxt, Iād say. Itās much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and itās things like that that brought me to twtxt in the first place.Iād also say that in our tiny little community, message integrity simply doesnāt matter. Signed feeds donāt matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, thereās enough āimplicit trustā or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? š
I do have to āadmitā, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the
(replyto:ā¦) proposal would work just as well in practice.
The
(replyto:ā¦) proposal is definitely more in the spirit of twtxt, Iād say. Itās much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and itās things like that that brought me to twtxt in the first place.Iād also say that in our tiny little community, message integrity simply doesnāt matter. Signed feeds donāt matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, thereās enough āimplicit trustā or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? š
I do have to āadmitā, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the
(replyto:ā¦) proposal would work just as well in practice.
The
(replyto:ā¦) proposal is definitely more in the spirit of twtxt, Iād say. Itās much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and itās things like that that brought me to twtxt in the first place.Iād also say that in our tiny little community, message integrity simply doesnāt matter. Signed feeds donāt matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, thereās enough āimplicit trustā or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? š
I do have to āadmitā, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the
(replyto:ā¦) proposal would work just as well in practice.
The
(replyto:ā¦) proposal is definitely more in the spirit of twtxt, Iād say. Itās much simpler, anyone can use it even with the simplest tools, no need for any client code. That is certainly a great property, if you ask me, and itās things like that that brought me to twtxt in the first place.Iād also say that in our tiny little community, message integrity simply doesnāt matter. Signed feeds donāt matter. I signed my feed for a while using GPG, someone else did the same, but in the end, nobody cares. The community is so tiny, thereās enough āimplicit trustā or whatever you want to call it.
If twtxt/Yarn was to grow bigger, then this would become a concern again. *But even Mastodon allows editing*, so how much of a problem can it really be? š
I do have to āadmitā, though, that hashes *feel* better. It feels good to know that we can clearly identify a certain twt. It feels more correct and stable.
Hm.
I *suspect* that the
(replyto:ā¦) proposal would work just as well in practice.
> - editing, if you don't care about message integrity
So thatās the big question, because thatās the only real difference between hashes and the
(replyto:ā¦) proposal.Do we care about message integrity?
With
(replyto:ā¦), someone could write a twt, then I reply to it, like āyouāre absolutely right!ā, and then that person could change their twt to something malicious like āthe earth is flat!ā And then it would look like Iām a nutcase agreeing with that person. š
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. Thatās good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isnāt message integrity ignored anyway now, at least in practice?
Thereās no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does
#12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we donāt want to break threads, so ā¦ whatās the point of using a hash?
> - editing, if you don't care about message integrity
So thatās the big question, because thatās the only real difference between hashes and the
(replyto:ā¦) proposal.Do we care about message integrity?
With
(replyto:ā¦), someone could write a twt, then I reply to it, like āyouāre absolutely right!ā, and then that person could change their twt to something malicious like āthe earth is flat!ā And then it would look like Iām a nutcase agreeing with that person. š
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. Thatās good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isnāt message integrity ignored anyway now, at least in practice?
Thereās no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does
#12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we donāt want to break threads, so ā¦ whatās the point of using a hash?
> - editing, if you don't care about message integrity
So thatās the big question, because thatās the only real difference between hashes and the
(replyto:ā¦) proposal.Do we care about message integrity?
With
(replyto:ā¦), someone could write a twt, then I reply to it, like āyouāre absolutely right!ā, and then that person could change their twt to something malicious like āthe earth is flat!ā And then it would look like Iām a nutcase agreeing with that person. š
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. Thatās good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isnāt message integrity ignored anyway now, at least in practice?
Thereās no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does
#12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we donāt want to break threads, so ā¦ whatās the point of using a hash?
> - editing, if you don't care about message integrity
So thatās the big question, because thatās the only real difference between hashes and the
(replyto:ā¦) proposal.Do we care about message integrity?
With
(replyto:ā¦), someone could write a twt, then I reply to it, like āyouāre absolutely right!ā, and then that person could change their twt to something malicious like āthe earth is flat!ā And then it would look like Iām a nutcase agreeing with that person. š
Hashes (in their current form) prevent that. The thread is broken and my reply clearly refers to something else. Thatās good, right?
But now take into account that we want to allow editing anyway. Is there even a point to using hashes anymore? Isnāt message integrity ignored anyway now, at least in practice?
Thereās no difference (in practice) between someone writing
2024-09-18T12:34Z Brds are great!
and then editing it to either
2024-09-18T12:34Z (original:#12379) Birds are great! (Whoops, fixed a typo.)
or
2024-09-18T12:34Z (original:#12379) The earth is flat!
The actual original message is (potentially) gone. The only thing that we can be sure of now is that the twt was edited in *some* way. *Essentially*, the actual twt message is no longer part of the hash, is it? What does
#12379 refer to? The edited message or the original one? We *want* it to refer to the edited one, because we donāt want to break threads, so ā¦ whatās the point of using a hash?
And I guess the release after that is going to include all the threading/hashing stuff ā if we can decide on one of the proposals. š
And I guess the release after that is going to include all the threading/hashing stuff ā if we can decide on one of the proposals. š
And I guess the release after that is going to include all the threading/hashing stuff ā if we can decide on one of the proposals. š
And I guess the release after that is going to include all the threading/hashing stuff ā if we can decide on one of the proposals. š
\\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\\\n2020-07-18T12:39:52Z\\\\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\n2020-07-18T12:39:52Z\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\n2020-07-18T12:39:52Z\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
\n into actual newlines:
$ echo -n "https://twtxt.net/user/prologic/twtxt.txt\n2020-07-18T12:39:52Z\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
zq4fgq
$ printf "https://twtxt.net/user/prologic/twtxt.txt\\n2020-07-18T12:39:52Z\\nHello World! š" | openssl dgst -blake2s256 -binary | base32 | tr -d '=' | tr 'A-Z' 'a-z' | tail -c 7
p44j3q
2024-09-18T23:08:00+10:00 Hllo World
2024-09-18T23:10:43+10:00 (edit:#229d24612a2) Hello World
2024-09-18T23:08:00+10:00\tHllo World
2024-09-18T23:10:43+10:00\t(edit:#229d24612a2) Hello World
2024-09-18T23:08:00+10:00 Hllo World
2024-09-18T23:10:43+10:00 (edit:#229d24612a2) Hello World
2024-09-18T23:08:00+10:00 Hllo World
2024-09-18T23:10:43+10:00 (edit:#229d24612a2) Hello World
It works for us because there are enough people around and thereās a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week youāre the poor bastard who is legally required to fix shit. Thatās just horrible, I donāt want that. š
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. š
It works for us because there are enough people around and thereās a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week youāre the poor bastard who is legally required to fix shit. Thatās just horrible, I donāt want that. š
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. š
It works for us because there are enough people around and thereās a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week youāre the poor bastard who is legally required to fix shit. Thatās just horrible, I donāt want that. š
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. š
It works for us because there are enough people around and thereās a good chance that someone will be able to help.
Really, I am glad that we have this model. The alternative would be actual on-call duty, like, this week youāre the poor bastard who is legally required to fix shit. Thatās just horrible, I donāt want that. š
What I was referring to in the OP: Sometimes I check the workphone simply out of curiosity. š
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
> The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII.
https://www.rfc-editor.org/rfc/rfc2046.html#section-4.1.2
https://www.rfc-editor.org/rfc/rfc6657#section-4
And, well, I also need that thing for 2FA. š
And, well, I also need that thing for 2FA. š
And, well, I also need that thing for 2FA. š