@xlii is on PowPing!

PowPing is a place where you can earn Bitcoin simply by socializing, for FREE.
Never tried Bitcoin? It's OK! Just come, socialize, and earn Bitcoin.
Check out xlii's activities
Total Economy: 0.09 USD
Feature-request for Baemail. The gist. Let's say I as the owner wish to share a specific baemail message. * I could take a screenshot & hope that others believe that the screenshot is real. * Or I could send the decrypted content to Baemail-serverside, there you could verify that this is the actual content & do the setup & start serving this baemail-message (unencrypted) via a generated-url. After this point can just hand this link to whomever & verify it for themselves. Verified by Baemail. I as the owner of the message should also have the ability to disable the link anytime later. Maybe someone could find sharing of whole threads more useful. (Seems like it would also be better if the unencrypted, baemail-verified message is available as both a webpage & also a json-data-structure)
musiq tipped:
0.03 USD
1 year ago
pete tipped:
0.07 USD
1 year ago
The only way to prove the message content in a court of law would be to give the court the decryption key.
Thinking out loud: Messages are not private if the receiver can publish the message without your consent and prove that it’s unchanged. The decryption via your paymail is the proof for you but then going on to publish that? Yeah I want only the sender to be able to attest to public messages.
xlii replied:
""" Yeah I want only the sender to be able to attest to public messages. Could you please expand on why this is preferable, or why receiver `attesting` is somehow bad? It might not be `attestation`, but the content can already be leaked by the receiver.
This existed in baemail early days. Public baemails. It was called sought info. I separated it out to avoid confusing users from accidentally publishing private messages. Your suggestion is not possible because I cannot verify the content is unchanged from the forwarded message. Not currently anyway.
xlii replied:
I as the receiver of a message can prove that this particular baemail-tx has this content. ////////////////// //this is how the OP_RETURN of a baemail is assembled var assembledOpReturn = [this.protocolPrefix]; assembledOpReturn.push(encryptForPki(serializedBaemailFull, this.baemailPki)); assembledOpReturn.push(encryptForPki(serializedBaemail, sendingPaymailPkiPublicKey.toString())); assembledOpReturn.push(encryptForPki(serializedBaemail, message.destinationPkiPublicKey)); const baeHash = this.context.bsv.crypto.Hash.sha256( Buffer.from(this.protocolPrefix + serializedBaemailFull) ).toString('hex'); assembledOpReturn.push('|'); assembledOpReturn.push('15igChEkUWgx4dsEcSuPitcLNZmNDfUvgA'); assembledOpReturn.push(baeHash); assembledOpReturn.push(senderPkiSign(baeHash)); assembledOpReturn.push(sendingPaymailPkiPublicKey.toString()); assembledOpReturn.push(sendingPaymail.paymail); ////////////////// During the assembling of the array, there are three calls to #encryptForPki adding 3 items to the array. This function asymmetrically-encrypted the content passed in `var1` with pub-key of `var2`. From the code you can see that variable `serializedBaemail` is encrypted for both sender and receiver with an identical content. I as the receiver can decrypt the array-item intended for me & then use the content I got by passing it into my own call of #encryptForPki with the sender's paymail-pki (which is public). The resulting encrypted value would be identical to the value that can be found in my receiveing-baemail-tx in the array-item intended for sender, proving this is the content.
Use https://bitfeed.org/ for the links, when implementing the sharing. It is going to be great.
Sounds like a great feature.
kpdad72 replied:
project corroboration is key to unlocking new ideas.