Feature Request: "Mailing List" Addresses about pybitmessage HOT 5 CLOSED

I don't think it would be very difficult. For the interface we could add an option in the context menu when you right click an address which says something like "Special address features" which brings up a form to allow you to turn on an option: "When a message is received at this address, broadcast it for everyone to see."
There could also be a sub-option: "Include the sender's address in the broadcast message".
Adding this feature will, of course, make people want a richer management interface including user rights management.

from pybitmessage.

Sounds good, can't wait to see!

One thing I discovered while investigating this myself is that there's a falsification detection system baked in to prevent malicious message re-sending from a new address.. that's great, but it won't play well with a mailing list, unless messages from broadcast addresses are auto-whitelisted for this sort of "attack", so users instead trust the signature from the sending key (if available) and not the broadcast address.

But then, you'd understand far better than I how that system works! ;)

from pybitmessage.

Indeed, all messages would appear to come from the broadcast address no matter what- they would never come from the sender's address. The "Include the sender's address in the broadcast message" option would do nothing more than put in a line at the top of each reply: "Message rebroadcast from BM-BasLdoAsomethingsomething". You could trust this line to be truthful as long as you trust the owner of the Broadcast address. I don't think it is very important to authenticate since it is meant to be a public mailing list anyway. I suppose we could include signatures to authenticate the original sender without having to trust the broadcast address owner but then we have two layers of signatures and the program definitely isn't set up to do anything like that right now.

from pybitmessage.

Meh, probably not worth the trouble: mailing lists seldom call for the
same level of authentication and verifiability, and that level of
code-refactoring would be a needless distraction from more important tasks.

It's not as l33t as using raw binary for the message format as you
appear to, but I'd have personally loved to have JSON-formatting of
messages, for this sort of reason; could nest original messages within
the JSON field for the broadcast message, and just code the client to
present nested messages with appropriately nested authentication, or
something. It's more flexible, but at cost of being harder to manage in
C, I guess (should someone code a client in C).

But yea, even this simple level of functionality would be very
excellent. I'm imagining a near future when I can "mirror" mailing lists
I like within bitmessage, and vice versa, to reach a broader/more
paranoid audience!

from pybitmessage.

Hi cathalgarvey,
The format of messages is something that can be decided on by defacto community action- messages each contain an 'encoding type' which is just a number that ranges from 0 to [really huge]. The first 3 are defined but other people are more than welcome to come up with their own ways of encoding messages and I'll support whatever people want.

Concerning pseudo-mailing lists or subscriber lists or whatever people want to call them, I have implemented the feature and it is now active in v0.2.6. Just right click on one of your addresses.

Atheros

from pybitmessage.