yarnd. Has it been successful, well sort of, somewhat (_but that doesn't matter, I like that it's small and niche anyway_).I agree that the goal of simplicity is a good goal to strive for, which is why I'm actually suggesting we change the Twt identifiers to be a simple SHA256 hash, something that everyone understand and has readily available tools for. I really don't think we should be doing any of this by hand to be honest. But part of the beauty of Twt Subject and Twt Hash(es) in the first place is replying by hand is much much easier because you only have a short 7 or 11 character thing to copy/paste in your reply. Switching to something like
<url> <timestamp> with a space in it is going to become a lot harder to copy/paste, because you can't "double click" (_or is it triple click for some?_) to copy/paste to your clipboard/buffer now 🤣Anyway I digress... On the whole edit thing, I'm actually find if we don't support it at all and don't build a protocol around that. I have zero issues with dropping that as an idea. Why? Because I actually think that clients should be auto-detecting edits anyway. They already can, I've PoC'd this myself, I _think_ it can be done. I haven't (yet), and one of the reasons I've not spent much effort in it is it isn't something that comes up frequently anyway.
Who cares if a thread breaks every now 'n again anyway?_
yarnd. Has it been successful, well sort of, somewhat (_but that doesn't matter, I like that it's small and niche anyway_).I agree that the goal of simplicity is a good goal to strive for, which is why I'm actually suggesting we change the Twt identifiers to be a simple SHA256 hash, something that everyone understand and has readily available tools for. I really don't think we should be doing any of this by hand to be honest. But part of the beauty of Twt Subject and Twt Hash(es) in the first place is replying by hand is much much easier because you only have a short 7 or 11 character thing to copy/paste in your reply. Switching to something like
<url> <timestamp> with a space in it is going to become a lot harder to copy/paste, because you can't "double click" (_or is it triple click for some?_) to copy/paste to your clipboard/buffer now 🤣Anyway I digress... On the whole edit thing, I'm actually find if we don't support it at all and don't build a protocol around that. I have zero issues with dropping that as an idea. Why? Because I actually think that clients should be auto-detecting edits anyway. They already can, I've PoC'd this myself, I _think_ it can be done. I haven't (yet), and one of the reasons I've not spent much effort in it is it isn't something that comes up frequently anyway.
Who cares if a thread breaks every now 'n again anyway?_
If we were to use
(replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.This probably isn’t the best argument for
(replyto:…), but it is *an* argument.Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to
(reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
If we were to use
(replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.This probably isn’t the best argument for
(replyto:…), but it is *an* argument.Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to
(reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
If we were to use
(replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.This probably isn’t the best argument for
(replyto:…), but it is *an* argument.Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to
(reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
If we were to use
(replyto:…), I could just copy and paste the required info into my text editor. With echo … | sha256sum | base64 (+ the truncation step), I have to open a new terminal, make sure the tab gets copied verbatim, make sure that there’s no trailing whitespace in the content, little details like that. It *is* more effort.This probably isn’t the best argument for
(replyto:…), but it is *an* argument.Would people do all this manually? I don’t know. Probably not. But part of the fascination with twtxt is that you *could* do it.
I’m speaking from a point of extreme minimalism here and all this isn’t strictly only related to
(reply:…). It just reflects my general view on twtxt. The more additional things we build on top, the less interesting twtxt becomes (for me). My goal would be to find solutions that require *less*. Like, don’t solve edits breaking threads by *adding* another protocol, but by rethinking the whole thing, finding the root cause, and maybe come up with something that doesn’t need another building block on top.This is all I have to say for now. 😃 I’m gonna let things cool off for a while.
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with
vi or whatever, done.If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with
vi or whatever, done.If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with
vi or whatever, done.If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
> Location-based addressing is vulnerable to the content changing. If the content changes the "location" is no longer valid. This is a problem if you build systems that rely on this.
What you’re mentioning is *the primary reason*, imho, *for* location-based addressing. You’re referencing a certain entry in a feed by its timestamp and the author is free to edit it. This solves the problem of broken threads after edits. And editing “raw” twtxt files is a very natural thing to do in the twtxt world (just not in *Yarn*’s world). It’s one of the core aspects and main selling points: You just have a file that you can edit with
vi or whatever, done.If you think changing content is a *vulnerability* of location-based addressing, then I get the feeling that there’s some kind of big misunderstanding going on here. 🤔 Either on your end or on mine/ours. 🤔
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
rsync -zaXAP is what I use all the time. But that’s all – for the rest, I have to consult the manual. 😅
(#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).
(#abcdefg12345) to something like (https://twtxt.net/user/prologic/twtxt.txt 2024-09-22T07:51:16Z).
yarnd does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (_on the average case_).
yarnd does for example) and equally a 5x increase in on-disk storage as well. This is based on the Twt Hash going from a 13 bytes (content-addressing) to 63 bytes (on average for location-based addressing). There is roughly a ~20-150% increase in the size of individual feeds as well that needs to be taken into consideration (_on the average case_).
yarnd does (_as peering_) because there is no "integrity" to the Twt identified by it's <url> <timestamp>. The identify is meaningless and is only valid as long as you can trust the location and that the location at that point hasn't changed its content.
yarnd does (_as peering_) because there is no "integrity" to the Twt identified by it's <url> <timestamp>. The identify is meaningless and is only valid as long as you can trust the location and that the location at that point hasn't changed its content.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a
echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> -- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a
echo -e "<url>\t<timestamp>\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> -- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
I also don't really buy the argument of simplicity either personally, because I don't technically see it much more difficult to take a
echo -e "<url>\\t<timestamp>\\t<content>" | sha256sum | base64 as the Twt Subject or concatenating the <url> <timestamp> -- The "effort" is the same. If we're going to argue that SHA256 or cryptographic hashes are "too complicated" then I'm not really sure how to support that argument.
yarnd supports the use of WebMentions, it's very rarely used in practise (_if ever_) -- In fact I should just drop the feature entirely.The use of WebSub OTOH is far more useful and is used by every single
yarnd pod everywhere (_no that there's that many around these days_) to subscribe to feed updates in ~near real-time _without_ having the poll constantly.~
yarnd supports the use of WebMentions, it's very rarely used in practise (_if ever_) -- In fact I should just drop the feature entirely.The use of WebSub OTOH is far more useful and is used by every single
yarnd pod everywhere (_no that there's that many around these days_) to subscribe to feed updates in ~near real-time _without_ having the poll constantly.~
1. The format:
(#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.2. Having something like
(#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
1. The format:
(#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.2. Having something like
(#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
1. The format:
(#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.2. Having something like
(#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
1. The format:
(#<DATE URL>) or (@<DATE URL>) both makes sense: # as prefix is for a hashtag like we allredy got with the (#twthash) and @ as prefix denotes that this is mention of a specific post in a feed, and not just the feed in general. Using either can make implementation easier, since most clients already got this kind of filtering.2. Having something like
(#<DATE URL>) will also make mentions via webmetions for twtxt easier to implement, since there is no need for looking up the #twthash. This will also make it possible to make 3th part twt-mentions services.3. Supporting twt/webmentions will also increase discoverability as a way to know about both replies and feed mentions from feeds that you don't follow.
#running
#running
#running
rsync(1) but, whenever I Tab for completion and get this:> λ ~/ rsync --
> zsh: do you wish to see all 484 possibilities (162 lines)?
I'm like: Nope! a
scp -rpCq ... or whatever option salad will do just fine. 😅 \n~
rsync(1) but, whenever I Tab for completion and get this:> λ ~/ rsync --
> zsh: do you wish to see all 484 possibilities (162 lines)?
I'm like: Nope! a
scp -rpCq ... or whatever option salad will do just fine. 😅 [Insert: "Ain't nobody got time fo'that!" Meme.]~
rsync(1) but, whenever I Tab for completion and get this:> λ ~/ rsync --
> zsh: do you wish to see all 484 possibilities (162 lines)?
I'm like: Nope! a
scp -rpCq ... or whatever option salad will do just fine. 😅 [Insert: "Ain't nobody got time fo'that!" Meme.]~
Thanks, @bender. :-)
Anyway… cheers!
#catsoftwtxt
/https://baldo.cat/media/photos/IMG_2115.jpeg) #catsoftwtxt
#catsoftwtxt
#catsoftwtxt
/https://baldo.cat/media/photos/IMG_2113.jpeg) #catsoftwtxt
#catsoftwtxt
Joy starts at you, not the platform you use. When you get bored, disgusted, offended, and leave X, come and let us know. I will be interested to read all about your experiment then. For now, “¡hasta pronto!”
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave
mthread a spin and this is crazy fast. 🤯 Tempting!
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave
mthread a spin and this is crazy fast. 🤯 Tempting!
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave
mthread a spin and this is crazy fast. 🤯 Tempting!
I have to admit, even though I knew they existed, I never had a look at Leah’s mail tools. Just gave
mthread a spin and this is crazy fast. 🤯 Tempting!
I'm being a little silly, of course. fzf doesn't actually check your email, but it appears to be basically the whole user interface for that mail program, with #mblaze wrangling the emails.
I've been thinking about how I handle my email, and am tempted to make something similar. (When I originally saw this linked the author was presenting it as an example tweaked to their own needs, encouraging people to make their own.)
This approach could surely also be combined with #jenny, taking the place of (neo)mutt. For example mblaze's mthread tool presents a threaded discussion with indentation.
https://media.ccc.de/v/ds24-394-linux-hello-world-nur-mit-einem-hex-editor
Luckily, everything™ is easier™ on DOS with
.COM files. A fun little time killer to make a HELLO.COM using only a hex editor, the Intel docs and the DOS interrupt list.That ModR/M stuff is easy in the end, but it took me quite some time to understand it. 🥴
(I’m still new to DOS on this level and didn’t know that all segment registers are initialized to the same values, apparently, so copying CS to DS was not necessary. Too lazy to update the screenshot. File size shrinks by 4 bytes.)
https://movq.de/v/0139fbaabc/doshello.png
https://media.ccc.de/v/ds24-394-linux-hello-world-nur-mit-einem-hex-editor
Luckily, everything™ is easier™ on DOS with
.COM files. A fun little time killer to make a HELLO.COM using only a hex editor, the Intel docs and the DOS interrupt list.That ModR/M stuff is easy in the end, but it took me quite some time to understand it. 🥴
(I’m still new to DOS on this level and didn’t know that all segment registers are initialized to the same values, apparently, so copying CS to DS was not necessary. Too lazy to update the screenshot. File size shrinks by 4 bytes.)
https://movq.de/v/0139fbaabc/doshello.png
https://media.ccc.de/v/ds24-394-linux-hello-world-nur-mit-einem-hex-editor
Luckily, everything™ is easier™ on DOS with
.COM files. A fun little time killer to make a HELLO.COM using only a hex editor, the Intel docs and the DOS interrupt list.That ModR/M stuff is easy in the end, but it took me quite some time to understand it. 🥴
(I’m still new to DOS on this level and didn’t know that all segment registers are initialized to the same values, apparently, so copying CS to DS was not necessary. Too lazy to update the screenshot. File size shrinks by 4 bytes.)
https://movq.de/v/0139fbaabc/doshello.png
https://media.ccc.de/v/ds24-394-linux-hello-world-nur-mit-einem-hex-editor
Luckily, everything™ is easier™ on DOS with
.COM files. A fun little time killer to make a HELLO.COM using only a hex editor, the Intel docs and the DOS interrupt list.That ModR/M stuff is easy in the end, but it took me quite some time to understand it. 🥴
(I’m still new to DOS on this level and didn’t know that all segment registers are initialized to the same values, apparently, so copying CS to DS was not necessary. Too lazy to update the screenshot. File size shrinks by 4 bytes.)
https://movq.de/v/0139fbaabc/doshello.png