@prologic Sorry, I can’t spare the time to write a sufficiently detailed ELI5 today. Already spent all of the time I budgeted for shortform blogging writing about highlighter pens.
@prologic Protocol ossification means “loss of […] evolvability of network protocols.” (cf. Wikipedia https://en.wikipedia.org/wiki/Protocol_ossification). Related terms: Overfitting, Hyrum’s Law https://www.hyrumslaw.com/.
Oh, wow. That is a frightening level of protocol ossification.
Will it thread?
What if the subject is a valid twt hash, but the twt it refers to was never seen by yarnd
?
Time to find out!
Ok, so https://twtxt.net does not “thread” twts with matching but otherwise completely arbitrary subject strings. What will it do with an 8-character string that starts with #
but isn’t a valid twt hash?
Don’t mind the non-standard twt subject. I’m using this opportunity to test what happens to extant twtxt clients when they encounter arbitrary strings in the twt subject position.
If you want to read the post, but aren’t quite ready to install a gemini browser, it’s also reachable through this gemini-to-https portal: https://portal.mozz.us/gemini/asquare.srht.site/gemlog/highlighter_pen.gmi
I recount the complete story in a 573-word shortform post on my gemlog: gemini://asquare.srht.site/gemlog/highlighter_pen.gmi
I was yesterday years old when I learned the correct way to use highlighter pens.
IMHO, the original spec had it right when it said (paraphrased) “just upload your tw.txt
file wherever”. The essence of micro-blogging, as opposed to full-scale blogging, is low friction and low stakes. Imposing a norm that you can’t just use any ol’ url, looking down on people with insufficently cool urls (as in “Cool URIs don’t change” https://www.w3.org/Provider/Style/URI), puts up too much of a barrier to entry.
#b795meh
and #431barf
refer to the same twt - since hashes are one-way, Bob cannot recover the original urls from the hash and run them through his url-equivalence-checker.
Though actually, it’s still pretty easy to create strings that look like hashes even though they can’t ever be generated “legitimately”. Just use 1
, 8
or 9
anywhere in the string - those digits aren’t part of the base32 alphabet.
#b795meh
and #431barf
refer to the same twt - since hashes are one-way, Bob cannot recover the original urls from the hash and run them through his url-equivalence-checker.
An amusing consequence of the hash truncation misdesign: it’s possible to just make up hashes for hypothetical examples and be sure that they won’t collide with any real hash - just pick anything other than q
or a
for the last character.
You know how maps typically include a compass rose to help readers figure out where things are located in relation to each other? I want the anatomical equivalent of a compass rose for the linked drawing, because just by looking at it I can’t decipher which anatomical axis (anterior-posterior vs superior-inferior) corresponds to the up-down axis of the drawing. https://en.wikipedia.org/wiki/Uterus#/media/File:Uterus_image-Photoroom.png
Turns out that Factorio got an update two years ago that makes it playable with an X-Box controller - no need for a mouse. I could’ve been playing the Space Age expansion on launch day despite my injury (already healed, don’t worry) if only I’d bothered to check.
# nick
as a sort of "identifier". This gets us out of this mess of when feeds move locations or authors decide to host on 3 or 4 different protocols 🤣 Downside? Something picks the same nick? (they'll still hash differently, so that's fine).
Suppose now that Dana and Damien also reply to Alice’s twt, but use the twt hash extension to pick their subject string. When Bob gets their replies, his client is unable to figure out that #b795meh
and #431barf
refer to the same twt - since hashes are one-way, Bob cannot recover the original urls from the hash and run them through his url-equivalence-checker.
# nick
as a sort of "identifier". This gets us out of this mess of when feeds move locations or authors decide to host on 3 or 4 different protocols 🤣 Downside? Something picks the same nick? (they'll still hash differently, so that's fine).
Bob, who follows alice at http://example.net/~alice/tw.txt, has configured his client to recognize https://example.com/ugc/alice.txt as an alternate source for the same feed. When he fetches Charlie and Carmen’s respective feeds, his client can recognize that even though they used different subject strings, both refer to the same twt and can be displayed as a single thread.
# nick
as a sort of "identifier". This gets us out of this mess of when feeds move locations or authors decide to host on 3 or 4 different protocols 🤣 Downside? Something picks the same nick? (they'll still hash differently, so that's fine).
Suppose that Alice mirrors her feed at http://example.net/~alice/tw.txt and https://example.com/ugc/alice.txt. Suppose further that Charlie and Carmen reply to one of her twt using url-and-timestamp as the subject, getting 2 different subject strings for the same twt because each one is following her on a different url.
# nick
as a sort of "identifier". This gets us out of this mess of when feeds move locations or authors decide to host on 3 or 4 different protocols 🤣 Downside? Something picks the same nick? (they'll still hash differently, so that's fine).
@prologic Feeds moving or being mirrored in multiple locations don’t inherently create a mess. Things only become messy when an opaque hash is added to the mix.
a
or a q
? Which is the natural consequence of taking the last digit in the base32 representation of a 256-bit hash -- 256 is not evenly divisible by 5 ! That final character is made up of one bit of actual information and 4 bits of padding.
Oops, I’ve typed many words before thinking how to express the same thoughts more succintly. The TL;DR version is: attempting to detect edits from a client’s perspective leads to race conditions, and trying to increase your chance to “win the race” leads to wasteful behavior.
a
or a q
? Which is the natural consequence of taking the last digit in the base32 representation of a 256-bit hash -- 256 is not evenly divisible by 5 ! That final character is made up of one bit of actual information and 4 bits of padding.
And I’d like to be able to fetch the feeds of people I don’t regularly follow on an as-needed basis, instead of having to pre-emptively discover and fetch every feed in the entire network just in case they might be relevant to a thread in the near future.
a
or a q
? Which is the natural consequence of taking the last digit in the base32 representation of a 256-bit hash -- 256 is not evenly divisible by 5 ! That final character is made up of one bit of actual information and 4 bits of padding.
Speaking only for myself, I’d like threading to work in a way that lets me keep using my flaky home internet connection, rather than spend money on a VPS in some datacenter with a reliable connection.
a
or a q
? Which is the natural consequence of taking the last digit in the base32 representation of a 256-bit hash -- 256 is not evenly divisible by 5 ! That final character is made up of one bit of actual information and 4 bits of padding.
@prologic With respect, a client can not identify whether an edit took place. Not unless that same client witnessed both the original twt and the edited one. This won’t be the case if a person you’re following is joining a thread started by people you aren’t following after the first twt of that thread has already been modified. Or if you’re knocked offline by a multi-hour power outage that spans then entire time window between a twt getting uploaded and modified.
a
or a q
? Which is the natural consequence of taking the last digit in the base32 representation of a 256-bit hash -- 256 is not evenly divisible by 5 ! That final character is made up of one bit of actual information and 4 bits of padding.
@prologic Twt Hash isn’t location addressed, though. Calculation of the hash takes the content of a twt into account, making it content addressed. That’s why it breaks threading if someone edits the first twt in the thread.