Re:Bitmessage: A decentralized and trustless P2P communicati...
by jancsika on Monday January 11, 2021 @12:37PM
(#25732500)
I feel like a tinier, more constrained version of this would have worked better. E.g.,
* normalized 128 byte message content size
* defaults to sending all messages during a one-hour window each day
* no acks until next one-hour sending window
That's quite ascetic. But I think you get certain privacy properties that way which aren't otherwise possible. It would interesting to see if there are practical uses for those properties.
Edit: Oops, forgot:
* when the client is opened, fill a 128-byte buffer with random garbage. When the one-hour send window arrives, if no message has been set in the UI then send the garbage (and reset the buffer to new garbage).
Again, super crude but this PIR is a kind of brute-force approach anyway.
* normalized 128 byte message content size
* defaults to sending all messages during a one-hour window each day
* no acks until next one-hour sending window
That's quite ascetic. But I think you get certain privacy properties that way which aren't otherwise possible. It would interesting to see if there are practical uses for those properties.
Edit: Oops, forgot:
* when the client is opened, fill a 128-byte buffer with random garbage. When the one-hour send window arrives, if no message has been set in the UI then send the garbage (and reset the buffer to new garbage).
Again, super crude but this PIR is a kind of brute-force approach anyway.