2026-07-15T04:31:11Z (
zvava@twtxt.net )
accidentally just pasted my twtxt.net password in the compose field
2026-03-24T22:40:03Z (
zvava@twtxt.net )
(#pxsba2q) @benderso..here is where the roadmap is at right now lol. the prototype itself is solid i could just be doing everything wayyy better 
2026-03-23T23:00:19Z (
zvava@twtxt.net )
(#qy6xk5q) @bender@thecanine hoping for this to backfire and have [shizuku](https://github.com/RikkaApps/Shizuku) or something like it to become way more popular, as it utilizes adb which is excluded from this "advanced workflow"
2026-03-23T22:50:44Z (
zvava@twtxt.net )
women>>>>>>
2026-01-08T19:59:26Z (
zvava@twtxt.net )
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-01-06T18:58:01Z (
zvava@twtxt.net )
2026 will be the year of twtxt
2025-12-29T02:14:11Z (
zvava@twtxt.net )
(#o3hv4aq) @lyse 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
2025-12-23T18:48:04Z (
zvava@twtxt.net )
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.](https://functional.computer/blog/the-cardinal-sin-of-software-architecture)
2025-12-10T04:30:12Z (
zvava@twtxt.net )
(#jwv5raq) @prologic@movq 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)))
2025-12-10T04:04:48Z (
zvava@twtxt.net )
(#gzed7ua) 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 
2025-12-10T00:48:17Z (
zvava@twtxt.net )
my MIND is a MACHINE that turns ILLEGIBLE CODE into ILLEGIBLE CODE 
2025-12-09T23:42:45Z (
zvava@twtxt.net )
(#25s22ka) @bender on the way o7 spent enough time away from the codebase
2025-12-09T23:22:31Z (
zvava@twtxt.net )
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
2025-12-09T23:20:48Z (
zvava@twtxt.net )
yarn stop logging me out challenge (impossible)
2025-11-26T19:32:21Z (
zvava@twtxt.net )
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 ^^'
2025-11-03T20:47:05Z (
zvava@twtxt.net )
(#mjqmz5q) 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
2025-11-03T20:41:19Z (
zvava@twtxt.net )
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 
2025-10-04T18:46:35Z (
zvava@twtxt.net )
(#uh5p56q) @bender@alexonit 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)
2025-10-04T18:40:53Z (
zvava@twtxt.net )
(#lzt3dea) @prologic 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
2025-10-04T07:47:49Z (
zvava@twtxt.net )
(#cityvxa) @itsericwoodward@bender 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
2025-10-03T00:41:31Z (
zvava@twtxt.net )
(#x4s4mla) @alexonit i dont think `display_name` is worthwhile, since `nick` is functionally a display name
2025-10-01T17:53:40Z (
zvava@twtxt.net )
(#2kiw2vq) @lyse 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)
2025-10-01T17:48:52Z (
zvava@twtxt.net )
(#3sqf67q) @bender 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
2025-10-01T17:47:25Z (
zvava@twtxt.net )
(#lolhvka) @movq 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
2025-10-01T09:39:40Z (
zvava@twtxt.net )
(#xrswtvq) @alexonit 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)
2025-10-01T09:13:27Z (
zvava@twtxt.net )
(#fyipgsq) @rnlog bbycll, whenever it is ready, in the meantime you're already on a pretty good one :3
2025-10-01T08:41:46Z (
zvava@twtxt.net )
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)
2025-09-30T23:15:48Z (
zvava@twtxt.net )
(#qz7eeeq) frontend developer who keeps getting sidetracked doing frontend things instead of fixing the backend :p
2025-09-30T18:14:52Z (
zvava@twtxt.net )
(#hom6ofa) @alexonit terrariums are so cool but i couldn't even keep grass from the back yard in a jar alive </3
2025-09-30T18:13:34Z (
zvava@twtxt.net )
im just a poor frontend developer qwq
2025-09-30T17:58:35Z (
zvava@twtxt.net )
(#dekbu6q) @alexonit 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
2025-09-29T19:44:35Z (
zvava@twtxt.net )
(#dekbu6q) @alexonit 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
2025-09-26T07:47:30Z (
zvava@twtxt.net )
(#rsrlmzq) 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
2025-09-26T07:40:43Z (
zvava@twtxt.net )
(#rsrlmzq) @prologic 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
2025-09-26T06:04:33Z (
zvava@twtxt.net )
2025-09-26T05:42:05Z (
zvava@twtxt.net )
(#rsrlmzq) @prologic 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
2025-09-22T05:52:00Z (
zvava@twtxt.net )
(#altkl2a) @alexonit@lyse 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
2025-09-17T23:29:47Z (
zvava@twtxt.net )
(#z2kexzq) @bender `https://andros.dev/texudus.txt`, its url doesn't correspond to the feed either
2025-09-17T20:14:59Z (
zvava@twtxt.net )
(#fzmmn2q) @lyse@movq 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
2025-09-17T18:07:01Z (
zvava@twtxt.net )
is there consensus on what characters should(n't) be allowed in `nick`s? 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?
2025-09-15T22:41:38Z (
zvava@twtxt.net )
(#nzs23fa) @lyse 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
2025-09-15T22:26:46Z (
zvava@twtxt.net )
(#jdhwlna) @bender@thecanine 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)
2025-09-15T22:13:56Z (
zvava@twtxt.net )
(#jpmgraa) @bender yeah i've noticed yarn being very strange with edits, deletes haven't worked since i joined here
2025-09-15T22:12:36Z (
zvava@twtxt.net )
(#34thtfq) @quark 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
2025-09-15T11:53:30Z (
zvava@twtxt.net )
mobile navigation bar :3 
2025-09-15T01:20:25Z (
zvava@twtxt.net )
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 >.<
2025-09-15T00:36:38Z (
zvava@twtxt.net )
(#zqxcq3a) @prologic 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
2025-09-14T20:21:42Z (
zvava@twtxt.net )
(#wwnhgva) @bender just a heads up im thinking of rewriting the database schema with hash v2 in mind >.<
2025-09-14T19:58:07Z (
zvava@twtxt.net )
(#tm3naga) @lyse the problem is that i can not easily show both
2025-09-14T03:52:35Z (
zvava@twtxt.net )
it's so satisfying clicking refresh and watching new posts appear 🥺
2025-09-14T03:34:56Z (
zvava@twtxt.net )
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
2025-09-14T03:21:00Z (
zvava@twtxt.net )
(#6ishh6q) @prologic i just added timeline refresh to bbycll and it is so convincing i almost replied to you from there hehe, can i get a link pretty please :o
2025-09-14T02:19:37Z (
zvava@twtxt.net )
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** 
2025-09-13T23:02:02Z (
zvava@twtxt.net )
(#eyswcaa) @prologic wife is awesome 🙇♀️
2025-09-12T20:03:22Z (
zvava@twtxt.net )
(#uocyl3q) @kat i think almost all of the code was written between 10pm-10am :3c
2025-09-12T02:14:12Z (
zvava@twtxt.net )
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 
2025-09-12T01:46:37Z (
zvava@twtxt.net )
future sophia is going to have Fun cleaning up this mess
2025-09-12T01:42:03Z (
zvava@twtxt.net )
im a 1000x developer
2025-09-12T00:14:51Z (
zvava@twtxt.net )
> remote.json | 3.4MiB i hope testing this doesn't get me ip banned from Everything
2025-09-11T23:24:19Z (
zvava@twtxt.net )
(#yyuo34q) @bender ty for attempting to test, though, it means a lot! lmk if u find any more silly things i need to clarify or fix :> be prepared for everything breaking during beta :p
2025-09-11T23:22:22Z (
zvava@twtxt.net )
(#yyuo34q) @bender i also recently discovered there was a bug causing new users to initialize wrong leading to their posts not being saved :p ..and made breaking changes to how the config and database files are stored so um, make sure to clear your local tree before updating!
2025-09-11T23:14:32Z (
zvava@twtxt.net )
(#yyuo34q) @bender as the host (eg `twtxt.net`) determines the canonical url of the instance in generated feed `url` metadata as well as every hash of every post made on the instance internally, i added this error message to make sure people don't accidentally set up their instance on `localhost` :p for testing i set it to `localhost:31212` and protocols to `["http"]`, it's a recent addition that could definitely do with documenting in the getting started section
2025-09-11T15:58:58Z (
zvava@twtxt.net )
(#6atyjjq) @lyse 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
2025-09-11T15:43:55Z (
zvava@twtxt.net )
(#54p5ala) @bender@kat after implementing cws in bbycll (parsing them the way i described in op) i understand why `<details>` aren't rendered. firstly they're not actually markdown, and secondly they style weird — details are forced onto a new line as a block element but you can't make the `<summary>` inline because it is inside `<details>`, and making `<details>` inline will also indent everything inside it
2025-09-09T09:21:49Z (
zvava@twtxt.net )
(#z25erwq) in the same vein, i think content warnings can be faithfully implemented by parsing `CW: ...`, `tw // ...`, etc. from the first line of a post followed by two newlines, like how they're used on platforms that don't have content warnings
2025-09-09T05:54:11Z (
zvava@twtxt.net )
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
2025-09-08T03:31:59Z (
zvava@twtxt.net )
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 
2025-09-07T18:47:26Z (
zvava@twtxt.net )
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
2025-09-07T18:42:23Z (
zvava@twtxt.net )
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) 
2025-09-05T17:18:08Z (
zvava@twtxt.net )
i wish the mug didn't run out of coffee
2025-09-05T16:05:14Z (
zvava@twtxt.net )
(#wk6bxkq) @kat thank you!!!! just wait until you see what i have cooking :3
2025-09-05T16:04:56Z (
zvava@twtxt.net )
(#wk6bxkq) @lyse hihi ^^ i did that at first, but i personally i don't like it when websites don't let me change my password when i am already authenticated — fwiw you can view and log out other sessions, if that diminishes this attack vector at all
2025-09-04T17:35:39Z (
zvava@twtxt.net )
(#vwoezwq) @bender ..if you read the post you would see those are the next planned steps, yes
2025-09-04T16:30:45Z (
zvava@twtxt.net )
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 ^^' 
2025-09-03T00:10:42Z (
zvava@twtxt.net )
(#lqjftwa) test reply please ignore
2025-09-03T00:08:01Z (
zvava@twtxt.net )
test edit please ignore
2025-09-02T20:02:22Z (
zvava@twtxt.net )
really proud of how [bbycll](https://bbycll.zvava.org/) is coming along!! 
2025-09-02T14:10:01Z (
zvava@twtxt.net )
test post please ignore
2025-09-01T14:28:28Z (
zvava@twtxt.net )
(#sdu5kcq) @prologic haven't had too much time to really try it out yet ^^' i'm um too busy staring at code i wrote while sleep deprived and wondering why i did the things i did, while sleep deprived \@.@
2025-09-01T13:58:29Z (
zvava@twtxt.net )
(#sdu5kcq) @prologic hiiii o/