Hmmmm the AoC site is not mobile friendly 😢 Can someone post the puzzles as Twts? 🤣

@lyse@lyse.isobeef.org Damn. That was stupid of me. I should have posted examples using 2026-03-01 as cutoff date. 😂

In my actual test suite, everything uses 2027-01-01 and then I have this, hoping that that’s good enough. 🥴

def test_rollover():
    d = jenny.HASHV2_CUTOFF_DATE
    assert len(jenny.make_twt_hash(URL, d - timedelta(days=7), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d - timedelta(seconds=3), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d - timedelta(seconds=2), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d - timedelta(seconds=1), TEXT)) == 7
    assert len(jenny.make_twt_hash(URL, d, TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(seconds=1), TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(seconds=2), TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(seconds=3), TEXT)) == 12
    assert len(jenny.make_twt_hash(URL, d + timedelta(days=7), TEXT)) == 12

(In other words, I don’t care as long as it’s before 2027-01-01. 😏😅)

@shinyoukai@neko.laidback.moe What do you mean by that? 🧐 Clients don’t care about the order of twts in a feed. For display clients usually sort by timestamp.

Oh my god! 🤣 It works! 🥳 My first Twt into the Fediverse (stil some improvements to be made of course), but still 😳 Wow! 🤩

The funny thing is, Yarn moving to Twt Hash v2 sounds a tad more optimistic than Git adopting SHA-256.

Git is several years too late, while Yarn is pretty much on time.

All my newly added test cases failed, that movq thankfully provided in https://git.mills.io/yarnsocial/twtxt.dev/pulls/28#issuecomment-20801 for the draft of the twt hash v2 extension. The first error was easy to see in the diff. The hashes were way too long. You’ve already guessed it, I had cut the hash from the twelfth character towards the end instead of taking the first twelve characters: hash[12:] instead of hash[:12].

After fixing this rookie mistake, the tests still all failed. Hmmm. Did I still cut the wrong twelve characters? :-? I even checked the Go reference implementation in the document itself. But it read basically the same as mine. Strange, what the heck is going on here?

Turns out that my vim replacements to transform the Python code into Go code butchered all the URLs. ;-) The order of operations matters. I first replaced the equals with colons for the subtest struct fields and then wanted to transform the RFC 3339 timestamp strings to time.Date(…) calls. So, I replaced the colons in the time with commas and spaces. Hence, my URLs then also all read https, //example.com/twtxt.txt.

But that was it. All test green. \o/

Hmmm, looks like my twt hash algorithm implementation calculates incorrect values. Might be the tilde in the URL that throws something off. :-? At least yarnd and jenny agree on a different hash.

@tilde.club@tilde.club unwritten etiquette (by me, and for me, but one can hope, right?).

• Proper grammar (in any language).
  
• Correct capitalisation, and punctuation.
  
• Subject extension support.
  

Anything else doesn’t matter. ☺️

@bender@twtxt.net You are totally correct! The thing is: The Caveman within was thinking how minimal can one go before things start to get too uncomfortable? And if cavemen weren’t supposed to be too self-conscious about their spelling, I could have just ssh remote echo "$(date -Is)\tTwt Twt Mother-Lover! 🤣🤣" >> /path/to/twtxt.txt and called it a day.

@aelaraji@aelaraji.com yeah, it looks tedious because it is. LOL. I can twt no matter where I am because a) with Yarn is as easy as opening a web browser, and b) with jenny is as easy at SSHing to my VPS. But, the keyword is fun. That’s what matters!

Just typing twts directly into my twtxt file.

Details:

• Opening my twtxt file remotely using vim scp://user@remote:port//path/to/twtxt.txt
  
• Inserting the date, time and tab part of the twt with :.!echo "$(date -Is)\t"
  
• In case I need to add a new line I just Ctrl+Shift+u, type in the 2028 and hit Enter
  
• In order to replay, you just steal a twt hash from your favorite Yarn instance.
  

It looks tedious, but it’s fun to know I can twt no matter where I am, as long as can ssh in.

Holly! I thing I might have figured out a way to twt like a true caveman 🤣
The sad thing tho is this caveman will have to cheat a bit in order to replay properly…
(P.S: I hope the multi-lines trick works, if not then F..rog it!)

@bender@twtxt.net The first format use the subject extension while the other is a new format that is inspired by mentions format, the first one should be compatible but I’m not sure, if it’s used verbatim by the client it would work, but if we consider the new proposal for it to have an optional part it wont work on clients without changes.

I finally solved the loading issue in my WIP reader, TwtStrm (and apologies again to anyone that got spammed while I was diagnosing the issue).

