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)

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 >.<

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

Image

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

Video

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

test post please ignore