@benderso..here is where the roadmap is at right now lol. the prototype itself is solid i could just be doing everything wayyy better

@bender @thecanine hoping for this to backfire and have shizuku or something like it to become way more popular, as it utilizes adb which is excluded from this "advanced workflow"

@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

@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)))

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

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

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

@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)

@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

@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

@alexonit i dont think display_name is worthwhile, since nick is functionally a display name

@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)

@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

@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

@alexonit prologic has me sold on the idea of hashv2 being served alongside a text fragment, eg. (<a href="?search=abcdefghijkl" class="tag">#abcdefghijkl</a> 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 bbycll, whenever it is ready, in the meantime you're already on a pretty good one :3

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

@alexonit terrariums are so cool but i couldn't even keep grass from the back yard in a jar alive </3

@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

@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

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

@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

@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

@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

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

@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

@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

@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)

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

@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

@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

@bender just a heads up im thinking of rewriting the database schema with hash v2 in mind >.<

@lyse the problem is that i can not easily show both

@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

@prologic wife is awesome 🙇‍♀️

@kat i think almost all of the code was written between 10pm-10am :3c

@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

@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!

@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

@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

@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

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

@kat thank you!!!! just wait until you see what i have cooking :3

@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

@bender ..if you read the post you would see those are the next planned steps, yes

test reply please ignore

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

@prologic hiiii o/