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

mobile navigation bar :3

Image

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

@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

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

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

Video

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

edit: remaking demo video

@lyse@lyse.isobeef.org 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

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

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

i wish the mug didn’t run out of coffee

@lyse@lyse.isobeef.org 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@twtxt.net ..if you read the post you would see those are the next planned steps, yes

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

Video

really proud of how bbycll is coming along!!

Video

test post please ignore