Another thing: At the moment, anyone could claim that some feed contained a certain message which was then removed again by just creating the hash over the fake message in said feed and invented timestamp themselves. Nobody can ever verify that this was never the case in the first place and completely made up. So, our twt hashes have to be taken with a grain of salt.

@lyse@lyse.isobeef.org matter of fact, earlier you posted:

2024-09-19T20:20:00+02:00	I don't like Australians!

And then deleted it, fearing the Australian Mafia (which, as we know, is very powerful in Bavaria). But I got the hash for it, p5zdahq, and that timestamp has tt written all over it. That’s my proof! 😅😅😅

@lyse@lyse.isobeef.org Sorry could you explain this sifferently?

@prologic@twtxt.net Just what @bender@twtxt.net did. :-D If he’d additionally serve the fake message from his yarnd twt endpoint, everybody querying that hash from him (or any other yarnd that synced it in the meantime) would believe, that I didn’t like Australians.

In fact, I really don’t. I love’em! 8-)

We would need to sign each message in a feed, so others could verify that this was actually part of that feed and not made up. But then we end up in the crypto debate for identities again, which I’m not a big fan of. :-)

I just want to highlight, one might get a false sense of message authenticity, if one just briefly looks at the hashes.

@lyse@lyse.isobeef.org Walk me through this? 🤔 I get what you’re saying, but I’m too stupid to be a “hacker” 🤣

@prologic@twtxt.net Let me try:

Invent anything you want, say feed A writes message text B at timestamp C. You simply create the hash D for it and reply to precisely that D as subject in your own feed E with your message text F at timestamp G. This gets hashed to H.

Now then, some a client J fetches your feed E. It sees your response from time G with text F where in the subject you reference hash D. Since client J does not know about hash D, it simply asks some peers about it. If it happens to query your yarnd for it, you could happily serve it your invention: “You wanna know about hash D? Oh, that’s easy, feed A wrote B at time C.”

The client J then verifies it and since everthing lines up, it looks legitimate and puts this record in its cache or displays it to the user or whatever. It does not even matter, if the client J follows feed A or not. The message text B at C with hash D could have just deleted or edited in the meantime.

Congrats, you successfully spread rumors. :-D

@lyse@lyse.isobeef.org Hmmm I’m not sure sure I get what you’re getting at here. In order for this to be true, yarnd would have to be maliciously fabricating a Twt with the Hash D.

@lyse@lyse.isobeef.org Yeah, makes sense. You don’t even need hash collisions for that. 🤔 (I guess only individually signed twts would prevent that. 🙈 Yet another can of worms.)

@movq@www.uninformativ.de Care to explain how this explicit/attack works for me? 🤣

@prologic@twtxt.net I only saw your previous twt right now. You said:

In order for this to be true, yarnd would have to be maliciously fabricating a Twt with the Hash D.

Yep, that’s one way.

Now, I have no idea how any of the gossipping stuff in Yarn works, but maybe a malicious pod could also inject such a fabricated twt into your cache by gossipping it?

Either way, hashes are just integrity checks basically, not proof that a certain feed published a certain twt.

@movq@www.uninformativ.de Yes that’s true they are only integrity checks. But beyond a malicious pod (ignore yarnd’a gossiping protocol for now) how does what @lyse@lyse.isobeef.org presented work exactly? 😅