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
@prologic@twtxt.net pinging the involved (@andros@twtxt.andros.dev, @abucci@anthony.buc.ci, @eapl.me@eapl.me, @lyse@lyse.isobeef.org, @movq@www.uninformativ.de, @sorenpeter@darch.dk), just in case. I might have forgotten someone, please feel free to ping them.
We have 4 clients but this should be 6 I believe with tt2 from @lyse@lyse.isobeef.org and Twtxtory from @javivf@adn.org.es?
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
@prologic@twtxt.net Can you please draft up a specification for that proposed change with all the details? Such as which date do you actually refer to? Is it now() or the message’s creation timestamp? I reckon the latter is the case, but it’s undefined right now. Then we can discuss and potentially tweak the proposal.
Also, I see what you did there in regards to the reply model change poll. ]:->
@lyse@lyse.isobeef.org Yup! Will do 🤗
@prologic@twtxt.net 🚀🚀🚀🎉🎉🎉
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.
@eapl.me@eapl.me I honestly believe you are overreacting here a little bit 🤣 I completely emphasize with you, it can be pretty tough to feel part of a community at times and run a project with a kind of “democracy” or “vote by committee”. But one thing that life has taught me about open source projects and especially decentralised ecosystems is that this doesn’t really work.
It isn’t that I’ve not considered all the other options on the table (which can still be), it’s just that I’ve made a decision as the project lead that largely helped trigger a rebirth of the use of Twtxt back in July 1 2020. There are good reasons not to change the threading model right now, as the changes being proposed are quite disruptive and don’t consider all the possible things that could go wrong.
I also fundamentally do not believe in the notion that Twtxt should be readable and writable by humans. We’ve thrown this “argument” around in support of some of the proposals, and I just don’t buy it (sorry). As an analogy, nobody writes Email by hand and transmits them to mail servers vai SMTP by hand. We use tools to do this. Twtxt/Yarn should be the same IMO.
I’m with @andros@twtxt.andros.dev and @eapl.me@eapl.me on this one. But I have also lost interest in twtxt lately and currently rethinking what digital tools truly add value to my life. So I will not spending my time on adding more complexity to Timeline. Still a big thanks to you @prologic@twtxt.net for all the great work you have done and all the nice conversations both here and on our video calls.
@sorenpeter@darch.dk You’re welcome 🤗 We’ll run into each other again. I’m sure! 🤞
@andros@twtxt.andros.dev @eapl.me@eapl.me @sorenpeter@darch.dk Sad to see you go. 🫤
@movq@www.uninformativ.de I didn’t say I was leaving, just not that active here atm. I might be more active on mastodon at https://norrebro.space/@sorenpeter but I’m also rethinking that too tbh.