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

2026 will be the year of twtxt

@lyse@lyse.isobeef.org while caching those is a good idea the problem is baking data that can be calculated into the database instead of some cache, because post hashes are not fixed and change for every post edit. you can always easily look up other twts by hash with a cached lookup table, but now you’re not locked into them so supporting hashv2 or other hash variants or any other solution becomes far easier

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

⇒ the cardinal sin of software architecture: the unnecessary distribution, replication, or restructuring of state, both in space and time.

@prologic@twtxt.net @movq@www.uninformativ.de h.265 is from 13 years ago and support is still incredibly spotty (though it being proprietary probably has a lot to do with that)

also see: jpegxl’s adoption (three or six years old depending how you quantify it) which afaik is mostly attributed to google deciding not to put it in chrome (though they changed their stance recently iirc (webp, of course, did not have this problem since it was pushed so hard by google (the browser wars never ended)))

really love this design language i borrowed from firefish/misskey v12, you can even select a bbycll theme in zinnia to make things even more confusing :3 though i myself somehow see past the similarities just knowing how different the codebases are

my MIND is a MACHINE that turns ILLEGIBLE CODE into ILLEGIBLE CODE

@bender@twtxt.net on the way o7  spent enough time away from the codebase

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

yarn stop logging me out challenge (impossible)

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 ^^’

don’t mind the glaring light mode i just think the pink looks pretty. this “desktop mode” is just a bunch of css repurposing the sidebar into the taskbar, but the file manager and its supporting code is proving a very fun endeavour. my favorite part is u can just turn javascript off and it functions like a regular website with nothing suspicious about it at all

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

@bender@twtxt.net @alexonit@twtxt.alessandrocutolo.it funnily enough i came up with the idea for a banner field when i started working on bbycll too (though i still need to implement avatar uploads themselves first)

@prologic@twtxt.net i’m guessing then a HEAD request is sent every 5m, and then the feed is fetched if the headers are different?

also what would be the cases where a feed would be fetched more than every five minutes? :o

@itsericwoodward@itsericwoodward.com @bender@twtxt.net this is vaguely concerning…does yarn refresh feeds every minute or two? or is there some special “notify twtxt.net to refresh my feed” that i don’t know about

@alexonit@twtxt.alessandrocutolo.it i dont think display_name is worthwhile, since nick is functionally a display name