After another round of coding this weekend, I’m happy to report that it now renders all the twts (with markdown parsing), complete with localstorage and server-based file caching.

I meant, “jlj”. He used to be at https://twt.nfld.uk/, long gone now too. I wonder…

@alexonit@twtxt.alessandrocutolo.it Yeah I think we’re overstating the UNIX principles a bit here 🤣 I get what you’re trying to say though @zvava@twtxt.net 😅 If I could go back in time and do it all over again, I would have gotten the Hash length correct and I would have used SHA-256 instead. But someone way smarter than me designed the Twt Hash spec, we adopted it and well here we are today, it works™ 😅

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable twts whilst keeping a unique id for twts that is universal across all pods

plus, if hashv2 was implemented in combination with text fragments the way you proposed that would solve both scripting and human readability woes!!

…though, the presence of the text fragments then makes reversing the replied-to twt (and therefore its hash) trivial, which could allow clients to tolerate the omission of the hash — and while it would be ‘non-standard’ this would be the best of both worlds; potential to tolerate (or pave a glacial path toward? :o) human writable replies whilst keeping a unique id for twts that is universal across all pods

@zvava@twtxt.net Going to have to hard disagree here I’m sorry. a) no-one reads the raw/plain twtxt.txt files, the only time you do is to debug something, or have a stick beak at the comments which most clients will strip out and ignore and b) I’m sorry you’ve completely lost me! I’m old enough to pre-date before Linux became popular, so I’m not sure what UNIX principles you think are being broken or violated by having a Twt Subject (Subject) whose contents is a cryptographic content-addressable hash of the “thing”™ you’re replying to and forming a chain of other replies (a thread).

I’m sorry, but the simplest thing to do is to make the smallest number of changes to the Spec as possible and all agree on a “Magic Date” for which our clients use the modified function(s).

I finally resolved my issues with hashing twts… with REGEX!

Dates in JavaScript are truly strange creatures.

@bender@twtxt.net Thanks for asking!

So, I’ve been working on 2 main twtxt-related projects.

The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I’ve been testing it on my site since the night I made that post. It’s still very much an MVP, and I’ve been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).

But that’s where I’ve been struggling. The idea seems simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the “follow” list, grabs (and parses) those twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I’ll figure it out eventually, but for now, I’ve been spending far more time than I anticipated just trying to get it to work end-to-end.

On top of it, the 2 projects wound up turning into 4 (so far), as I’ve been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).

In the end, I’m hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we’ll see.

I hope this has satisfied your curiosity, but if you’d like to know more, please reach out!

@bender@twtxt.net Thanks for asking!

So, I’ve been working on 2 main twtxt-related projects.

The first is small Node / express application that serves up a twtxt file while allowing its owner to add twts to it (or edit it outright), and I’ve been testing it on my site since the night I made that post. It’s still very much an MVP, and I’ve been intermittently adding features, improving security, and streamlining the code, with an eye to release it after I get an MVP done of project #2 (the reader).

But that’s where I’ve been struggling. The idea seems simple enough - another Node / express app (this one with a Vite-powered front-end) that reads a public twtxt file, parses the “follow” list, grabs (and parses) those twtxt files, and then creates a river of twts out of the result. The pieces work fine in seclusion (and with dummy data), but I keep running into weird issues when reading real-live twtxt files, so some twts come through, while others get lost in the ether. I’ll figure it out eventually, but for now, I’ve been spending far more time than I anticipated just trying to get it to work end-to-end.

On top of it, the 2 projects wound up turning into 4 (so far), as I’ve been spinning out little libraries to use across both apps (like https://jsr.io/@itsericwoodward/fluent-dom-esm, and a forthcoming twtxt helper library).

In the end, I’m hoping to have project 1 (the editor) into beta by the end of October, and project 2 (the reader) into beta sometime after that, but we’ll see.

I hope this has satisfied your curiosity, but if you’d like to know more, please reach out!

Nothing serious! just a sanity check Twt x) ...

@kat@yarn.girlonthemoon.xyz Mine shows 1/1 of 14 Twts 😆 I think this is a bug 🤯

whyyyyy is my discover page only showing 7 twts!!!

@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

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

@lyse@lyse.isobeef.org retwts are a discovery feature! on federated platforms with no algorithm where you only ever see posts from accounts you explicitly follow, the element of “hey look at this!” helps users to find other accounts they might like organically

i agree quoting and replying forum-style is generally a much better way of doing things even though im a heathen and i revel in the dark patterns inspired by quote posts but when you have nothing to add and you just want to share a twt with your followers it’d be good to have a standardized way of linking to twt

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

