Searching yarn

Twts matching #hash
Sort by: Newest, Oldest, Most Relevant
In-reply-to » @lyse i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified

@zvava@twtxt.net There would be only one hash for a message. Some to be defined magic date selects which hash to use. If the message creation timestamp is before this epoch, hash it with v1, otherwise hammer it through v2. Eventually, support for v1 could be dropped as nobody interacts with the old stuff anymore. But I’d keep it around in my client, because why not.

If users choose a client which supports the extensions, they don’t have to mess around with v1 and v2 hashing, just like today.

As for the school of thought, personally, I’d prefer something else, too. I’m in camp location-based addressing, or whatever it is called. There more I think about it, a complete redesign of twtxt and its extensions would be necessary in my opinion. Retrofitting has its limits. Of course, this is much more work, though.

⤋ Read More
In-reply-to » @prologic im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn't really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits

@lyse@lyse.isobeef.org i dont mind if the hash is not backward compatible but im not sure if this is the right way to proceed because the added complexity dealing with two hash versions isnt justified

regular end users wont care to understand how twt hashes are formed, they just want to use twtxt! so i guess i could work in protecting users from themselves by disallowing post edits on old posts or posts with replies, but i’m not fond of this either really. if they want to break a thread, they can just delete the post (though i’ve noticed yarn handling post deletes dubiously…)

on activitypub i do genuinely find myself looking through several month or even year old posts sometimes and deciding to edit/reword them a little to be slightly less confusing, this should be trivial to handle on twtxt which is an infinitely simpler specification

⤋ Read More
In-reply-to » wait why are so many of my post hashes not generating correctly ;w;

@zvava@twtxt.net I was about to suggest that you post some examples. By now, we’re pretty good at debugging hashing issues, because that happens so often. šŸ˜‚ But it looks like you figured it out on your own. āœŒļø

⤋ Read More

im unable to figure out why bbycll is not generating posts hashes for @lyse@lyse.isobeef.org’s feed correctly (or at least different from the ones generated by yarn)

i’m pretty sure the timezone is stripped off the offset correctly (2025-09-14T12:45:00+02:00 → 2025-09-14T12:45:00Z) though messing with how the hash is generated i can’t get it to make one that matches…but all other hashes for all other feeds seem to be correct? does yarn use a different canonical url for lyse internally? is there a bug in the libraries im using? bwehhh

⤋ Read More

wait why are so many of my post hashes not generating correctly ;w;

edit: i read the spec wrong :3 only +/-00:00 is stripped, not the entire timezone offset >.<

⤋ Read More
In-reply-to » @zvava Herw you go: https://git.mills.io/yarnsocial/twtxt.dev/pulls/28

@prologic@twtxt.net im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn’t really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits

i skimmed through discussions under other the proposals — i agree humans are very bad at keeping the integrity of the web in tact, but hashes in done in this way make it impossible even for systems to rebuild threads if any post edits have occurred prior to their deployment

⤋ Read More
In-reply-to » wait....so i'm like nearly done? it just works? and it's fast? this feels like the end of the first all-nighter i pulled where i just got post creation done, unaware of the three weeks that would follow — like looking at the roadmap i'm definitely not done but bbycll is like actually kind of usable now o.o

@bender@twtxt.net just a heads up im thinking of rewriting the database schema with hash v2 in mind >.<

⤋ Read More

ok so i have found a genuine twt hash collision. what do i do.

internally, bbycll relies on a post lookup table with post hashes as keys, this is really fast but i knew i’d inevitably run into this issue (just not so soon) so now i have to either:
Ā Ā 1) pick the newer post over the other
Ā Ā 2) break from specification and not lowercase hashes
Ā Ā 3) secretly associate canonical urls or additional entropy with post hashes in the backend without a sizeable performance impact somehow

⤋ Read More
In-reply-to » @zvava I am getting [2025/09/11 12:56:01.816] ⇒ please set config.host when trying to run "bbycll". How to bypass that tiny hurdle?

@bender@twtxt.net as the host (eg twtxt.net) determines the canonical url of the instance in generated feed url metadata as well as every hash of every post made on the instance internally, i added this error message to make sure people don’t accidentally set up their instance on localhost :p for testing i set it to localhost:31212 and protocols to ["http"], it’s a recent addition that could definitely do with documenting in the getting started section

