@prologic@twtxt.net what if I copy your uuid, and use it on my feed? What happens then? Also, was the dot after the timestamp intended?

@bender@twtxt.net This is sadly where you need two things:

• A /twtxt.txt.sig (detached signauture)
  
• Or a way to sign the # uuid = with a key that can be verified.
  

Hmmm and as I write this actually, I think this doesn’t work either, because you can still just copy it regardless. Hmmm @xuu@txt.sour.is help me out here? How do we prevent “spoofing”? 🤔

I think the only legit way of preventing this kind of “spoofing attack” would be:

Digitally Sign Twts: Each Twt could be digitally signed using a private key associated with the UUID. The signature would be calculated over the concatenation of the UUID, timestamp, and content. The public key could be published along with the feed so anyone can verify the authenticity of the Twt by checking the signature. This approach ensures that only the true owner of the UUID (and the corresponding private key) can produce valid hashes.

Which leads us to more Cryptography. Something which y’all voted against.

If we want this though (or some of us do) I will probably have to make the hard decision here to just fork from Twtxt entirely and define a completely new spec. If we care about the UX we need a few properties (some of which we have, some of which we don’t have and some of which are “weak”):

• Authenticity
  
• Integrity
  
• Precision Versioning
  

The last one involves actually supporting the notion of “Edits” and “Deletes” IMO more formally. Without this it would be quite hard to support a strong/good UX. Another way to think about this is “Versioned Twts”.