Oops, maybe I should have posted a reminder. 🥴

@dce@hashnix.club By the time you posted your twt, the red phase was already over. 🙈 Stellarium has a pretty good simulation of the whole thing.

Yesterday, I published my first package on JSR: https://jsr.io/@itsericwoodward/fluent-dom-esm.

Then today, I pushed an update to my site to show my twts (including a schnazzy little animation to add them): https://itsericwoodward.com/

Overall, a most productive weekend.

Yesterday, I published my first package on JSR: https://jsr.io/@itsericwoodward/fluent-dom-esm.

Then today, I pushed an update to my site to show my twts (including a schnazzy little animation to add them): https://itsericwoodward.com/

Overall, a most productive weekend.

@kat@yarn.girlonthemoon.xyz i wanna catch up on the twts!!!

ugh my TL’s once again doing the thing where it only shows like 5 twts

Looks like here’s something wrong with Markdown parsing. 🤔 The original twt looks like this:

>This extension was turned off because it is no longer supported

Thanks Google.
This browser was uninstalled because it absolutely sucks!

So only the first line should be a quote.

PSA: setpriv on Linux supports Landlock.

If this twt goes through, then restricting the filesystem so that jenny can only write to ~/Mail/twt, ~/www/twtxt.txt, ~/.jenny-cache, and /tmp works.

@bender@twtxt.net @aelaraji@aelaraji.com Sorry this was my fault 🤦 For whatever reason my pod had never seen that particular Twt from @movq@www.uninformativ.de – And… There’s a bit of a “behavioral” problem with the Trusted Peers functionality that means operators have to periodically re-trust peers manually 😭 Need to rework this 🤞

@bender@twtxt.net Can’t you see this twt ??

() @aelaraji@aelaraji.com I am missing the root for this twtxt. What was it? Hmm, referring to https://twtxt.net/twt/g5sjnlq.

hey @prologic@twtxt.net heads up - my pod is suddenly having weird 400 bad request errors on things like posting twts, new user registration, following, and more. it’s not just me because a friend is also having these issues as a new user and can’t post. i saw one exception in the logs but i’m not sure if it’s related, i’ll link it in a reply to this

bruh i log in after a day and my TL/discover feed has 12 twts WHAT AM I MISSING

a twt a day keeps the doctor away…

@prologic@twtxt.net i will try my best if it happens again! it seems it goes in and out and things eventually come back - i just logged on this morning and i do see new twts but not past ones. so when it happens again and i notice i’ll try to trace logs

whys my feed back to showing like 5 twts

I’m also thinking of adding eye-off icon next to every Twt that, when clicked, hides that feed (tooltip: “Hide this feed”). This would work with the filters as a “temporary additive filter” to restrict/control the current view.

I’m thinking of bringing back filters (this time not as a feature flag, just baked in): New filters: Hide Feed, Hide Bots, Hide News, Media Only, No Replies, Local Only — toggle to trim noise & surface the Twts you care about.

last night my timeline randomly reset to only show my own recent twts and i restarted my instance a few times and pulled from main and shit and it didn’t change but it seems fine now lol?!

In other words, why didn’t you all do the same that @movq@www.uninformativ.de did, and setup a completely different feed for this?

But Yarn does not like it: https://twtxt.net/twt/yoatzwa

I’ve just released version 1.0 of twtxt.el (the Emacs client), the stable and final version with the current extensions. I’ll let the community maintain it, if there are interested in using it. I will also be open to fix small bugs.
I don’t know if this twt is a goodbye or a see you later. Maybe I will never come back, or maybe I will post a new twt this afternoon. But it’s always important to be grateful. Thanks to @prologic@twtxt.net @movq@www.uninformativ.de @eapl.me@eapl.me @bender@twtxt.net @aelaraji@aelaraji.com @arne@uplegger.eu @david@collantes.us @lyse@lyse.isobeef.org @doesnm@doesnm.p.psf.lt @xuu@txt.sour.is @sorenpeter@darch.dk for everything you have taught me. I’ve learned a lot about #twtxt, HTTP and working in community. It has been a fantastic adventure!
What will become of me? I have created a twtxt fork called Texudus (https://texudus.readthedocs.io/). I want to continue learning on my own without the legacy limitations or technologies that implement twtxt. It’s not a replacement for any technology, it’s just my own little lab. I have also made a fork of my own client and will be focusing on it for a while. I don’t expect anyone to use it, but feedback is always welcome.
Best regards to everyone.
#twtxt #emacs #twtxt-el #texudus