⤋ Read More

at first i dismissed the idea of likes on twtxt as not sensible…like at all — then i considered they could just be published in a metadata field (though that field could get really unruly after a while)

retwts are plausible, as ā€œRE: https://example.com/twtxt.txt#abcdefgā€, the hash could even be the original timestamp from the feed to make it human readable/writable, though im extremely wary of clogging up timelines

i thought quote twts could be done extremely sensibly, by interpreting a mention+hash at the end of the twt differently to when placed at the beginning — but the twt subject extension requires it be at the beginning, so the clean fallback to a normal reply i originally imagined is out of the question — it could still be possible (reusing the retwt format, just like twitter!) but i’m not convinced it’s worth it at that point

is any of this in the spirit of twtxt? no, not in the slightest, lmao

⤋ Read More

beginnings of remote feed parsing..! the fact hashing just sort of works with the minuscule libraries i found for base32 and blake2b still amazes me (mentions are being eaten as html tags)

⤋ Read More
In-reply-to » replies and following implemented! next step is further parsing of post contents, rendering threads, and then maybe i can finally start adding remote feeds...! though i kinda wanna redo the whole ui ^^'

@zvava@twtxt.net may I recommend to change the mention format upon hitting reply to something similar to what it’s used in Yarn, and perhaps hiding the hash on the post too? Looking good!

