@mckinley@twtxt.net To answer some of your questions:

Are SSH signatures standardized and are there robust software libraries that can handle them? We’ll need a library in at least Python and Go to provide verified feed support with the currently used clients.

We already have this. Ed25519 libraries exist for all major languages. Aside from using ssh-keygen -Y sign and ssh-keygen -Y verify, you can also use the salty CLI itself (https://git.mills.io/prologic/salty), and I’m sure there are other command-line tools that could be used too.

If we all implemented this, every twt hash would suddenly change and every conversation thread we’ve ever had would at least lose its opening post.

Yes. This would happen, so we’d have to make a decision around this, either a) a cut-off point or b) some way to progressively transition.

@lyse@lyse.isobeef.org This looks like a nice way to do it.

Another thought: if clients can’t agree on the url (for example, if we switch to this new way, but some old clients still do it the old way), that could be mitigated by computing many hashes for each twt: one for every url in the feed. So, if a feed has three URLs, every twt is associated with three hashes when it comes time to put threads together.

A client stills need to choose one url to use for the hash when composing a reply, but this might add some breathing room if there’s a period when clients are doing different things.

(From what I understand of jenny, this would be difficult to implement there since each pseudo-email can only have one msgid to match to the in-reply-to headers. I don’t know about other clients.)

@bender@twtxt.net Yes, they do 🤣 Implicitly, or threading would never work at all 😅 Nor lookups 🤣 They are used as keys. Think of them like a primary key in a database or index. I totally get where you’re coming from, but there are trade-offs with using Message/Thread Ids as opposed to Content Addressing (like we do) and I believe we would just encounter other problems by doing so.

My money is on extending the Twt Subject extension to support more (optional) advanced “subjects”; i.e: indicating you edited a Twt you already published in your feed as @falsifian@www.falsifian.org indicated 👌

Then we have a secondary (bure much rarer) problem of the “identity” of a feed in the first place. Using the URL you fetch the feed from as @lyse@lyse.isobeef.org ’s client tt seems to do or using the # url = metadata field as every other client does (according to the spec) is problematic when you decide to change where you host your feed. In fact the spec says:

Users are advised to not change the first one of their urls. If they move their feed to a new URL, they should add this new URL as a new url field.

See Choosing the Feed URL – This is one of our longest debates and challenges, and I think (_I suspect along with @xuu@txt.sour.is _) that the right way to solve this is to use public/private key(s) where you actually have a public key fingerprint as your feed’s unique identity that never changes.

