Feature Request: "Mailing List" Addresses #51

New Issue

2013-02-19T14:29:19+01:00

ghost commented

2013-02-19 14:29:19 +01:00

(Migrated from github.com)

Hey, I'm not sure how hard this will be to implement but my hunch is "not very". Still digging into the codebase and trying to figure out how it all works.

Anyway; Bitmessage has support for broadcast addresses that people can subscribe to, which can also receive mail as normal addresses.

If there were an action-hook for addresses to call as they receive mail, then one could configure an address that auto-broadcasts any message it receives, creating a mailing-list address. If sender's addresses were included by default (at mailing-address-owner's option), it'd behave like a normal list. If not, then it'd be a sort of anon-list, where senders choose whether to include their address/id in their signatures.

This feature would really expand my ability to sell bitmessage to others, and it would provide an easy-in to new people to bitmessage: join bitmessage and discuss it internally on the bitmessage network, rather than on the subreddit or public forum!

Anyways. I'll keep digging in my spare time and perhaps I'll find a way to implement this. It would be doable with an RPC interface too, of course. :)

Hey, I'm not sure how hard this will be to implement but my hunch is "not very". Still digging into the codebase and trying to figure out how it all works. Anyway; Bitmessage has support for broadcast addresses that people can subscribe to, which can also receive mail as normal addresses. If there were an action-hook for addresses to call as they receive mail, then one could configure an address that auto-broadcasts any message it receives, creating a mailing-list address. If sender's addresses were included by default (at mailing-address-owner's option), it'd behave like a normal list. If not, then it'd be a sort of anon-list, where senders choose whether to include their address/id in their signatures. This feature would really expand my ability to sell bitmessage to others, and it would provide an easy-in to new people to bitmessage: join bitmessage and discuss it internally on the bitmessage network, rather than on the subreddit or public forum! Anyways. I'll keep digging in my spare time and perhaps I'll find a way to implement this. It would be doable with an RPC interface too, of course. :)

Atheros1 commented

2013-02-19 16:30:03 +01:00

(Migrated from github.com)

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.

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.

ghost commented

2013-02-19 16:58:52 +01:00

(Migrated from github.com)

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! ;)

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! ;)

Atheros1 commented

2013-02-19 17:08:30 +01:00

(Migrated from github.com)

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.

ghost commented

2013-02-19 18:25:50 +01:00

(Migrated from github.com)

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!

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!

Atheros1 commented

2013-02-27 18:48:42 +01:00

(Migrated from github.com)

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

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

This repo is archived. You cannot comment on issues.