@prologic@twtxt.net I wanted to wait for things to settle down. It’s still unclear to me in which direction we’re going – and if that new/different stuff is even possible to implement in jenny. That said, I’ve been really busy with private stuff these last few days, I’ve lost track of most of what you’re discussing. 🥴

@movq@www.uninformativ.de sorry to hear about your personal things going on. 🤗

@prologic@twtxt.net why sorry? For all we know @movq@www.uninformativ.de won the lottery, and is retiring in Tasmania. :-P

@bender@twtxt.net Oh I hope that is true 🤣

I’d also appreciate if somebody wrote a proposal. It’s very hard to piece everything together across all those many conversations.

@lyse@lyse.isobeef.org I agree. Yet, even with a proposal, it is hard to finally agree to something, because it is not about developing a unique, sole client, but agreeing on a set of “standards” to be used on a handful(?) of clients, make by different people.

Using Mastodon as a—albeit poorly—contrast, they set their road-map, and clients (even other server implementations!) that want to cater/communicate with it using similar APIs will have to adjust. No other way. That doesn’t apply to twtxt.

I think the incremental changes that have been made to twtxt happened kind of slowly for that reason.

@bender@twtxt.net Yes, a proposal alone is certainly not enough, but a good start. Absolutely necessary in my opinion. With everything just in thin air and constantly changing (at least it appears to me that way), I’m lost.

I have the feeling that the hashing part is the most important one that should be sorted first.

@lyse@lyse.isobeef.org I think the proposal should be as simple as this:

• Update the Twt Hash extension.
  
• Increase its truncation from 7 to 12
  

@xuu@txt.sour.is is right about quite a few things, and I’d love it if he wrote up the dynamic hash size proposal, but I’m inclined to just increase the length in the first place mostly because my own client yarnd doesn’t even store the full hashes in the first place 🤦‍♂️ (I thinnk)

I share I did write up an algorithm for it at some point I think it is lost in a git comment someplace. I’ll put together a pseudo/go code this week.

Super simple:

Making a reply:

1. If yarn has one use that. (Maybe do collision check?)
   
2. Make hash of twt raw no truncation.
   
3. Check local cache for shortest without collision
   
   • in SQL: select len(subject) where head_full_hash like subject || '%'
     

Threading:

1. Get full hash of head twt
   
2. Search for twts
   
   • in SQL: head_full_hash like subject || '%' and created_on > head_timestamp
     

The assumption being replies will be for the most recent head. If replying to an older one it will use a longer hash.