👋 Thanks for joining us on our Sept monthly Yarn.social meetup today y’all 🙇‍♂️ We had @david@collantes.us @sorenpeter@darch.dk @doesnm@doesnm.p.psf.lt @falsifian@www.falsifian.org and @xuu 💪 Nice turn out! (not all at once of course, as we normally run this over 4 hours as we span many time zones!)

Things we talked about:

• Decentralised vs. Distributed
  
• Use of SHA256 for Twt Hash(es)
  
• We solved Edits! 🥳
  
• UUID(s) probably won’t work! (susceptible to sppofing)
  
• Helped @sorenpeter@darch.dk write some PHP to process/parse User-Agent and service his feed via a custom PHP script 😅
  
• @falsifian@www.falsifian.org introduced himself 👌
  
• Talked about Merkle Trees 🌳
  

Did I miss anything? 🤔

Lol, im just join for several minutes. Wait, Merkle Trees in twtxt?

@prologic@twtxt.net Any more details on the edit stuff? 🤔

@movq@www.uninformativ.de Yes! Basically @david@collantes.us points out that if we mandate that authors should retain the original timestamp in their feed when adjusting content, making fixes, etc, that they retain the original timestamp and leave it unaltered. We already do this anyway, we just need to say so.

Now we have a situation where folks participating in a “conversation” (thread) with appropriate clients can automatically detect edits with almost 100% accuracy by mere fact that the next time they fetch a feed that contains an edit, they now see two versions of the Twt with two different hashes, but identical timestamps.

You can use the fetch time to approximate a “version number” and deal with the display (UX) appropriately.

I can’t believe I didn’t think of this before 🤦‍♂️

@prologic@twtxt.net Okay. So it goes like this:

My client fetches a feed. It builds a map/hashmap/dictionary of all twts: Timestamps map to twt hashes. It then stores/shows the twts. It also stores the hashmap.

On the next fetch operation, the client re-processes all twts in the feed. It must now compare each timestamp to the previously built hashmap: Aha, timestamp T has now a twt hash of B instead of A, so this is an edited twt.

Did I understand that correctly so far? 🤔

@prologic@twtxt.net I’m afraid, I don’t understand how the edit detection works so that it does not break threads. All I see is that some hash in a subject is missing.

@movq@www.uninformativ.de Yes 👍

@lyse@lyse.isobeef.org See @movq@www.uninformativ.de ’s undersanding. Now this had some edge cases that we agreed probably aren’t worth solving for.

@prologic@twtxt.net So this hinges on clients keeping a history of the twt hashes. Clients that clean their cache or simply start following a feed later on have no way of reconstructing older twt hash versions and thus no way of reconstructing existing threads. Right?

@movq@www.uninformativ.de Yup.

It’s no worse than what we have now, it’s better. But yes caveats still apply.

Personally I don’t see it as a problem. I didn’t even really see edits as a problem either tbh, but this is just an incremental improvement I think.

@prologic@twtxt.net If I understand correctly, then this means that twt hashes no longer uniquely refer to one specific twt. When someone talks about #1234567, it could refer to the original or some edit of it. It is up to clients to find out what this hash could mean (by keeping a historical database of all feed versions, basically).

Isn’t this essentially the same as only including url and timestamp in the hash?

@movq@www.uninformativ.de Hmmm 🤔 Intuitively I say “No they’re not the same”; but let me sleep on it 🙏😴

@prologic@twtxt.net That can only work if I happen to have the original one as well. But what are the odds for that? Quite low I’d say. It’s rare that I see a once working thread to be cactus later on. Usually, when I arrive, police already broke up the party. Yarnd might be more lucky in that it constantly pulls, but I don’t.

Anyway, I won’t implement that in my client. Sounds too much effort for the tiny gain.

@lyse@lyse.isobeef.org Maybe you’re right: Let’s pause this while edit/delete discussions.