🧮 USERS:1 FEEDS:2 TWTS:1283 ARCHIVED:85598 CACHE:2694 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1282 ARCHIVED:85584 CACHE:2693 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1281 ARCHIVED:85547 CACHE:2670 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1280 ARCHIVED:85265 CACHE:2782 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1279 ARCHIVED:85261 CACHE:2781 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1278 ARCHIVED:85213 CACHE:2788 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1277 ARCHIVED:85199 CACHE:2783 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1276 ARCHIVED:85172 CACHE:2772 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1275 ARCHIVED:85157 CACHE:2789 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1274 ARCHIVED:85144 CACHE:2787 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1273 ARCHIVED:85134 CACHE:2796 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1272 ARCHIVED:85120 CACHE:2798 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1271 ARCHIVED:85113 CACHE:2793 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1270 ARCHIVED:85107 CACHE:2793 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1269 ARCHIVED:85097 CACHE:2793 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1268 ARCHIVED:85090 CACHE:2802 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1267 ARCHIVED:85061 CACHE:2808 FOLLOWERS:18 FOLLOWING:14

it seems to be confused with the subject right next to it.. it works better at the end of the twt string.
Yarn won’t display anything. but the parser does add it to the AST in a way that you can parse it out using twt.Attrs().Get("lang")

https://git.mills.io/yarnsocial/go-lextwt/src/branch/main/ast.go#L1270-L1272

https://git.mills.io/yarnsocial/go-types/src/branch/main/twt.go#L473-L478

🧮 USERS:1 FEEDS:2 TWTS:1266 ARCHIVED:85045 CACHE:2795 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1265 ARCHIVED:85028 CACHE:2815 FOLLOWERS:18 FOLLOWING:14

True. Though if the idea turns out to be better.. then community will adopt it.

if you look at the subject for that twt you will see that it uses the extended hash format to include a URL address.

🧮 USERS:1 FEEDS:2 TWTS:1264 ARCHIVED:85005 CACHE:2818 FOLLOWERS:18 FOLLOWING:14

@andros@twtxt.andros.dev Oh, this system has an edit button so I can just update the twt as needed. It’s a custom implementation so just kind of through it in when I was building it out.

🧮 USERS:1 FEEDS:2 TWTS:1263 ARCHIVED:84993 CACHE:2810 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1262 ARCHIVED:84977 CACHE:2801 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1261 ARCHIVED:84964 CACHE:2806 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1260 ARCHIVED:84955 CACHE:2806 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1259 ARCHIVED:84951 CACHE:2806 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1258 ARCHIVED:84933 CACHE:2792 FOLLOWERS:18 FOLLOWING:14

@andros@twtxt.andros.dev I believe you have just reproduced the bug… it looks like you’ve replayed to a twt but the hash is wrong. I can see the hash here from Jenny, but it doesn’t look like it corresponds to any{twt,thing}. if you check it out on any yarn instance it won’t look like a replay.

🧮 USERS:1 FEEDS:2 TWTS:1257 ARCHIVED:84925 CACHE:2797 FOLLOWERS:18 FOLLOWING:14

My hypothesis about that thing breaking my twts is that it might have something to do with the parenthesis surrounding the root twt hash in the replay twt-A when I replay to it with fork-twt-B; I imagine elisp interpreting those as a s-expression thus breaking the generation precess of hash (#twt-A) before prepending it to for-twt-B … but then I’m too ignorant to figure out how to test my theory (heck I couldn’t even recalculate the hashes myself correctly in bash xD). I’ll keep trying tho.

@andros@twtxt.andros.dev yes, that usually happens when twts get edited and we just made a gentlemen agreement to avoid edits as much as possible (at least for the time being). But the thing is, That is not what’s happening with my broken twts’ hashes. Since I’ve bee mostly replaying to my own twts as a test and I know for sure that I haven’t edited any. (I usually fork-replay instead of edit a twt when needed)

🧮 USERS:1 FEEDS:2 TWTS:1256 ARCHIVED:84916 CACHE:2808 FOLLOWERS:18 FOLLOWING:14

@prologic@twtxt.net Agreed! But clients can hallucinate and generate wrong hashes aka Lies 🤣 Also, If you chheck your own twt on twtxt.net, it looks like a root twt instead of a replay.

@andros@twtxt.andros.dev Here’s that twtxt-el test replay to my last twt! let’s see how it goes.

@andros@twtxt.andros.dev hmmm… pretty strange, isn’t it? replaying to threads worked perfectly, I’ve only had that problem trying to replay to a twt that was part of a thread.

As an example, this one is a Fork-Replay from Jenny. My next twt will be a replay to this exact twt but from twtxt-el as a test.
Then I’will file an issue if it doesn’t behave the way it’s supposed to. Cheers!

@prologic@twtxt.net Are you sure? xD … it was supposed to be a replay to another twt, but the twt hash is wrong (I think).

🧮 USERS:1 FEEDS:2 TWTS:1255 ARCHIVED:84884 CACHE:2780 FOLLOWERS:18 FOLLOWING:14

@andros@twtxt.andros.dev is it me or twtxt-el generates a wrong twt hash when I use the [ ↳ Reply to twt ] button?

🧮 USERS:1 FEEDS:2 TWTS:1254 ARCHIVED:84848 CACHE:2758 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1253 ARCHIVED:84833 CACHE:2744 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1252 ARCHIVED:84826 CACHE:2761 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1251 ARCHIVED:84810 CACHE:2762 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1250 ARCHIVED:84794 CACHE:2807 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1249 ARCHIVED:84784 CACHE:2804 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1248 ARCHIVED:84769 CACHE:2799 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1247 ARCHIVED:84694 CACHE:2775 FOLLOWERS:18 FOLLOWING:14

@prologic@twtxt.net the code block is the cause of https://txt.sour.is/twt/zn2kg7q

and the second? i get POST errors when i try to submit the webform.

🧮 USERS:1 FEEDS:2 TWTS:1246 ARCHIVED:84670 CACHE:2758 FOLLOWERS:18 FOLLOWING:14