(#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
subject = '' for the existing conversation roots with subject > ''. Somehow, my brain must have read subject <> ''. That equality check should not have been touched at all. I just updated the updated archive for anyone who is interested to follow along: https://lyse.isobeef.org/tmp/tt2cache.tar.bz2 (151.1 KiB)
> BUGS
> None. Mutts have fleas, not bugs.
> BUGS
> None. Mutts have fleas, not bugs.
> BUGS
> None. Mutts have fleas, not bugs.
yarnd's cache became so complicated really. I mean it's a bunch of maps and lists that is recalculated every ~5m. I don't know of any better way to do this right now, but maybe one day I'll figure out a better way to represent the same information that is displayed today that works reasonably well.~
yarnd's cache became so complicated really. I mean it's a bunch of maps and lists that is recalculated every ~5m. I don't know of any better way to do this right now, but maybe one day I'll figure out a better way to represent the same information that is displayed today that works reasonably well.~
Using
EXPLAIN QUERY PLAN I was able to create two indices, to avoid some table scans:CREATE INDEX parent ON messages (hash, subject);
CREATE INDEX subject_created_at ON messages (subject, created_at);
Also, since strings are sortable, instead of
str_col <> '' I now use str_col > '' to allow the use of an index.But somehow, my output seems to be broken at the end for some reason, I just noticed. :-? Hmm.
The read status still gives me headache. I think I either have to filter in the application or create more meta data structures in the database.
I'm wondering if anyone here already used certain storages for tree data.
I wasn't very clear; my apologies. If we update the current hash truncation length from 7 to 11. But then still decide anyway to go down this location-based twt identity and threading model then yes, we're talking about twt subjects having a ~5x increase in size on average. Going from 14 characters (11 for the has, 2 for the parens, 1 for the #) to ~63 bytes (average I've worked out of length of URL + Timestamp) + 3 byte overhead for parents and space.~
I wasn't very clear; my apologies. If we update the current hash truncation length from 7 to 11. But then still decide anyway to go down this location-based twt identity and threading model then yes, we're talking about twt subjects having a ~5x increase in size on average. Going from 14 characters (11 for the has, 2 for the parens, 1 for the #) to ~63 bytes (average I've worked out of length of URL + Timestamp) + 3 byte overhead for parents and space.~
yarnd, but still.If this constitutes a hard “no” to the proposal, then I think we don’t need to discuss it further.
yarnd, but still.If this constitutes a hard “no” to the proposal, then I think we don’t need to discuss it further.
yarnd, but still.If this constitutes a hard “no” to the proposal, then I think we don’t need to discuss it further.
yarnd, but still.If this constitutes a hard “no” to the proposal, then I think we don’t need to discuss it further.