🧮 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

@prologic@twtxt.net We can’t agree on this idea because that makes things even more complicated than it already is today. The beauty of twtxt is, you put one file on your server, done. One. Not five million. Granted, there might be archive feeds, so it might be already a bit more, but still faaaaaaar less than one file per message.

Also, you would need to host not your own hash files, but everybody else’s as well you follow. Otherwise, what is that supposed to achieve? If people are already following my feed, they know what hashes I have, so this is to no use of them (unless they want to look up a message from an archive feed and don’t process them). But the far more common scenario is that an unknown hash originates from a feed that they have not subscribed to.

Additionally, yarnd’s URL schema would then also break, because https://twtxt.net/twt/<hash> now becomes https://twtxt.net/user/prologic/<hash>, https://twtxt.net/user/bender/<hash> and so on. To me, that looks like you would only get hashes if they belonged to this particular user. Of course, you could define rules that if there is a /user/ part in the path, then use a different URL, but this complicates things even more.

Sorry, I don’t like that idea.

One of the biggest gripes of the community with the way the threading model currently works with Twtxt v1.2 (https://twtxt.dev) is this notion of:

What is this hash?
What does it refer to?

Idea: Why can’t we all agree to implement a simple URI scheme where we host our Twtxt feeds?

That is, if you host your feed at https://example.com/twtxt.txt – Why can’t or could you not also host various JSON files (let’s agree on the spec of course) at https://example.com/twt/<hash> ? 🤔

That way we solve this problem in a truly decentralised way, rather than every relying on yarnd pods alone.

🧮 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

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

lang=en @xuu@txt.sour.is gotcha!
From that PR #17 I think it was reverted? We could discuss about metadata later this month, as it seems that I’m the only person using it.

I’ve added a [lang=en] to this twt to see current yarn behaviour.

🧮 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

a few async ideas for later

The editing process needs a lot of consideration and compromises.

From one side, editing and deleting it’s necessary IMO. People will do it anyway, and personally I like to edit my texts, so I’d put some effort on make it work.
Should we keep a history of edits? Should we hash every edit to avoid abuse? Should we mark internally a twt as deleted, but keeping the replies?

I think that’s part of a more complete ‘thread’ extension, although I’d say it’s worth to agree on something reflecting the real usage in the wild, along with what people usually do on other platforms.

looks good to me!

About alice’s hash, using SHA256, I get 96473b4f or 96473B4F for the last 8 characters. I’ll add it as an implementation example.
The idea of including it besides the follow URL is to avoid calculating it every time we load the file (assuming the client did that correctly), and helps to track replies across the file with a simple search.

Also, watching your example I’m thinking now that instead of {url=96473B4F,id=1} which is ambiguous of which URL we are referring to, it could be something like:
{reply_to=[URL_HASH]_[TWT_ID]} / {reply_to=96473B4F_1}
That way, the ‘full twt ID’ could be 96473B4F_1.

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.

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

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

@bmallred@staystrong.run Any edit automatically changes the twt hash, because the hash is built over the hash URL, message timestamp and message text. https://twtxt.dev/exts/twt-hash.html So, it is only a problem, if somebody replied to your original message with the old hash. The original message suddenly doesn’t exist anymore and the reply becomes detached, orphaned, whatever you wanna call it. Threading doesn’t break, though, if nobody replied to your message.

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

I was on the hunt for new twts and found what I was looking for. Welcome to my timeline:
@javivf@adn.org.es @lafe@tilde.club @melyanna@tilde.club @nff@www.noizhardware.com @shreyan@twtxt.net

🧮 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

I really like the concept of “twt”. It’s the perfect blend of txt and twtxt. An abbreviated form. Even though it’s the name given to posts, I personally find it very nice.
#twtxt

I don’t think so, at least the tests I did passed. If you’re pretty sure it’s a bug, please create an issue in the repository with the specific case and I’ll investigate it.
There are 2 buttons to make replicas, one makes a replica in the thread where the twt is located (this is the one that should be used the most, as it serves a thread), the other creates a replica to a specific twt.
I’ll let you know a bit about the status: I’m just now implementing the thread screen. There you can be sure where you are. It’s a bit confusing right now, sorry. I think the client is still in alpha. When I’ve finished what I’m doing, and the direct message system, I’ll freeze development and focus on creating more tests, looking for bugs and making small visual adjustments.

@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

among these options, 3

Although I like it more “twt”, without the dot and with a t at the end

🧮 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

@prologic@twtxt.net Of course you don’t notice it when yarnd only shows at most the last n messages of a feed. As an example, check out mckinley’s message from 2023-01-09T22:42:37Z. It has “[Scheduled][Scheduled][Scheduled]“… in it. This text in square brackets is repeated numerous times. If you search his feed for closing square bracket followed by an opening square bracket (][) you will find a bunch more of these. It goes without question he never typed that in his feed. My client saves each twt hash I’ve explicitly marked read. A few days ago, I got plenty of apparently years old, yet suddenly unread messages. Each and every single one of them containing this repeated bracketed text thing. The only conclusion is that something messed up the feed again.

🧮 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

@eapl.me@eapl.me Yeah, you need some kind of storage for that. But chances are that there’s already a cache in place. Ideally, the client remembers etags or last modified timestamps in order to reduce unnecessary network traffic when fetching feeds over HTTP(S).

A newsreader without read flags would be totally useless to me. But I also do not subscribe to fire hose feeds, so maybe that’s a different story with these. I don’t know.

To me, filtering read messages out and only showing new messages is the obvious solution. No need for notifications in my opinion.

There are different approaches with read flags. Personally, I like to explicitly mark messages read or unread. This way, I can think about something and easily come back later to reply. Of course, marking messages read could also happen automatically. All decent mail clients I’ve used in my life offered even more advanced features, like delayed automatic marking.

All I can say is that I’m super happy with that for years. It works absolutely great for me. The only downside is that I see heaps of new, despite years old messages when a bug causes a feed to be incorrectly updated (https://twtxt.net/twt/tnsuifa). ;-)

Definitely something going on with replies. This one was replying to the wrong twt and even when I got clever and pasted the right hash it didn’t work.

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

@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

@mckinley@twtxt.net And there is the bracketed text duplication bug again… Actually with lots of twts. Did you edit a twt? Do you remember? /cc @prologic@twtxt.net

🧮 USERS:1 FEEDS:2 TWTS:1245 ARCHIVED:84640 CACHE:2798 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1244 ARCHIVED:84634 CACHE:2814 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1243 ARCHIVED:84633 CACHE:2814 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1242 ARCHIVED:84626 CACHE:2827 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1241 ARCHIVED:84617 CACHE:2820 FOLLOWERS:18 FOLLOWING:14

Well, that’s another bug: The search https://twtxt.net/search?q=%22LOOOOL%2C+great+programming+tutorial+music%22 yields the wrong hash. It should have been poyndha instead.

alert the twt police!!

alert the twt police!!

🧮 USERS:1 FEEDS:2 TWTS:1240 ARCHIVED:84596 CACHE:2811 FOLLOWERS:18 FOLLOWING:14

I have a paper deadline coming up, so will everyone please stop writing twts for the next 48 hours, thanks.

🧮 USERS:1 FEEDS:2 TWTS:1239 ARCHIVED:84585 CACHE:2812 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1238 ARCHIVED:84570 CACHE:2811 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1237 ARCHIVED:84560 CACHE:2833 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1236 ARCHIVED:84552 CACHE:2837 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1235 ARCHIVED:84533 CACHE:2833 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1234 ARCHIVED:84522 CACHE:2827 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1233 ARCHIVED:84508 CACHE:2834 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1232 ARCHIVED:84461 CACHE:2822 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1231 ARCHIVED:84449 CACHE:2828 FOLLOWERS:18 FOLLOWING:14

@andros@twtxt.andros.dev Sweeeeet! Just gave it a try, you’ve done a wonderful work 🫡 I wanted to replay from there but couldn’t go past the first page of the feed. It kept freezing on me and complaining about some bad Url (as mentioned on the test twt), so I’ll have to dig through my follow list and see where I effed up this time. 😅

Here’s a twt from @andros@twtxt.andros.dev ’s new version of Twtxt-el 🥳 It feels WAaaaaY better! although it freezes on me as soon as I navigate to the next page complaining about some bad url, but the chronological sorting of the feed as well as the navigation buttons (links?) are a great addition. Looking forward to the next update already! 😁 🥳🥳🥳

🧮 USERS:1 FEEDS:2 TWTS:1230 ARCHIVED:84439 CACHE:2829 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1229 ARCHIVED:84434 CACHE:2828 FOLLOWERS:18 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1227 ARCHIVED:84412 CACHE:2833 FOLLOWERS:18 FOLLOWING:14

Ok, it’s really spam account: https://twtxt.net/twt/xu3u7zq . Damn spammers. Can you delete this?

https://twtxt.net/twt/nbl4xfq

🧮 USERS:1 FEEDS:2 TWTS:1225 ARCHIVED:84394 CACHE:2842 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1224 ARCHIVED:84381 CACHE:2833 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1223 ARCHIVED:84366 CACHE:2831 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1222 ARCHIVED:84353 CACHE:2826 FOLLOWERS:17 FOLLOWING:14

@lyse@lyse.isobeef.org @prologic@twtxt.net 😆 There was something weird going on with my #Timeline instance, the text input box was visible even though I was logged out and I was able to twt from it … It has to do with cache because it wouldn’t disappear unless I whip my website’s cache from the browser.

Poke @sorenpeter@darch.dk and @eapl.me@eapl.me I have no Idea how to reproduce this.

It seems related to us poor single user pods not getting the trust to share twts.. which it seems to still untrust on restart for me.

It seems related to us poor single user pods not getting the trust to share twts.. which it seems to still untrust on restart for me.

@movq, @prologic@twtxt.net when navigating to a Yarn. If the head twt is missing then the whole thread is not accessible. It only returns an error. so i have no way to view any of the replies within the thread other than the end twt.

@movq, @prologic@twtxt.net when navigating to a Yarn. If the head twt is missing then the whole thread is not accessible. It only returns an error. so i have no way to view any of the replies within the thread other than the end twt.

🧮 USERS:1 FEEDS:2 TWTS:1221 ARCHIVED:84322 CACHE:2821 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1220 ARCHIVED:84306 CACHE:2829 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1219 ARCHIVED:84295 CACHE:2871 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1218 ARCHIVED:84286 CACHE:2886 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1217 ARCHIVED:84245 CACHE:2908 FOLLOWERS:17 FOLLOWING:14

🧮 USERS:1 FEEDS:2 TWTS:1216 ARCHIVED:84226 CACHE:2919 FOLLOWERS:17 FOLLOWING:14