Searching We.Love.Privacy.Club

Twts matching #writing
Sort by: Newest, Oldest, Most Relevant
In-reply-to » @kat I've almost fixed this btw 🤗 Just testing it thoroughly and polihsing the code. In case you're curious, I do this style of development called "Observability Driven Development" (ODD) whereby I make observations of the system via metrics and internal observations and adjust the system's overall behavior to the desired outcome 😅

@lyse@lyse.isobeef.org Well you are being slightly rude 🤪 Sure you could write unit tests for this, but in practise testing emergent properties and behaviors of a system is actually a lot harder than you might realize. But I’m happy to always be proven wrong 😑

⤋ Read More

OSle: a tiny boot sector operating system
OSle is an incredibly small operating system, coming in at only 510 bytes, so it fits entirely into a boot sector. It runs in real-mode, and is written in assembly. Despite the small size, it has a shell, a read and write file system, process management, and more. It even has its own tiny SDK and some pre-built programs. The code’s available under the MIT license. ⌘ Read more

⤋ 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://we.loveprivacy.club/search?q=%23123467">#123467</a>) hello foo bar

you would have

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

or maybe even:

(<a href="https://we.loveprivacy.club/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

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.

⤋ Read More

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

⤋ Read More
In-reply-to » @sorenpeter you raw feed says otherwise. Also, https://txt.sour.is/conv/wj5bcwq.

@bender@twtxt.net Hehe good sleuthing 🤣 I swear it was an edit ✍️ Haha 😂 yarnd now “sees” both every single time, where-as before it would just obliterate the old Twt, but remain in archive. Now you get to see both 😅 Not sure if that’s a good thing or not, but it certainly makes it much clearer how to write “code logic” for detecting edits and doing something more UX(y) about ‘em 🤔

⤋ Read More