working on the bombycilla twtxt instance software! (right now i'm procrastinating by working on my notes app zinnia,, but i'm learning a lot about ways i can improve bbycll at least :3)
implemented curl, grep, jq, head & tail in javascript for my website, zsh now knows the difference between hi;hi and "hi;hi", and a bunch of documentation has been written for all that, too! i do normal people things for fun :3

very good blog post that reminded me why it's taking so long to ship bbycll — previously i had computed the hashes of every post before storing them in the database, after realizing it's a much better idea to compute the hashes during runtime and only store the post content & timestamp i'm now having to rewrite every function that reads & writes data. i hope the reason as to why i lost motivation is obvious — thankfully i caught it early enough so that once i'm done rewriting just those functions i should™ be able to finalize 1.0-rc with little hassle
my MIND is a MACHINE that turns ILLEGIBLE CODE into ILLEGIBLE CODE

i've learned a lot of lessons from writing my notes app, gonna apply this to bbycll and refactor the code to make it way more legible cause my custom templating system is only kind of a giant mess
since there are quite literally no note taking apps that work for me, i've began writing my own! to get started real quick i adapted the core part of bbycll's backend and it works so nicely — which speaks volumes to the quality of the code! should really break it out into a custom framework. i'm also realizing how easy it would be to get bbycll v1 ready...but this is probably more important since it'll allow me to get my life in order ^^'
sorry i haven't been working on bbycll or even hanging around twtxt much at all as of late -- gf was over for a few weeks, i turned twenty years old, and have been doing extremely unnecessary things to my website

is the first url metadata field unequivocally treated as the canon feed url when calculating hashes, or are they ignored if they're not at least proper urls? do you just tolerate it if they're impersonating someone else's feed, or pointing to something that isn't even a feed at all?
and if the first url metadata field changes, should it be logged with a time so we can still calculate hashes for old posts? or should it never be updated? (in the case of a pod, where the end user has no choice in how such events are treated) or do we redirect all the old hashes to the new ones (probably this, since it would be helpful for edits too)
is there consensus on what characters should(n't) be allowed in nicks? i remember reading somewhere whitespace should not be allowed, but i don't see it in the spec on twtxt.dev — in fact, are there any other resources on twtxt extensions outside of twtxt.dev?
wait why are so many of my post hashes not generating correctly ;w;
edit: i read the spec wrong :3 only +/-00:00 is stripped, not the entire timezone offset >.<
it's so satisfying clicking refresh and watching new posts appear 🥺
wait....so i'm like nearly done? it just works? and it's fast? this feels like the end of the first all-nighter i pulled where i just got post creation done, unaware of the three weeks that would follow — like looking at the roadmap i'm definitely not done but bbycll is like actually kind of usable now o.o
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

we are now parsing and recursively fetching remote feeds somewhat successfully, gotta work on the media proxy and markdown way more, so so many fucky edgecases....my friend's feed with like four posts parsed correctly so i tried this account's feed and well now im not going to bed on time
remote.json | 3.4MiB
i hope testing this doesn't get me ip banned from Everything
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
search page, bookmarks page, improved thread view (that i will probably improve further), as well as a logo and a whole ui redesign. it is truly all coming together...were i to mark any items off the roadmap :p
is there someone (ideally not in the opposite timezone to me) who'd be willing to let me bother them with technical questions abt twtxtv2 and/or yarn's inner workings? :3
beginnings of remote feed parsing..! the fact hashing just sort of works with the minuscule libraries i found for base32 and blake2b still amazes me (mentions are being eaten as html tags)

replies and following implemented! next step is further parsing of post contents, rendering threads, and then maybe i can finally start adding remote feeds...! though i kinda wanna redo the whole ui ^^'
Timeline Sandbox 