@movq@www.uninformativ.de @prologic@twtxt.net Another option would be: when you edit a twt, prefix the new one with (#[old hash]) and some indication that it’s an edited version of the original tweet with that hash. E.g. if the hash used to be abcd123, the new version should start “(#abcd123) (redit)”.

What I like about this is that clients that don’t know this convention will still stick it in the same thread. And I feel it’s in the spirit of the old pre-hash (subject) convention, though that’s before my time.

I guess it may not work when the edited twt itself is a reply, and there are replies to it. Maybe that could be solved by letting twts have more than one (subject) prefix.

But the great thing about the current system is that nobody can spoof message IDs.

I don’t think twtxt hashes are long enough to prevent spoofing.

All this hash breakage made me wonder if we should try to introduce “message IDs” after all. 😅

But the great thing about the current system is that nobody can spoof message IDs. 🤔 When you think about it, message IDs in e-mails only work because (almost) everybody plays fair. Nothing stops me from using the same Message-ID header in each and every mail, that would break e-mail threading all the time.

In Yarn, twt hashes are derived from twt content and feed metadata. That is pretty elegant and I’d hate see us lose that property.

If we wanted to allow editing twts, we could do something like this:

2024-09-05T13:37:40+00:00   (~mp6ox4a) Hello world!

Here, mp6ox4a would be a “partial hash”: To get the actual hash of this twt, you’d concatenate the feed’s URL and mp6ox4a and get, say, hlnw5ha. (Pretty similar to the current system.) When people reply to this twt, they would have to do this:

2024-09-05T14:57:14+00:00	(~bpt74ka) (<a href="https://yarn.girlonthemoon.xyz/search?q=%23hlnw5ha">#hlnw5ha</a>) Yes, hello!

That second twt has a partial hash of bpt74ka and is a reply to the full hash hlnw5ha. The author of the “Hello world!” twt could then edit their twt and change it to 2024-09-05T13:37:40+00:00 (~mp6ox4a) Hello friends! or whatever. Threading wouldn’t break.

Would this be worth it? It’s certainly not backwards-compatible. 😂

The actual end-user problem is that I can’t see the thread properly when using neomutt+jenny.

@prologic@twtxt.net How does yarn.social’s API fix the problem of centralization? I still need to know whose API to use.

Say I see a twt beginning (#hash) and I want to look up the start of the thread. Is the idea that if that twt is hosted by a a yarn.social pod, it is likely to know the thread start, so I should query that particular pod for the hash? But what if no yarn.social pods are involved?

The community seems small enough that a registry server should be able to keep up, and I can have a couple of others as backups. Or I could crawl the list of feeds followed by whoever emitted the twt that prompted my query.

I have successfully used registry servers a little bit, e.g. to find a feed that mentioned a tag I was interested in. Was even thinking of making my own, if I get bored of my too many other projects :-)

@quark@ferengi.one Check out this thread if you haven’t already: https://mastodon.social/@sundogplanets/112464533481477428

I think we already know It’s likely to be a disaster.

@movq@www.uninformativ.de I think I have got it, but need to test upon receiving further posts. I added:

set uncollapse_new     = yes  # open threads when new mail
set uncollapse_jump    = yes  # jump to unread message when uncollapse
set collapse_unread    = no   # don't collapse threads with unread mails

Let’s see how it goes.

Collapsed threads, that is. If I un-collapse a thread, new/unread messages show on the intended new colour, but while the thread is in collapsed state, there is no highlight.

@bender@twtxt.net, cool, so I can join the threads, but your edit to the original will never show at my end. Will have @bender@twtxt.net show the screenshot.

Testing this. I will break this thread purposely, to see how to handle it under neomutt.

Testing this. I will break this thread purposely, to see how to handle it under neomutt. I have now edited this one. Let’s go!

For the mutt/neomutt users out here, what’s the trick to highlight threads with new messages? No user interaction, just upon opening, or while opened, have threads with new, unread messages in it highlighted. Thanks!

@movq@www.uninformativ.de, using the branch on topic right now, it works perfect. The only thing I found was that I had to quit neomutt, and re-open, to see the perfect thread. Other than that, I love it!

@falsifian@www.falsifian.org @bender@twtxt.net I pushed an alternative implementation to the fetch-context branch. This integrates the whole thing into mutt/jenny.

You will want to configure a new mutt hotkey, similar to the “reply” hotkey:

macro index,pager <esc>C "\
<enter-command> set my_pipe_decode=\$pipe_decode nopipe_decode<Enter>\
<pipe-message> jenny -c<Enter>\
<enter-command> set pipe_decode=\$my_pipe_decode; unset my_pipe_decode<Enter>" \
"Try to fetch context of current twt, like a missing root twt"

This pipes the mail to jenny -c. jenny will try to find the thread hash and the URL and then fetch it. (If there’s no URL or if the specific twt cannot be found in that particular feed, it could query a Yarn pod. That is not yet implemented, though.)

The whole thing looks like this:

https://movq.de/v/0d0e76a180/jenny.mp4

In other words, when there’s a missing root twt, you press a hotkey to fetch it, done.

I think I like this version better. 🤔

(This needs a lot of testing. 😆)

This has become quite a large thread. 😅

https://movq.de/v/5c51be2cd3/s.png

@movq@www.uninformativ.de Is there a good way to get jenny to do a one-off fetch of a feed, for when you want to fill in missing parts of a thread? I just added @slashdot@feeds.twtxt.net to my private follow file just because @prologic@twtxt.net keeps responding to the feed :-P and I want to know what he’s commenting on even though I don’t want to see every new slashdot twt.

@bender@twtxt.net He is running on the latest macbook pro with 128G memory. though the chrome app seems to be sitting at 125MB. i am a bit suspicious about that stat since we dont see all the worker threads and he is currently sitting on 40GB of non cache ram.

42km for 42 years: 26.26 miles, 00:11:50 average pace, 05:10:44 duration
crazy run… don’t have a lot of time so i’ll have to remember to complete the thread that i captured in my journal.
#running

Why are there two threads for the same post? #2hhvp2a #kz5qjza

@movq@www.uninformativ.de Well trust me if I tell you that most of my past addictions have started with a “Just once” or a “24 hrs challenge”.

I’m reading through the Week Week In TTY thread you’ve linked earlier and oh-boy!
People went All In TTY and no X … I’m tempted! Although I do not believe I can last more than a couple of hours 😅 but I’ll keep on reading.

And again, Thank you!

Started writing something from scratch yesterday using thread(3) and wow do I miss writing in Limbo instead. :-/ #plan9

I wonder if anyone got that as a replay 🥲 I tried and copied thread’s tag from twtxt.net

Not making THREADING the default view of e-mail clients and thus teaching users that e-mail is “chaotic” (if you get a lot of mail, it becomes unusable without threading) and “needs” full quoting all the time was one of the worst mistakes ever.

Twtxt spec enhancement proposal thread 🧵

Adding attributes to individual twts similar to adding feed attributes in the heading comments.

https://git.mills.io/yarnsocial/go-lextwt/pulls/17

The basic use case would be for multilingual feeds where there is a default language and some twts will be written a different language.

As seen in the wild: https://eapl.mx/twtxt.txt

The attributes are formatted as [key=value]

They can show up in the twt anywhere it is not enclosed by another element such as codeblock or part of a markdown link.

@sorenpeter@darch.dk this makes sense as a quote twt that references a direct URL. If we go back to how it developed on twitter originally it was RT @nick: original text because it contained the original text the twitter algorithm would boost that text into trending.

i like the format (#hash) @<nick url> > "Quoted text"\nThen a comment
as it preserves the human read able. and has the hash for linking to the yarn. The comment part could be optional for just boosting the twt.

The only issue i think i would have would be that that yarn could then become a mess of repeated quotes. Unless the client knows to interpret them as multiple users have reposted/boosted the thread.

The format is also how iphone does reactions to SMS messages with +number liked: original SMS

Bug Thread
⌘ Read more

Decided to block the threads.net domain on Mastodon. I am happy with reaching the people that are part of the current Fediverse. I have no need to add more celebrities and brands and whatever to the Mastodon instance I have been enjoying.

@movq@www.uninformativ.de It took a little over a minute on my machine.. i should try to make it multi threaded.. 🤔

Executed in   68.96 secs    fish           external
   usr time   60.84 secs  242.00 micros   60.84 secs
   sys time   12.52 secs  252.00 micros   12.52 secs

… it just finished and brute-force worked. 18 minutes of computing time on my 11 year old machine, single-threaded.

So far it all seems prey snappy. No long pauses when pulling up threads at all.

@prologic@twtxt.net was this in reply to a different thread? Or maybe a hash collision?

I’ve only been using snac/the fediverse for a few days and already I’ve had to mute somebody. I know I come on strongly with my opinions sometimes and some people don’t like that, but this person had already started going ad hominem (in my reading of it), and was using what felt to me like sketchy tactics to distract from the point I was trying to make and to shut down conversation. They were doing similar things to other people in the thread so rather than wait for it to get bad for me I just muted them. People get so weirdly defensive so fast when you disagree with something they said online. Not sure I fully understand that.

What the hell is #Threads? I’m glad to know nothing xD

Después de probar Meta Threads por curiosidad periodística, definitivamente me quedo con Twtxt 😬

Interesting thoughts about multi thread vs single thread performance.

Image

I found this to be a good thread on the subject of how the media is covering the dam explosion. The author, Timothy Snyder, is a history professor at Yale and has consistently good commentary on the war in Ukraine.

What is a good device for home virtualization these days? I have been looking at the Intel NUC 13 pro’s. Basically I want something “quiet” (ie not a screaming banshee 1U), smallish, but with lots of threads and rams. Disk will come from an external NAS.

@xuu@txt.sour.is @prologic@twtxt.net Yarn.social without threading (as it would be the case in a “truncated” feed) does not make sense to me.

Put another way: Yarn.social is not twtxt. The content that we all have in our feeds really is much closer to a web forum or usenet or whatever. It’s threaded conversations. twtxt, as I believe it was originally intended, are short little status updates – that’s it. The formats of Yarn.social and twtxt might be very similar, but the content is vastly different and, in a way, incompatible. (As such, I think I understand very well that the original twtxt crowd is disgruntled.)

That proposed truncated feed doesn’t really provide any value, if you ask me. 🤔 It’d just be chaotic.

I maintain keys for my email addresses.. but like most in this thread i almost never receive encrypted emails.. other than the BTC exchange i use that sends automated mail encrypted.

There are too many threads going, I can’t keep up. Can someone catch me up on what’s been going on here since last night?

Wob3.11 is a scam. Pass it on. https://threadreaderapp.com/thread/1455625844504743938.html

@movq@www.uninformativ.de No argument that threading is an improvement. But I think (#hash) does that, and I think figuring out how to search should mostly be up to the client.

@prologic@twtxt.net we would want:

• a way to reply to the current thread. We have this.
  
• a way to reply to a specific twt. Need this. Maybe make all the replies start new conversations?
  
• check if twt is start of a conversation.. we kinda have this in the main feed with the conversation button. need to extend it for forked convs
  
• a way to inline first replies. maybe show one or two in the sub thread with a link to view.
  
• for convenience have a link to parent conv?