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! 😊

@movq@www.uninformativ.de good job!

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

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

Guess you could say:

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

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.

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? 🤔

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

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?

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

Thanks again for typing it up, @movq@www.uninformativ.de! I left a few comments there. Currently, I’m in favor of the location-based adressing, that’s heaps simpler.