Question to Nostr devs:
If 2 different devices sign the exact same message and broadcast it, will there be something that distinguishes them as separate messages, or will it appear merely as a second broadcast of the exact same note?
#asknostr
Discussion
The created_at would probably be different.
Ah crap, can you manually force that data easily? Like let’s say I have 2 devices online ready to sign that both get the message, but the device that sends it to them says “add created_at [exact time]”
Do you think that would produce the exact same apparent message or is there still something else likely to get in the way? 🤔
Isn't there some randomness to the signature algo? I don't know, just assumed that there is.
I guess it doesn't matter, if they're identical, tho. But then it's the same as just copy-pasting them and sort of pointless.
There are *a lot* of possible valid signatures per messages.
But no one cares and they still have the same ID
Yes, but it will always have the same sig given the same tags/inputss.
It has to be of course, otherwise it cannot be verified and repeated.
incorrect
Huh? Why not? if I have the same timestamp, pvt key, e tag, p tag, whatever, the signed and delivered note will always be the same.
Okay, I thought I was dreaming that up, since everyone else seemed so sure.
…with the exact same keys if that wasn’t obvious. I’m wondering if there is some data, or hash, or entropy of some sort that’s unique to the device and time of the signing that would make it seem like I signed the same message and posted it two different times, or if it will just look like both devices are “relaying” the same message.
The signature will be different every time you sign even if the event is exactly the same
I worried this would be the case. Would be easier if I could somehow force it to be the same.
My understanding is that randomness is used in the signature to prevent some kind of cryptographic attack
Relays don’t care. As long as they know 1 valid signature it does not matter
Oh I know they wouldn’t care, it was more about preventing from having duplicate posts filling up a feed and trying to prevent that, but having redundant signers available without needing a system of “this device already signed so don’t do anything” that has to get around the whole network… basically a pseudo consensus system among my own devices if they are all in a closed network so one doesn’t repeat the actions of another and flood the feed with the same stuff 2, 3 or more times
They will look as one post if they have the same created_at and data
The signature is different, but the id is the same. Clients and relays have to deduplicate anyway, so whichever signature ends up on the event, only one will ever be displayed or stored in any given place.
They will be signed at different times so it shouldnt be the same signature
yup, it should create a duplicate note
not sure if you can edit the metadata to make it look like it was sent at the same time as that data (timestamp) might be what the relays provide rather than the user
You can easily set a same timestamp
I'm not a dev, in the end it's like broadcasting a note, if the event is signed it's signed
I’m aware of that, but my question is specifically about whether the two separately signed events will appear to relays as if it’s exactly the same event, or two separate events signing the same note.
The former being that it shows up once in my feed, the latter it shows up twice, one behind the other.
if the client has an internal database this should not happen or negentropy (sync id)
This a good question. The signatures may be different, but the ids will be the same.
Nostr uses bip340 for signing, which specifies that random data be included in signing. But this is optional, so it's up to the client doing the signing.
I would assume that because the ids are to same, the relays will just see it as a duplicate event, and ignore it.
It will be a different event.
As a developer i would have to pull a lot of tricks for the signature to be exactly the same. I think it's nearly impossible for good reasons.
I think a good way to think about it would be: the first event would be the 'real' event and the other client making the same message would be more like a broadcast/blastr similar to replaying events.