⤋ Read More
In-reply-to » It might just be my client, but it seems that I cannot track multiple URLs at once. As such, all three of my twtxt URLs will work for following, but mentions will only reach me at my HTTPS URL (https://hashnix.club/~dce/twtxt.txt). If there is a client that can cope with twtxt mirrors, I would love to know about it.

@movq@www.uninformativ.de Yeah, we’ve seen how this plays out in practice 🤣 @dce@hashnix.club My advice, do what @movq@www.uninformativ.de has hinted at and don’t change the 1st # url = field in your feed. I’m not sure if you had already, but the first url field is kind of important in your feed as it is used as the ā€œHashing URIā€ for threading.

⤋ Read More
In-reply-to » It might just be my client, but it seems that I cannot track multiple URLs at once. As such, all three of my twtxt URLs will work for following, but mentions will only reach me at my HTTPS URL (https://hashnix.club/~dce/twtxt.txt). If there is a client that can cope with twtxt mirrors, I would love to know about it.

@dce@hashnix.club Ah, oh, well then. 🄓

My client supports that, if you set multiple url = fields in your feed’s metadata (the top-most one must be the ā€œmainā€ URL, that one is used for hashing).

But yeah, multi-protocol feeds can be problematic and some have considered it a mistake to support them. šŸ¤”

⤋ Read More

I have zero mental energy for programming at the moment. 🫤

I’ll try to implement the new hashing stuff in jenny before the ā€œdeadlineā€. But I don’t think you’ll see any texudus development from me in the near future. ā˜¹ļø

⤋ Read More
In-reply-to » @prologic if I understand correctly it's just to increase hash size from 7 to 12 once it gets calculated, isn't it? BTW is this change already approved? I still don't understand how a proposal become an implementation in the twtxtverse šŸ¤“

@lyse@lyse.isobeef.org Yeah to avoid cutting off bits at the end making hashes end in either q or a 🤣

⤋ Read More
In-reply-to » @prologic Not sure I’d attach any if clauses to this. My point is: Every time I see a hash, I’d like to have a hint as to where to find the corresponding twt.

The reason I think this can work so well and I’m in full support of it is that it’s the least disruptive way to resolve the issue of:

where did this hash come from?

⤋ Read More
In-reply-to » If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

@prologic@twtxt.net Not sure I’d attach any if clauses to this. My point is: Every time I see a hash, I’d like to have a hint as to where to find the corresponding twt.

⤋ Read More
In-reply-to » If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

@movq@www.uninformativ.de If we’re focusing on solving the ā€œmissing rootsā€ problems. I would start to think about ā€œclient recommendationsā€. The first recommendation would be:

  1. Replying to a Twt that has no initial Subject must itself have a Subject of the form (hash; url).

This way it’s a hint to fetching clients that follow B, but not A (in the case of no mentions) that the Subject/Root might (very likely) is in the feed url.

⤋ Read More

If we must stick to hashes for threading, can we maybe make it mandatory to always include a reference to the original twt URL when writing replies?

Instead of

(<a href="https://yarn.girlonthemoon.xyz/search?q=%23123467">#123467</a>) hello foo bar

you would have

(<a href="https://yarn.girlonthemoon.xyz/search?q=%23123467">#123467</a> http://foo.com/tw.txt) hello foo bar

or maybe even:

(<a href="https://yarn.girlonthemoon.xyz/search?q=%23123467">#123467</a> 2025-04-30T12:30:31Z http://foo.com/tw.txt) hello foo bar

This would greatly help in reconstructing broken threads, since hashes are obviously unfortunately one-way tickets. The URL/timestamp would not be used for threading, just for discovery of feeds that you don’t already follow.

I don’t insist on including the timestamp, but having some idea which feed we’re talking about would help a lot.

⤋ Read More
In-reply-to » Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) šŸ˜… And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

July 1st. 63 days from now to implement a backward-incompatible change, apparently not open to other ideas like replacing blake with SHA, or discussing implementation challenges for other languages and platforms.
Finally just closing #18, #19 and #20 without starting a proper discussion and ignoring a ā€˜micro consensus’ feels… not right.

I don’t know what to think rather than letting it rest (May will be busy here) and focus on other stuff in the future.

twt-hash-v2.md#implementation-timeline

⤋ Read More
In-reply-to » Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) šŸ˜… And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! -- I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social's 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

I will be adding the code in for yarnd very soonā„¢ for this change, with a if the date is >= 2025-07-01 then compute_new_hashes else compute_old_hashes

⤋ Read More

Finally I propose that we increase the Twt Hash length from 7 to 12 and use the first 12 characters of the base32 encoded blake2b hash. This will solve two problems, the fact that all hashes today either end in q or a (oops) šŸ˜… And increasing the Twt Hash size will ensure that we never run into the chance of collision for ions to come. Chances of a 50% collision with 64 bits / 12 characters is roughly ~12.44B Twts. That ought to be enough! – I also propose that we modify all our clients and make this change from the 1st July 2025, which will be Yarn.social’s 5th birthday and 5 years since I started this whole project and endeavour! 😱 #Twtxt #Update

⤋ Read More

I had Chick-fil-A breakfast today (sausage, egg, and cheese biscuit, hash browns, coffee, and orange juice). Then at lunch my work place offered hot dogs. I had two (kosher, if that matters), plus a coke, a macadamia nuts cookie, and a small chocolate brownie.

So, here I am, at home, feeling hungry but guilty and refusing to eat anything else for the rest of the day. To top it off, I have only clocked 4,000 steps today (and I don’t feel like walking). I am going to hell, am I?

⤋ Read More
In-reply-to » @andros maybe create a separate, completely distinct feed for DM? That way, clients do not need to do anything, only those wanted to "talk in private" follow themselves, using their very special dm-only.txt feeds. šŸ˜‚

by commenting out DMs are you giving up on simplicity? See the Metadata extension holding the data inside comments, as the client doesn’t need to show it inside the timeline.

I don’t think that commenting out DMs as we are doing for metadata is giving up on simplicity (it’s a feature already), and it helps to hide unwanted DMs to clients that will take months to add it’s support to something named… an extension.

For some other extensions in https://twtxt.dev/extensions.html (for example the reply-to hash #abcdfeg or the mention @ < example http://example.org/twtxt.txt >) is not a big deal. The twt is still understandable in plain text.
For DM, it’s only interesting for you if you are the recipient, otherwise you see an scrambled message like 1234567890abcdef=. Even if you see it, you’ll need some decryption to read it. I’ve said before that DMs shouldn’t be in the same section that the timeline as it’s confusing.

So my point stands, and as I’ve said before, we are discussing it as a community, so let’s see what other maintainers add to the convo.

⤋ Read More
In-reply-to » @andros maybe create a separate, completely distinct feed for DM? That way, clients do not need to do anything, only those wanted to "talk in private" follow themselves, using their very special dm-only.txt feeds. šŸ˜‚

After reading you, @eapl.me@eapl.me, I’ll tell you my point of view.
In my opinion, a feed does not have to be equivalent to a timeline. A timeline is a representation of the feed adapted to a user. You may not be interested in seeing other people’s threads or DMs. But perhaps they are interested in seeing mentions or DMs directed at them. It is important not to fall into the trap. With that clarification…
I insist, this is my point of view, it is not an absolute truth: I don’t think extensions should be respectful of customers who are no longer maintained.
We cannot have a system that is simple, backwards compatible and extensible all at the same time. We have to give up some of the 3 points. I would not like to give up simplicity because it will then make it harder to maintain the customers who do stay. Therefore, I think it is better to give up backwards compatibility and play with new formulas in the extensions. I don’t think it’s a good idea to make a hash keep so much load: a hashtag, a thread and also a DM.

⤋ Read More
In-reply-to » @bender I noticed that although the Discover view (and your own Timeline) is much improved with a MaxAgeDays configuration at the pod level, that now some profiles are rather empty. This is only because well, they're a bit "inactive" so to speak šŸ—£ļø Not sure what to do about this at the moment... Open to ideas? šŸ’”

yes it used be http:// only and to keep hashes from breaking i added # url = http://... and now we are stock with it due to the curret specs.

⤋ Read More

Hmmm there’s a bug somewhere in the way I’m ingesting archived feeds šŸ¤”

sqlite> select * from twts where content like 'The web is such garbage these days%';
      hash = 37sjhla
  feed_url = https://twtxt.net/user/prologic/twtxt.txt/1
   content = The web is such garbage these days šŸ˜” Or is it the garbage search engines? šŸ¤”
   created = 2024-11-14T01:53:46Z
created_dt = 2024-11-14 01:53:46
   subject = #37sjhla
  mentions = []
      tags = []
     links = []
sqlite>

⤋ Read More

Some A hole has been trying to pull every single Twtxt feed that existed/still exists since forever. How do I know? Welp’ They’ve been querying my Timelineā„¢ instance for all of it, every single twtxt file and twt Hash they can find. šŸ˜†šŸ¤¦ It must have been going on for days and I have just noticed… + it’s all coming from the same ASN AS136907 HWCLOUDS-AS-AP HUAWEI CLOUDS

Thank you Huawei for the DDos you sons of Glitches!!!

⤋ Read More
In-reply-to » @david @andros The correct hash would be si4er3q. See https://twtxt.dev/exts/twt-hash.html, a timezone offset of +00:00 or -00:00 must be replaced by Z.

@eaplme@eapl.me you wrote:

ā€œThat PHP snippet could be merged into https://twtxt.dev/exts/twt-hash.htmlā€

Why, though? AFAIK @andros@twtxt.andros.dev’s client is on Emacs, @lyse@lyse.isobeef.org’s is on Python (and Golang, for tt2), @movq@www.uninformativ.de’s is on Python, and @prologic@twtxt.net’s is on Golang. All the client creator needs to know is in the documentation already, coding language agnostic.

⤋ Read More
In-reply-to » @andros maybe create a separate, completely distinct feed for DM? That way, clients do not need to do anything, only those wanted to "talk in private" follow themselves, using their very special dm-only.txt feeds. šŸ˜‚

@bender@twtxt.net @aelaraji@aelaraji.com The client should ignore twts if it’s not compatible or not addressed to me. it’s a simple regex to add! It’s similar to Twt Hash Extension, should they be in another file? They are child messages, not flat twt. Not of course!

⤋ Read More
In-reply-to » (#znf6csa) @prologic What happened here – did I edit my twt or is this hash wrong? 🄓

Doesn’t look like it Hmmm

sqlite> select * from twts where content LIKE '%Linux installation%';
    hash = znf6csa
feed_url = https://www.uninformativ.de/twtxt.txt
 content = I wonder if my current Linux installation will actually make it to 20 years:

    $ head -n 1 /var/log/pacman.log
    [2011-07-07 11:19] installed filesystem (2011.04-1)

It’s not toooo far into the future.

It would be crazy … 20 years without reinstalling once … phew. 🄓
 created = 2025-04-07T19:59:51Z
 subject = (#znf6csa)
mentions = []
    tags = []
   links = []

⤋ Read More