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

And speaking of Twtxt (See: #xushlda, feeds should be treated as append-only. Your client(s) should be appending Twts to the bottom of the file. Edits should never modify the timestamp of the Twt being edited, nor should a Twt that was edited by deleted, unless you actually intended to delete it (but that's more complicated as it's very hard to control or tell clients what to do in a truely decentralised ecosystem for the deletion case). #Twtxt #Client #Recommendations

Just like we don't write emails by hand anymore (See: #a3adoka), we don’t manually write Twts or update our twtxt.txt feeds. Instead, we use modern Twtxt clients that conform to the specifications at Twtxt.dev for a seamless, automated experience. #Twtxt #Twt #UserExperience

Nobody writes emails by hand using RFC 5322 anymore, nor do we manually send them through telnet and SMTP commands. The days of crafting emails in raw format and dialing into servers are long gone. Modern email clients and services handle it all seamlessly in the background, making email easier than ever to send and receive—without needing to understand the protocols or formats behind it! #Email #SMTP #RFC #Automation

$ bat https://twtxt.net/twt/edgwjcq | jq '.subject'
""

hahahahaha 🤣 Does your client allow you to do this or what? 🤔

Interesting factoid... By inspecting my "followers" list every now and again, I can tell who uses a client like jenny, tt or any other client where fetches are driven by user interactions of invoking the app. What do we call this type of client? Hmmm 🤔 Then I can tell who uses yarnd because they are "seen" more frequently 🤣

💡 I had this crazy idea (or is it?) last night while thinking about Twtxt and Yarn.social 😅 There are two things I think that could be really useful additions to the yarnd UI/UX experience (for those that use it) and as "client" features (not spec changes). The two ideas are quite simple:

• Voting -- a way to cast, collect a vote on a decision, topic or opinion.
• RSVP -- a way to "rsvp" to a virtual (pr physical) event.

Both would use "plain text" on top of the way we already use Twtxt today and clients would render an appropriate UI/UX.