LOl 😂 Not only have a tried to write up a full Twtxt v2 specification, I’ve also written a Bash shell script that implements the new spec 😅

@movq@www.uninformativ.de Haha 😝 Nice one! And yes I’m also aware of some collisions too!

Had to build a list of all feeds (that I follow) and all twts in them and there are two collisions already:

$ ./stats
Saw 58263 hashes
7fqcxaa
  https://twtxt.net/user/justamoment/twtxt.txt
  https://twtxt.net/user/prologic/twtxt.txt
ntnakqa
  https://twtxt.net/user/prologic/twtxt.txt
  https://twtxt.net/user/thecanine/twtxt.txt

Namely:

$ jenny -D https://twtxt.net/user/justamoment/twtxt.txt | grep 7fqcxaa

[7fqcxaa] [2022-12-28 04:53:30+00:00] [(#pmuqoca) @prologic@twtxt.net I checked the GitHub discussion, it became a request to join forces.

Do you plan on having them join?

Also for the name, how about:

• “progit” or “prologit” (prologic official hard fork)
  
• “git-stance” (git instance)
  
• “GitTree” (Gitea inspired, maybe to related)
  
• “Gitomata” (git automata)
  
• “Git.Source”
  
• “Forgor” (forgit is taken so I forgor) 🤣
  
• “SweetGit” (as salty chat)
  
• “Pepper Git” (other ingredients) 😉
  
• “GitHeart” (core of git with a GitHub sounding name)
  
• “GitTaka” (With music in mind)
  

Ok, enough fun… Hope this helps sprout some ideas from others if nothing is to your taste.]

$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/5 | grep 7fqcxaa

[7fqcxaa] [2022-02-25 21:14:45+00:00] [(#bqq6fxq) It’s handled by blue Monday]

And:

$ jenny -D https://twtxt.net/user/thecanine/twtxt.txt | grep ntnakqa
[ntnakqa] [2022-01-23 10:24:09+00:00] [(#2wh7r4q) <a href="https://txt.sour.is/external?uri=https://twtxt.net/user/prologic/twtxt.txt&nick=prologic">@prologic<em>@twtxt.net</em></a> I know, I was just hoping it might have also gotten fixed by that change, by some kind of backend miracles. 😂]

$ jenny -D https://twtxt.net/user/prologic/twtxt.txt/1 | grep ntnakqa
[ntnakqa] [2024-02-27 05:51:50+00:00] [(#otuupfq) <a href="https://txt.sour.is/external?uri=https://twtxt.net/user/shreyan/twtxt.txt&nick=shreyan">@shreyan<em>@twtxt.net</em></a>  Ahh 👌]

@sorenpeter@darch.dk No, we don’t need both. They are competing proposals and only one of them should get merged. 😃 The format (#<DATETIME URL>) would also work, yeah.

@prologic@twtxt.net Care to explain how that proves anything when someone else already got the spoofed twt with no way to tell it was? can’t an old twt just be deleted and give a similar result when grep-ed for?

Le me is worried! 😅

@sorenpeter@darch.dk Yes, fully agreed.

Personally, I am not really concerned about malicious actors here. Some may see that as naive. But if someone turns out to be an idiot, I unfollow their feed and delete my replies to them, done. (Something like (replyto:…) would even make it trivial to find all my replies to a particular feed and nuke them. Could be done with sed.)

For the same reason, GPG signed feeds never took off. It just doesn’t matter. twtxt is small and nieche and that won’t change anytime soon, I think. We only have to make sure that we don’t open the gates for massive spam and I think we’re safe on that.

It’s easy to get lost in these scenarios and overshoot the target.

@prologic@twtxt.net Yeah. I guess no matter what we do, either one of us has to do a lot of work on his respective software. 😅 The (absolute) impact on Yarn is probably bigger than that on jenny, simply because Yarn is a much larger piece of software to begin with.

I’ll begin experimenting in jenny with Update Commands and see how bad it gets. I’ve already determined that my storage model wouldn’t work anymore. It’s all doable, but, like you, I’m not that happy with all the consequences. 😂

@aelaraji@aelaraji.com I like Nttfy 👌 I’ve wanted to replace my use of the Pushover service with this for a while now 🤔

@bender@twtxt.net Just desktop notifications at the moment, but you could easily throw in a Ntfy server and get notified about anything you want, wherever you want. 🤣

@bender@twtxt.net 👌

👋 Reminder folks of the upcoming Yarn.social monthly online meetup:

I hope to see @david@collantes.us @movq@www.uninformativ.de @lyse@lyse.isobeef.org @xuu @sorenpeter@darch.dk and hopefully others too @aelaraji@aelaraji.com @falsifian@www.falsifian.org and anyone else that sees this! 🙏 We’re hopefully going to primarily discuss the future of Twtxt and the last few weeks of discussions 🤣

• Event: Yarn.social Online Meetup
  
• When: 28th September 2024 at 12:00pm UTC (midday)
  
• Where: Mills Meet : Yarn.social
  
• Cadence: 4th Saturday of every Month
  

Agenda:

• Let’s talk about the upcoming changes to the Twtxt spec(s)
  
  • See #xgghhnq
    

#Yarn.social #Meetup

My Position on the last few weeks of Twtxt spec discussions:

• We increase the Hash length from 7 to 11.
  
• We formalise the Update Commands extension.
  
• We amend the Twt Hash and Metadata extension to state:
  

Feed authors that wish to change the location of their feed (once Twts have been published) must append a new # url = comment to their feed to indicate the new location and thus change the “Hashing URI” used for Twts from that point onward.

This has implications of the “order” of a feed, and we should either do one of two things, either:

• Mandate that feeds are append-only.
  
• Or amend the Metadata spec with a new field that denotes the order of the feed so clients can make sense of “inline” comments in the feed. – This would also imply that the default order is (of course) append-only. Suggestion: # direction = [append|prepend]

The three things we briefly talk about tonight (your morning), so that I don’t forget:

1. Add the ability to allow feed address changes.
   
2. Increase hash from 7 to 11, and/or change the hashing algorithm to something else, better.
   
3. Implement movq (I simply can’t mention while on mobile) second option (the one you like, which maintains content addressing).

I finally decided to do a few experiments with yarnd to see how many things would break and how many assumptions there are around the idea of “Content Addressing”; here’s where I’m at so far:

• What breaks
  

Basically I’m at a point where spending time on this is going to provide very little value, there are assumptions made in the lextwt parser, assumptions made in yarnd, assumptions in the way storage is done and the way threading works and things are looked up. There are far reaching implications to changing the way Twts are identified here to be “location addressed” that I’m quite worried about the amount of effort would be required to change yarnd here.

@mckinley@twtxt.net Yes I have, however I’m not counting that because even using “Cloud” is not labor free.

@aelaraji@aelaraji.com We digits it out 🤣 @lyse@lyse.isobeef.org ’s little hack was good but only temporary 🤣

@sorenpeter@darch.dk Lins of agree with dealing with this kind of social nonsense which we’ve all done in the past 🤣

@movq@www.uninformativ.de I think your scenario doesn’t account for clients and their storage. The scenario described only really affects clients that come along later. Even then they would also be able to re-fetch mossing Twts from peers or even a search engine to fill in the gaps.

@lyse@lyse.isobeef.org makes me want to be there. Sunny, but “feels” fresh. Lovely!

@aelaraji@aelaraji.com it looks good! Where do you see those notifications?

@movq@www.uninformativ.de I cases of these kind of “abuse” of social trust. Then I think people should just delete their replies, unfollow the troll and leave them to shouting in the void. This is a inter-social issue, not a technical issue. Anything can be spoofed. We are not building a banking app, we are just having conversation and if trust are broken then communication breaks down. These edge-cases are all very hypothetical and not something I think we need to solve with technology.

Been thinking about it for the last couple of days and I would say we can make do with the shorter (#<DATETIME URL>)since it mirrors the twt-mention syntax and simply points to the OP as the topic identified by the time of posting it. Do we really need and (edit:...)and (delete:...) also?

@prologic@twtxt.net 🕵🏻 Hint: it was a twt about stolen property…

@movq@www.uninformativ.de Awesome, thank you very much! I’ll have a look at it tomorrow.

It was beautiful in nature: https://lyse.isobeef.org/waldspaziergang-2024-09-21/

Fresh hay bales on a field

I have just made yet another convoluted twtxt notifications script! Feeling like an old dog learning new tricks! 🤣

Image

Alright, let’s call attention to this fact and let’s hear your opinions on this:

With the (replyto:…) proposal, clients cannot indicate that a twt was edited in the long run. Clients can, of course, show that right now, but when they clean their cache and refetch feeds, the information is lost. This can be abused by malicious actors if sufficient time has passed (clients must have purged their cache): Malicious actors can change root twts and thus change the meaning of thread/replies.

Is this a showstopper for you? 🤔

@prologic@twtxt.net You’ve done extremely well for ~$125/month, but that’s not figuring in labor. I’m sure you’ve put a lot of hours into maintenance in the last 10 years.

@prologic@twtxt.net Kind of. But the (edit:) spec has similar problems in its current form:

1. Post a normal twt with nonsense content, let’s say the content is just a dot “.”.
   
2. Post an update to that twt, this time filling it with actual content, let’s say: “Birds are great!”
   
3. Wait for people to reply to your twt (which is the edited one). You might get lots of replies along the lines of “ohhhh, yeah!” or “😍😍😍” or other stuff wholeheartedly agreeing with you.
   
4. Post another update to the first twt, again changing the content completely, let’s say: “The earth is flat!”
   
5. Delete your first update from your feed, the one with the birds. Not with (delete:), just remove the line.
   
6. There’s now a thread with lots of people agreeing to a twt that says “The earth is flat!”
   

You might be able to see that the original content was just a dot “.”, but the twt that people actually replied to is gone for good and no way to detect that.

This raises two questions:

• The easy question: What do we do when the twt that an (edit:) line refers to is removed later on from a feed? We would have to delete that original twt from our caches, including the edit operation. This should be part of the spec.
  
  • The result being a thread without a root, just like it is today. That’s fine.
    
• The hard question: How do we deal with multiple (potentially malicious or misleading) edits? Do we even want to open that can of worms? People only ever use the original twt hash in their replies, so nobody really knows to which edited version they’re replying. That is very similar to the (replyto:) situation, I think. 🤔

@movq@www.uninformativ.de That’s kind a problem though right?

@david@collantes.us 🤣🤣🤣

@prologic@twtxt.net

I just realized the other big property you lose is:

What if someone completely changes the content of the root of the thread?

Does the Subject reference the feed and timestamp only or the intent too?

Then the content of that root twt changes. Just like it would with (edit:…). The only difference is that you cannot go back to that person’s feed and find out what the original content was.

In other words, we can’t (reliably) show a little star * like on Mastodon to indicate edits.

@prologic@twtxt.net

Regarding the URL changing issue: That is not a new issue and not addressed by either PR. Do you have some plans to solve this that only works with hashes? 🤔 Is it feed signing? I have to admit here, I forgot most about the feed signing ideas. 🙈

• Twt Subjects lose their meaning
  

You mean existing threads in the past? Yeah.

• Twt Subjects cannot be verified without looking up the feed.
  
  • Which may or may not exist anymore or may change.
    

Not sure what you mean? 🤔 But yes, things can change (that’s the point).

• Two persons cannot reply to a Twt independently of each other anymore.
  

How so? 🤔 That would be a total show-stopper, I agree. But are you sure that’s going to happen? For example, if people were to reply to this very twt of yours, they would do this:

(replyto:https://twtxt.net/user/prologic/twtxt.txt,2024-09-21T15:22:18Z) foobar

Am I missing something?

I just realized the other big property you lose is:

What if someone completely changes the content of the root of the thread?

Does the Subject reference the feed and timestamp only or the intent too?

@prologic@twtxt.net “Even though there are some 😉 that have different views on this 🤣” — coyly raises the hand… LOL.

@bender@twtxt.net Yeah I’ll be honest here; I’m not going to be very happy if we go down this “location addressing” route;

• Twt Subjects lose their meaning.
  
• Twt Subjects cannot be verified without looking up the feed.
  
  • Which may or may not exist anymore or may change.
    
• Two persons cannot reply to a Twt independently of each other anymore.
  

and probably some other properties we’d stand to lose that I’m forgetting about…

I like the (replyto:...) as well. If the feed changes, well, it is the same as changing emails (and deleting the old one). No?

@movq@www.uninformativ.de One of the biggest reasons I don’t like the (replyto:…) proposal (location addressing vs. content addressing) is that you just introduce a similar problem down the track, albeit rarer where if a feed changes its location, your thread’s “identifiers” are no longer valid, unless those feed authors maintain strict URL redirects, etc. This potentially has the long-term effect of being rather fragile, as opposed to what we have now where an Edit just really causes a natural fork in the thread, which is how “forking” works in the first place.

I realise this is a bit pret here, and it probably doesn’t matter a whole lot at our size. But I’m trying to think way ahead, to a point where Twtxt as a “thing” can continue to work and function decades from now, even with the extensions we’ve built. We’ve already proven for example that Twts and threads from ~4 years ago still work and are easily looked up haha 😝

I’m still more in favor of (replyto:…). It’s easier to implement and the whole edits-breaking-threads thing resolves itself in a “natural” way without the need to add stuff to the protocol.

I’d love to try this out in practice to see how well it performs. 🤔 It’s all very theoretical at the moment.

Guess you could say:

• (replyto:…) is twtxt-style
  
• (edit:…) and (delete:…) is Yarn-style

I just read the primary spec I’m strongly in support of and it’s pretty rock solid for me 👌 💯

Do you recall what it was? I blame my maintenance window 🪟

@bender@twtxt.net Hmm what you replied to appears to be non-existent: https://twtxt.net/twt/pqst4ea

@movq@www.uninformativ.de I just saw thes come through! 🙏 Thank you very much, I’ll definitely have a read tomorrow! 👌

@movq@www.uninformativ.de good job!

Something’s broken.

Alright, before I go and watch Formula 1 😅, I made two PRs regarding the two “competing” ideas:

• https://git.mills.io/yarnsocial/yarn/pulls/1179 – (replyto:…)
  
• https://git.mills.io/yarnsocial/yarn/pulls/1180 – (edit:…) and (delete:…)
  

As a first step, this summarizes my current understanding. Please comment! 😊

@prologic@twtxt.net the one I relied to. It vanished now.

@bender@twtxt.net Which reply was that? 🤔

@bender@twtxt.net Bahahahahaha 🤣