@lyse@lyse.isobeef.org i would like to ditch hash addressing but as was pointed out it would be a pain in the ass to get clients currently working off of hashv1 to suddenly switch to location-based addressing instead of just hashv2 with the option to eventually phase it out — unless we can rally together all active client developers to decide on a location-based addressing specification (i still think my original suggestion of #<https://example.com/tw.txt#yyyy-mm-ddThh:mm:ssZ> is foolproof)

@bender@twtxt.net technically it’s still the same, but the brackets are different, and the # symbol is on the outside of the brackets, but it makes more sense with @<...> being mentions

@movq@www.uninformativ.de huh, firefox actually does seem to tolerate the dashes in the fragment. also, i did propose simply using an anchor link first, but prologic was not a fan of this :p

@alexonit@twtxt.alessandrocutolo.it prologic has me sold on the idea of hashv2 being served alongside a text fragment, eg. (#abcdefghijkl https://example.com/tw.txt#:~:text=2025-10-01T10:28:00Z), because it can be simply hacked in to clients currently on hashv1 and provides an off-ramp to location-based addressing (though i still think the format should be changed to smth like #<abc... http://example.com/...> so it’s cleaner once we finally drop hashes)

@rnlog@yarn.girlonthemoon.xyz bbycll, whenever it is ready, in the meantime you’re already on a pretty good one :3

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)

frontend developer who keeps getting sidetracked doing frontend things instead of fixing the backend :p

@alexonit@twtxt.alessandrocutolo.it terrariums are so cool but i couldn’t even keep grass from the back yard in a jar alive

im just a poor frontend developer qwq

i desperately want to simply deploy a bbycll instance but i need to change the entire database schema for the Nth time, i haven’t been working on it much recently as this back and forth w the backend (which you don’t expect from a spec as simple as twtxt) is really demotivating, as well as life and stuff getting in the way

perhaps i just need a nice shower and four coffees, midnight is when i am most productive and the hour is approaching..

@alexonit@twtxt.alessandrocutolo.it yeah, i didn’t even consider this as an option lol, though if it works it works! will you be writing a compatible proxy for self-hosting separate from the custom backend you were thinking of? :o

@alexonit@twtxt.alessandrocutolo.it i tried making a webapp initially but i didn’t even get into the initial stages of testing because no one sets the Access-Control-Allow-Origin header, so i just jumped into building a backend instead. did you find away around this limitation? :o

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

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

@prologic@twtxt.net to clarify: i meant the ability to parse feeds using unix command line utilities, as a principal of twtxtv1’s design. im not sure how feasible it is to build a simple feed reader out of common scripting utilities when hashing is in play, and;

i concede, it does make a lot of sense to fix up the hashing spec rather than completely supplant it at this point, just thinking about what the rewrite would be like is dreadful in and of itself x.x

@prologic@twtxt.net to clarify the i meant the ability to parse feeds using unix command line utilities, as a prinicpal of twtxtv1’s design. im not sure how feasible it is to build a simple feed reader out of common scripting utilities when hashing is in play, and;

i concede, it does make a lot of sense to fix up the hashing spec rather than completely supplant it at this point, just thinking about what the rewrite would be like is dreadful in and of itself x.x

@prologic@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3 while i agree hashes are incredibly helpful in the backend im not sure it has a place outside of it, it basically eliminates two core design principals of twtxt (human readability and integrating well with unix command line utilities) and makes new clients more difficult to build than it should be

@prologic@twtxt.net the simplest thing to do is to completely forgo hashing anything because we are communicating using plain text files right now :3

@alexonit@twtxt.alessandrocutolo.it @lyse@lyse.isobeef.org i really don’t understand why this was not the solution in the first place, given how simple twtxt is (mean to be), a reply should be as simple as #<https://example.com/twtxt.txt#2025-09-22T06:45Z> with the timestamp in an anchor link. the need for a mention is avoided like this as well since it’s already linking to the replied-to feed!

🐀💭 i should just implement it into bbycll and force it into existence

@bender@twtxt.net https://andros.dev/texudus.txt, its url doesn’t correspond to the feed either

@lyse@lyse.isobeef.org @movq@www.uninformativ.de bbycll’s nickname regex is /^([-_\p{N}\p{L}])+$/iu because i don’t like how english-centric only allowing ascii letters/numbers is though this only applies to local users as of now, currently all nicknames are tolerated when parsing remote feeds and i just do mentions how yarn does (just the feed url)

in the wild, i’ve noticed a texedus feed with spaces in the nick (where its spec explicitly disallows whitespace in the nick) and feeds with other symbols in the nick too. honestly, i think we should just tolerate arbitrary nicknames for sake of user expression (while stripping or converting unreasonable characters) and just leave them out of mentions

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?

@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

@bender@twtxt.net @thecanine@twtxt.net well now this has me thinking abt the feasibility of making an android twtxt app for pods, the actual apis of pods would have to be standardized (or a fucked up version of how activitypub does it, where the “mastodon api” is the defacto client api (does yarn even have an api reference?)) or the client is just simply..a client..but editing feeds via PUT, PATCH, DELETE etc. is standardized!…? (not to mention i dont even know where to begin making an android app lmao)

@bender@twtxt.net @thecanine@twtxt.net well now this has me thinking abt the feasibility of making an android twtxt app for pods, the actual apis of pods would have to be standardized (or the fucked up way that activitypub does it, where the “mastodon api” is the defacto client api (does yarn even have an api reference?)) or the client is just simply..a client..but editing feeds via PUT, PATCH, DELETE etc. is standardized!…? (not to mention i dont even know where to begin making an android app lmao)

@bender@twtxt.net yeah i’ve noticed yarn being very strange with edits, deletes haven’t worked since i joined here

@quark@ferengi.one ooh, thanks for catching that! i forgot abt the caddy example when adding the config example

nick is nick bc it is parsed as a nickname just for the instance, though calling it instance_nick would probably be less confusing

mobile navigation bar :3

im unable to figure out why bbycll is not generating posts hashes for @lyse@lyse.isobeef.org’s feed correctly (or at least different from the ones generated by yarn)

i’m pretty sure the timezone is stripped off the offset correctly (2025-09-14T12:45:00+02:00 → 2025-09-14T12:45:00Z) though messing with how the hash is generated i can’t get it to make one that matches…but all other hashes for all other feeds seem to be correct? does yarn use a different canonical url for lyse internally? is there a bug in the libraries im using? bwehhh

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 why are so many of my post hashes not generating correctly ;w;

@prologic@twtxt.net im unsure how i feel about the hash v2 proposal, given it is completely backward incompatible with hash v1 it doesn’t really solve any of the problems with it. it only delays collisions, and still fragments threads on post edits

i skimmed through discussions under other the proposals — i agree humans are very bad at keeping the integrity of the web in tact, but hashes in done in this way make it impossible even for systems to rebuild threads if any post edits have occurred prior to their deployment