My plan is to also associate a messaging identity to a Bitcoin address with a non-zero balance that the user owns (i.e. can sign with). ?This should help ensure that there is something closer to a person attached to the sender. ?Nothing will be perfect in regards to spam, but i'm hopeful this will get me close enough.
Thanks a lot for the link to the Freemail spec. ?I'm sure i wouldn't have come across this on my own and gives a good use case of working with Freenet as a communication layer. On Saturday, November 16, 2013 7:57 PM, Steve Dougherty <steve at asksteved.com> wrote: On 11/12/2013 04:16 AM, Michael Pearce wrote: > I just noticed... the AntiSpamHash should also include the sender's > identifier to avoid the sender using a nonce from a message already > sent to the recipient and avoiding calculating the AntiSpamHash. That does seem like an improvement, but one worry I have with short-lived identities in general is that a spammer needs only to compute more hashes faster to spam more effectively. It's a balancing act between making identity establishment fast enough to be useful and involving enough social forces / slowness to impair spam. > On Tuesday, November 12, 2013 1:07 AM, Michael Pearce > <michaelgpearce at yahoo.com> wrote: > > Thanks for the response!? All good information.? Its fun to think > about how to build a system with the very specific constraints that > Freenet imposes. > > I'm not building a messaging application per se, but users will need > to communicate and most identities will not be very long-lived.? This > is leading me towards thinking I can get away with a single key to > announce new messages.? I was also thinking about adding a Nonce to > the message combined with an expensive hashing algorithm (i.e. > BCrypt) so spamming a user takes some work on the spammer's side. May I ask what you're building? It will be easier to give more informed and specific suggestions with that knowledge. > A sender would create a message similar to: > > Sender <- my public identifier > > Recipient <- recipient's public identifer Nonce <- unique value to > this recipient from the sender for this message > > SenderSignature <- sender signs message with (recipient, nonce) to > ensure sender is who he says he is AntiSpamHash <- Bcrypt(recipient, > nonce, minimum_rounds) to force some work on the sender > > MessageBodyId <- location of signed/encrypted message body located at > a different Freenet key > > As a receiver checking for incoming messages, he only fetches the > message body for messages that: > > * Have himself as the recipient > * Have a unique Nonce from the sender (no duplicates to avoid >? signature / anti-spam value stealing) > * Correct signature at SenderSignature * Correct AntiSpamHash > > If all of these match, the receiver will then retrieve the message > body. > > I think the above scheme will allow for looking at the shared key > pretty quickly, and a computationally expensive AntiSpamHash will > disincentivize large amounts of spam.? Definitely not perfect but it > may be good enough for my needs. This is between individual users? This sounds a lot like Freemail's use case. Perhaps you could base your protocol on that, or use Freemail as a transport? [0] Steve [0] https://github.com/Thynix/Freemail/blob/spec/docs/spec/spec.tex _______________________________________________ Tech mailing list Tech at freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://emu.freenetproject.org/pipermail/tech/attachments/20131117/5f69ed26/attachment.html>
